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

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

hi !

Michael Riepe wrote:

Hi two,

With the advent of a new organisation (with FC0 having one specific I/O channel),
the "G chip" can be a simple FPGA. This makes it much more cost-effective and practical :

And slow?

not more than a custom chip :-P some recent FPGA are really fast and suitable for the G-chip. and they are available NOW. so whether it is slow is not really an issue.

some FPGAs can be had with a thousand pins, expensive but much less
than if we designed our own G-chip with as many pins. And we can develop
the routing algorithms, etc, without having to going to fundry.

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

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.

The basic idea is that the F-CPU contains a DMA engine that transfers data from I/O to memory and vice versa. When the chip is reset, the engine would be preset to receive a fixed amount of data from the I/O bus and transfer it to a fixed physical address (most likely zero) where the F-CPU can execute it.

That, or a simpler way : init PC=0, which triggers cache fault, (because RESET has flushed everything) so reads from outside memory (private memory is not mapped to address 0) ---> no need to design the DMA specificically for booting.

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. cache refill is an automatic function that is expected by the core.

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.


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