Rep:Re: [f-cpu] Control signals on the Xbar

["Nicolas Boulay" <nicolas.boulay@ifrance.com>]

find the >>>>
-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 30/07/02
Objet: Re: [f-cpu] Control signals on the Xbar

On Mon, Jul 29, 2002 at 08:32:42AM -0700, jaap stolk wrote:
> hi, (i'm the one that caused al these problems :-) )
> 
> --- Just an Illusion <illusion_to_net@yahoo.fr> wrote:
> > Do you understand now the problem of non-definition
> > of communication 
> > process between blocks ?
> > Do you understand now, the necessity to clearly
> > define the block 
> > interface and the communication protocols ?
> 
> centenary, an accurate and fixed description of each
> units interface would be helpful, however
> we will never have that till the F-CPU is completely
> designed, implemented, and tested.
> it will always we necessary to keep changing
> what part belongs to witch unit, and the
> communication between the units will we changed now
> and than, if it could make both units less
> complicated (think transistor count, timing, fan-out,
> etc. )

At least for the EUs, the interface and communication protocol should
be pretty clear:

 - There's an input register between the Xbar and the EU.

 - There are output registers between the EU and the Xbar.

 - There's an `enable' flipflop in front of each EU.

 - When an instruction is issued, operands and flags are clocked
   into the input register, and '1' is clocked into the enable flipflop.

 - When no instruction is issued, '0' is clocked into the enable
   flipflop. Contents of the input register are unspecified
   (ideally, the values remain unchanged, to save power).

 - Both data and the enable signal `move' through the stages of
   the EU in a wave-like fashion. Inactive stages may remain quiet,
   controlled by the propagated enable signal (ideally, their
   outputs will remain stable as well).

 - When data is ready at the output port(s), it is clocked into
   the output register(s). If a port has a latency of <n> cycles,
   and data is written to the input register at cycle <k>, its
   corresponding output register will be written at cycle <k+n>.

 - Whether or not the value of an output register changes in
   other clock cycles is unspecified. It may stay unchanged
   until the next valid result appears. On the other hand, an
   EU is allowed to ignore the enable bits and `work full-time'.
   In that case, a valid result will be available at the output
   register(s) only for a single clock period.


Note that input/output registers and the enable flipflop are NOT part of
the EU entities. There also are no `output enable' signals currently;
the
scheduler is supposed to know when the result arrives, and at which 
port.

>>> I don't like that so much because the scheduler must known the exact
behavior of the unit or try to simulate it. In either case, this task
should be done but the unit "known" much more than the scheduler about
it's own scheduling. (imagine load&store, multi-cycle operation that are
pipeline,...).

>>>I know that the whygee will. Because he think that for topology
reason this "simulation" of timing beavior must be done very close to
the scheduler it-self to avoid long wire. From my point of view it's
only a place&route problem and spliting desing from a routing point of
view could became a real mess in the future when things get bigger. 

nicO

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

 
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif


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