[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] F-CPU architecture...



Hi F-gang,

Yann Guidon wrote:

Well, we don't need so many pins for I/O. A unidirectional 1 Gbps lane will give us throughputs of up to 100 MB/s.


too slow :-P

What about 2.5 Gbps (InfiniBand speed), then? ;-)

If we use e.g. 16 lanes in either direction (1.6 GB/s), then we need 64 pins on the F-CPU and 256 on the G-chip (differential signals assumed).


roughly. a larger FPGA will be more expensive, but will handle more F-CPUs,
so will have a better performance.

Are there really FPGAs that can handle signals in the 1 GHz range or above?

[...]
Whether the DMA starts idle or waits for data from the I/O port is simply a matter of toggling control bits, IMHO.


well, DMA is usually an /explicit/ command from SW.

Maybe I should not call it DMA engine but "data moving engine" - in either case, it's an independent entity that can transfer data on its own.


cache refill is an automatic function that is expected by the core.

Well, yes. And who fills the cache with data that does not reside in memory?

And the interface to the DMA engine is not yet defined.
I wish something like on the SHARC is available
(DMA block descriptors are a linked list stored in RAM)
but this requires further thinking.

It doesn't have to be a list. An array will work fine, too, and requires less hardware - incrementing a pointer is easier than loading a new one from memory.


A ring buffer would also be possible with minimal overhead. And it has the advantage that you can easily add new requests while DMA is still running. All we need is four parameters: address and size of the DMA descriptor table, and "head" and "tail" offsets into the table. The "head" will be maintained by the DMA engine, and when head and tail are the same (simple XOR), DMA stops until the OS moves the tail to a new position (after writing new descriptors, of course).

--
Michael "Tired" Riepe <michael@xxxxxxxx>
X-Tired: Each morning I get up I die a little
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/