Re: [f-cpu] f-cpu simulator

[jaap stolk <jwstolk@yahoo.com>]

hi,

I intent to test each unit to the corresponding
VHDL unit, either by reading an input file
(generated by VHDL or C) or by using a c routine
that generates the input code (like in the VHDL
tests )
i won't test the timing inside each unit, only
the output after each cycle.

for this to work i will uses exactly the same
input / output signals as the VHDL code.
i also would like to use the same names as in VHDL,
but the vhdl names are not unique (i.e. they use
"input_a" wile i would like to use "asu_input_a".

my problem for now is that it is very hard to find
what the exact input/output signals are and what they
do. (that’s wy i made the funny "stage" drawings
in the c source files)
i'm sure this will we more clear at some point,
and i'm happy to keep adapting the names according
to the vhdl.

to make it more complicated:
i also would like to mix the vhdl units into the
simulator. would it be difficult to prepare a file
with input data, call the VHDL simulator, and read
its output back into the c simulator ?
for example run the c simulator, but instead of the
c opcode decoder, use a (experimental) vhdl opcode
decoder.

i'll try to fix any differences between vhdl and c as
soon as possible. 

i also have a cople of questions:
- the intermediate data can't go strait from the
 fetcher to the Xbar, because the 8 bit and 16 bit
 data are not aliged (6 bit shift needed)
 can i run the 16 bit intermediate data through the
 decoder and shift it there if it turns out to be
 8 bit? (it already end up there as flags)
-hoe do i do r3w1 ? (only 3 registers in opcode)
 is the 3rd input register == to the result register?
-as i understand it, the register units reads the
 3 registers that are indicated by the fetcher, and
 the decoder decides later if they need to be loaded
 onto the xbar. and doesn’t if they were not
 registers but flags or part of intermediate data
 or the instruction is stalled.
 dous this sound ok?


--- Yann Guidon <whygee@f-cpu.org> wrote:
> hi !
> 
> jaap stolk wrote:
> > 
> > i uploaded:
> > snapshot_jws_16_07_2002.tar.bz2 to:
> > http://f-cpu.seul.org/~f-cpu/new/
> ok i got it and will look at it.
> The files you first sent me seem to be ok
> though i did not yet compile them.
> 
> > it's just a little test of last weekend,
> > but it compiles, and can simulate ASU and
> > INC instructions including xbar and register set.
> wow.
> 
> > see the /c/jaap.txt file for more info.
> > 
> > jaap.
> > 
> > yg, it now shows all registers, and waits for
> > enter after every stage.
> 
> i do not want to stop your helpful efforts but i
> have
> a problem with the current testing workflow, a
> solution
> would be to rewrite some things...
> 
> The problem is to be sure that all versions (C, VHDL
> etc.)
> are coherent with the manual's description and (more
> importantly)
> with each others. This way, any input in the C
> version will
> return the same result for all other versions (if
> someone wants
> to make a Verilog version, or whatever).
> 
> The idea is to do a pattern generator for each unit,
> and send it to all the testbenches. The results will
> then
> be compared (a diff will be ok) and equivalence of
> the
> versions will be ensured.
> 
> I don't have a clear idea yet of how to do this, i
> want
> to avoid "naughty hacks" at any cost. I don't want
> to be
> forced to rewrite things whenever a new thing is
> implemented...
> 
> one "clean" way would be to create another
> subdirectory,
> maybe "patterns", so "c" and "vhdl" could read the
> generated
> files. The script would then run "diff" on both
> results.
> Another solution is to generate the patterns
> containing
> input and expected output, so each testbench can
> catch
> the inconsistencies themselves, but it's more
> complex.
> Not to mention that the input format for every unit
> changes (the interfaces differ) so a library must be
> written in each langage to read and compare the test
> patterns :-/
> 
> WHYGEE
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
*************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org
> with
> unsubscribe f-cpu       in the body.
http://f-cpu.seul.org/


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/