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

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



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:
> > > The VCI interface protocol is defined by the VSI Alliance (vsi.org).
> > > I am investigating whether it can be used in the frame
> > > of F-CPU. Why not Wishbone ? Could be, but VCI
> > > is very simple and does not define a bus or whatever, just the interface.
> > > Exactly what is needed to define a core, without caring for the fine prints
> > > of the reference manuals.  I like VCI to the same point i dislike PCI.
> > 
> > It has its quirks, though. An asynchronous VAL/ACK cycle seems to be
> > pretty unreliable -- you never know whether the ACK arrives in time --,
> > while synchronous handshakes are slow (2 cycles per cell).
> 
> 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.  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.

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