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

Re: [f-cpu] another DATE report

Yann Guidon a écrit :
> hello,
> nico wrote:
> > Sorry, i couldn't be at first jeudi.
> without you, it's less interesting ;-)
> > For the story about VCI, i have  contacted tghe guy from wishbone. He is
> > very please that we introduice new type of cycle in there buses. Maybe
> > such cycle could come from VCI ideas.
> VCI is looking even more simple, i think.
> VCI's protocol is : an initiator sends a packet (address+data+command word)
> and the target answers with a reply packet (data+status word).
> Such things can be interleaved with a TID (transaction number, 16 by default).
> Multiword packets have a protocol that ensures that over-simplified targets
> (without internal state machines) can still work : the address bus is incremented,
> a "end of packet" signal is raised when the last word is sent, a "contiguous"
> flag announces that the addresses are contiguous.
> All this is managed with a simple "FIFO" interface (Data Enable - ACKnowlege)
> and since it is only an interface, there is NO constraint on latency,
> interconnect topology, number of initiators and targets...
> And "wrapper"s already exist to "plug" VCI 'components' to most other existing
> buses and networks.
> > Wisbone is very (to much ?) simple.
> if it's simple, then why do you want to make it more complex than necessary ?
> > i propose to introduice 3 things :
> > - a cycle take only one cycle,
> huh ? a cycle is a cycle, i don't understand what you mean.
> maybe i should read the wishbone specs more carefully, i have printed it but haven't
> had enough time to read everything.

Oups ! i means a read or write cycle take only a clock cycle.(to be
comparre to the 2 clock cycle from AMBa wich pipeline data and address)

> > so it's means that the signal must make
> > the following travel : master-arbiter-master-slave-master ! There is an
> > extention to introduce waiting cycle but you loose bandwith.
> VCI is not complex like that because it's a point to point connexion
> between two elements. One of the elements can be the interconnect itself,
> providing multiple ports at wish.
> > I propose to introduice interleave multi-cycle access. It look like the
> > new low latency DRAM from Infineon with a synchronous SRAM interface.
> URL ?
> > So, you send the adress to receive the grant from the arbitrer but then
> > you have n cycle bevore receiving or sending the data. But you could
> > rebegin an other transaction in between.
> VCI already can do that easily :-)

> > - a CAS 2 cycle. 2 consécutives load followed by 2 writes but atomic !
> > If there is problems, writes could not occur.
> ugly.

Nop, absolutely necessary to handel very easly synchronous problem.
Christophe convince me, if he could resend it's URl about the paper that
speak about.
Such technic, in the common case, where there is no collision the only
lose is this CAS2 instruction, there is no OS call overhead, no task
switch, nothing. Only 4 atomic transactions ! We must have that !

> > - maybe things to manage cache L2 (from my point of view L2 is tied to
> > the DRAM controller, the L1 is tied to the CPU). None caching access for
> > example to avoid cache trashing.
> what do you mean by "things to manage cache L2" ? what things ?

For example, caching or no caching data (imagine the FCPu as the core of
the Geoforce 8, rendered image didn't need to be cached). To extend
that, i would try to apply distributed memory in some control logic to
make invalidate some cache line...
> see you soon,

Yep ! I leave Paris for 1 weeks. Don't blow my mail box !
> > nicO
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu       in the body. http://f-cpu.seul.org/
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/