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

Re: [f-cpu] opcodes : missing m4



hi !

jaap stolk wrote:
> sorry for the slow response.
no problem :-)

> about the tmp_*'s:
> 
> i have been thinking about this, but could not
> decide what would be the best. lots of flags/signals
> are the same for all EU's, so it would make sence to
> delay them in/after the decoder (or on the x-bar),
> and then distribute then to all the EU's.
> on the other hand, distributing the flags to all the
> EU's across long wires (from the decoder) will take
> some time, witch is a pity if there is a free cycle
> before that. also some units need that cycle to
> improve the fan-out of the flags ?
it's not a problem : the synthesizer+place+route software
will do the right decision (and if not, we'll correct it).

> but anyway,
> changing it back is fine, i'll just delay mode and
> combine_size in the decoder.
not in the decoder : the decoder decodes, and Xbar transmits.

> about the stall's:
> stall is declared by toplevel, if you use an EU
> without the rest, then the test bench shoeld provide
> the stall signal.
that's what i did. Fortunately there is only one signal
to recreate :-)

> > when the pipeline is stalled (well, the
> > decoder and the Xbar),
> actually it's just the decoder (and the fetcher), we
> can't stall the xbar, because we need to keep re-
> loading the data in case there is a bypass.
hmmmmmmmgrmblgrmbl.... did i miss something ?....

> i looked into it, and yes, it is a bit confusing.
sure.

> in hardware it's easy to "stall" a unit just by not
> changing it's input. in software, i have to save it's
> output or re-run the unit.
but not by clearing the input.
my latest ROP2 fixes that.

> to save hardware-power, you need to not-change the
> inputs, to save software-power you need to
> not-re-run the units.
sure. But then it's a higher level ad it's independent
from the unit itself.
Don't you think it would be better to split eu_rop2
to solve all these troubles ?
For example, we remove the fanout/xbar stage
and we let the Xbar function do the switches when
the control signals are ok....

> mixing both ways doesn't seem to go very well. :-(
> please forget about stalls, and just use your original
> eu_rop2.c files. i'll sort this ASAP in the simulator.
ok. do i remove the pipeline stage (with tmp_function)
from eu_rop2_cycle() ? i believe that there should
be no mention of "stalled" in the execution units
(it's the Xbar's job)...

> i'll let you know more soon...
ok.

> and i'll look at the files you send me.
ok. send me a short tarball when done.

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