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