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

Re: [f-cpu] Use of VCI for F-CPU core

hi !

Michael Riepe wrote:
> On Fri, Jan 18, 2002 at 02:24:11AM +0100, Yann Guidon wrote:
> > hi !
> > Michael Riepe wrote:
> > > On Thu, Jan 17, 2002 at 10:43:44PM +0100, Yann Guidon [systeme] wrote:

> > VCI (any version) is fully synchronous. It is clearly specified in the
> > documentation. As to whether it is slow, just consider that F-CPU is
> > meant to run at a higher frequency than usual circuits. This can also
> > involve crossing a clock domain. Although the minimum latency is 1 cycle, just consider
> > that the addressed circuits will probably require much more cycles before
> > they give an answer. This is where it becomes interesting (or awful
> > depending on how you see it). While in "Peripheral VCI" (a VCI subset for dumb I/O
> > for example) this is a limit, "Basic VCI" and "Advanced VCI" provide
> > 4 bits for Transaction ID (a TID from 0 to 15) so the answers can come back
> > in order or not, after a variable number of cycles. In a way, VCI's design
> > makes the FC0's design easier, or if you prefer, it removes some burdens.
> Right.
> I guess I didn't express myself clearly enough.
looks lile we are both tired ;-)

>  The problem is in the
> handshake protocol. The initiator raises VAL, the target responds with
> ACK, and when both lines are active at a rising clock edge, the transfer
> is done. When ACK is generated asynchronously, and the timing is too
> tight, the target might see an active ACK while the initiator still
> thinks it's inactive (transmission delay!). Now let the clock signal
> rise exactly at this point, et voila, they're out of sync.
in the VCI spec, they are clear about these cases (hey, the ones who
designed this are older than us all ;-D) and in no way should the interface
itself cross a clock domain (the wrapper has to do it, it more than one
domain exists, but not the interface). A VCI interface must NOT be
asynchronous. The little examples i had in course at the university showed
the simple FSMs that realize the necessary protocol, but this often depends
on your needs so one FSM does not fit all cases. Just in case you wanted
to know ;-)

>  Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/