[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] f-cpu simulator

On Tue, Jul 16, 2002 at 03:47:15PM -0700, 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 )
> 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".

Doesn't matter in VHDL. In C, you can prefix the port names with
`<EUNAME>_' or something like that.

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

At least in my units (IAdd, IMul64 and Shuffle64) the inputs and
outputs are well-documented. Do not look at the wrappers but at the
files behind them.

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

If you write VHDL test engines that read the file, pass the signals to
the entity-under-test, read the results and write them back, yes.
But it's going to be sloooooooooooooow...

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

The decoder is supposed to do that.

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

Either that, or the result register's "buddy" (register number ^ 1).
I don't remember which one it was.

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

IIRC, register read and decode are performed in the same cycle:

	1 - instruction fetch
	2 - register read & instruction decode
	3 - xbar
	4 - EU

That is, your idea looks correct.

 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/