Re: [f-cpu] f-cpu simulator

[Yann Guidon <whygee@f-cpu.org>]

hi !

i'm starting only now to dig into your files
(even though i have thousands of other things to do,
such as work on the manual, i know...).

In the beginning, i think that i'll have to carefully
watch how fcpusim is designed. when everything goes
ok, we will all return back to our favorite things.

First thing to remark : clearly separate the simulator
from the I/O. I think that the fcpusim files should
be moved away from the /toplevel/ directory, to another
new one that is dedicated to this simulator (simply
/fcpusim/ for example). This way, someone wanting to
make a different interface does not have any problem.
OTOH toplevel will be in charge of keeping
the pipeline correctly ordered by calling the individual
unit's functions in the correct order (there are some
ways to avoid the costly FF copy).

Concerning one of your remarks in your jaap.txt file,
i recommend usign ncurses and gpm. I have found some
resources about programming with these libraries
and it should not be too complex. i'll send you a
file that explains how to use GPM. Using this
is a first step towards a better interface.

jaap stolk wrote:
> 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 )
finally, it seems that we will have to write a little
library in C and VHDL that can read the input stimuli.
The vectors will be generated by another program.
i'll do my best to make something clean and scalable.
It would be cool if Renaud/Illusion helped us here...

> i won't test the timing inside each unit, only
> the output after each cycle.
that's obvious.

> 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".
that's not a big problem ...

> 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.
i am not sure that it is absolutely necessary to
reuse the VHDL names.

> to make it more complicated:
> i also would like to mix the vhdl units into the
> simulator.
why ? do you want to do cosimulation ?

> would it be difficult to prepare a file
> with input data, call the VHDL simulator, and read
> its output back into the c simulator ?
it's possible, but a big overkill...

> for example run the c simulator, but instead of the
> c opcode decoder, use a (experimental) vhdl opcode
> decoder.
what would be the benefits ?
if we can ensure that the C and VHDL sources are equivalent,
there is no need to do that...

> i'll try to fix any differences between vhdl and c as
> soon as possible.
don't stay focused too much on that, though.

> 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)
the decoding stage performs the shifts 'speculatively' :
imm8 and imm16 are expanded and duplicated, and the desired
result is multiplexed by the Xbar. it takes one or two cycles,
that's enough.

> -hoe do i do r3w1 ? (only 3 registers in opcode)
>  is the 3rd input register == to the result register?

the 3 sources are the 3 register fields of the instruction
(they are wired to the register set's input). that's as
simple as that.
Now for the result, it depends on the instruction :
 - for the normal operations, the destination is simply
    the deest field.
 - mac, mux : the destination is the destination register xor 1
     (that : if source is 4, the destination is 5 and vice versa)
 - load/store with postinc : the destination register is
    the pointer field (in the middle).
I don't remember whether there are other exceptions (i doubt)
but the write field is less critical than the read fields,
which are in the decoding critical datapath. The time
to perform any operation is enough to multiplex and select
the written register, so it's ok.

> -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?

the decoder (usually, a ROM or something hardwired and
optimised like that) gives signals to the Xbar for the
next cycle. then the Xbar selects what data is put
on the read bus : immediate data, register set output
or bypassed values.

WHYGEE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/