[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [f-cpu] F-CPU architecture...
Long time no C, I mean VHDL, er Verilog. Do you guys need webspace? I am an ISP now.
----- Original Message -----
From: "Yann Guidon" <whygee@xxxxxxxxx>
To: f-cpu@xxxxxxxx
Subject: Re: [f-cpu] F-CPU architecture...
Date: Sat, 27 Aug 2005 01:46:34 +0200
>
> 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.
>
> YG
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
--
_______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/