a2e at insight.rr.com wrote:

A _lot_ is going to depend on how the data is acquired and what you need
to do with this data.

Reading the data shouldn't be a problem - is 96MHz a serial or parallel
stream? Do you have a clock along with the incoming data? Or will you have
to sample it with a free-running clock?

you need to do with the data. The speed of an FPGA design depends on the complexity of that design. Considering you have hard-disk storage and ethernet in there I'm assuming that the 96MHz is either a serial stream or bursty or you are only interested in a subset of the incoming data - you're going to be SOL if you need to process _all_ the data at that rate and then store it or send it over ethernet... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Let me start off by saying that I am sorry if some of my questions
seem a bit basic, but my knowledge of FPGAÂ’s is limited to a few
classes I took back when I was in school.

My ultimate goal is to capture data from a CMOS image sensor and store
it to a hard drive. The CMOS sensor itself will either be clock out
data at a frequency of 48Mhz or 96Mhz. My first question is how can I
tell if a particular FPGA is capable of reading in data at these
rates? I have looked over various datasheets but I have to admit I
have not been able to find a straight answer.

The two devboards I am looking at are the “Spartan 3E Starter Board”
from Dililent or the “Cyclone II FPGA Starter Development Kit” from
Altrea. Would either of these boards be capable of doing what I need?

As for cores I am thinking that I will need to run the following:

OpenRISC 1200
General-Purpose I/O (GPIO) Core
I2C controller core
tri-mode Ethernet MAC
VGA/LCD Controller
OCIDEC (OpenCores IDE Controller)

Does any of this sound reasonable for the boards I mentioned above or
do I need to go back to the drawing board?

a2e at insight.rr.com wrote: [...] This problem is actually twofold. One thing you need to figure out is what clock rate you need to interface the CMOS sensor and then look in the FPGA data sheet whether the I/O pins support those timing constraints. The second thing to consider is the maximum frequency you can run your design in an FPGA. This one depends on the logic. Generally speaking, the more complex the design is, the lower gets the maximum speed you can run it with. But then there is still the possibility to speed up designs by the way they are designed. So the same function, carefully designed can achieve better maximum frequencies than if it were sloppy designed. At the end, the synthesis tool will tell you what maximum clock you can achieve with your design. In the data sheet you will only find what maximum external clock you can apply to your FPGA. But that is not necessarily the clock you are using inside for the logic. FPGAs have so called clock manager functions. They allow to step up or down the external applied clock. In the Xilinx FPGAs this is called the Digital Clock Manager (DCM). In the data sheet you will find what maximum input clock the DCM allows. See for example table 70 in the data sheet. http://direct.xilinx.com/bvdocs/publications/ds312.pdf The data sheet will also tell you how much the DCM can bring this clock up.

Look into the documentation of the specific cores whether they provide
synthesis information for a specific FPGA. This will give you an idea
how much of the FPGA the respective core will use and what clock rate
you can use.

Hope that helps.

Cheers,

Guenter

The answer to your first question is that there is no straight answer. Programmable logic is inherently slower than purpose-built ASICs, and the ability to close logic at a given frequency depends on how much you are trying to do and how good you are at optimizing. For the second part, I do not know the boards you mentioned, and again, it depends on how much you want to do. Cyclone II's should be perfectly capable of buffering data and presenting it to the bus architecture of your choice. Still, I would probably do at least a preliminary design and run it through a simulator to see what devices will hold the design. THEN choose a board that will support your logic. It would be a real shame to spend hundreds of bux on a board and then find that it is too small. Regards, Steve McQueen Mcqueen Technologies, Inc. On Fri, 2007-07-27 at 08:04 +0200, a2e at insight.rr.com wrote:

----- Original Message ----- From: Mark McDougallmarkm at v...> To: Date: Fri Jul 27 07:47:10 CEST 2007 Subject: [oc] Help with choosing a FPGA


Thanks for the reply. The incoming data will be parallel but 'bursty.'
Also everything will be sampled on the falling edge of an external
clock pulse. As for the incoming data the only thing I want to do with
it is store it to the hard drive, no processing necessary. The
ethernet will be used at a later point to retrieve the data from the
hd and send it back to a PC, so performance issues are not as big of a
deal there. So I am guessing from what you said that the Spartan 3E
with 500K gates is enough?

My next question is about the IDE interface, I am guessing that I will
have to incorporate some type of filing system into the soft
processors code?

Thanks.

I tried to post this yesterday but I must have done something wrong as it never showed up, so I am sorry if this is somehow a repeat. Thanks to everyone who replied, there is some useful information there. From what I gather if I keep my design simple a Spartan 3E with 500K gates should be enough right? The incoming data is going to be 8 bits with and sampled on the falling edge of an external clock. Depending on which sensor I chose to use this clock will be either 48 Mhz or 96 Mhz, but the data will come in bursts. My fist question is that if the onboard osc of the dev board is 50 MHz will that have any bearing on the maximum frequency I can clock in at? I know of this was a normal uController it would, but like I said my knowledge of FPGAÂ’s is pretty limited. Looking ahead my next question is about the hard drive interface, I know there are cores out there to implement IDE interfaces, but what about a file-system? I am guessing that I am going to have to deal with that in the soft-cores software? Thanks again. ----- Original Message ----- From: a2e at insight.rr.coma2e at i...> To: Date: Fri Jul 27 08:04:52 CEST 2007 Subject: [oc] Help with choosing a FPGA

Greetings and Aloha, I too am just starting my first hardware design that needs an FPGA, and have so-far decided cyclone3 or spartan3e are the appropriate choices. My design needs to capture images from a Micron MT9P001 5 megapixel CMOS sensor at 96 megapixels per second (at 12-bits per pixel). This sounds suspiciously like your application - except in my case I need to send the image across a gigabit ethernet cable (except not to save images on my PC). Therefore, your project and mine seem very similar and I would like to see whether you want to combine efforts. I have designed dozens of electronics devices over the years, including CPUs, embedded controllers and devices, and so forth --- but somehow have always evaded the need to design with FPGAs. However, my luck has run out on this design effort it seems, though most FPGAs are *FAR* too expensive to consider. The cyclone3 and spartan3e seem plausible at $10 to $20 for the smaller devices in those families. Because their I/O pins are only capable of 200 to 625 megahertz, we cannot implement the serial part of the gigabit ethernet in the FPGA. But we can adopt $3 ~ $20 gigabit ethernet serdes/transceiver chips from TI/national/marvell/others - but the cheaper ones input and output 10bit 8b10b encoded data, which we must encode and decode in our FPGA to adopt them. To put a 1Ge or 10Ge serdes/transceiver in an FPGA requires we choose one of their expensive families, which are ***VASTLY*** more expensive (as in $250 ~ $400). The cost to build my product needs to be as close to $25 per camera as I can manage, including 5Mpixel sensor, lens, FPGA, transceivers, connectors, housing, etc. This is in moderate quantities (10K to 1M units per year). Hope this helps. Contact me by email if you wish. Regards, bootstrap -at- hawaii.rr.com ----- Original Message ----- From: a2e at insight.rr.coma2e at i...> To: Date: Fri Jul 27 08:04:52 CEST 2007 Subject: [oc] Help with choosing a FPGA

a2e at insight.rr.com wrote:

No, FPGAs have internal PPLs that can synthesize a whole range of
frequencies from an external clock input. One caveat - a quick experiment
with the Quartus II megawizard reveals that you can't produce _exactly_
48MHz from a 50MHz clock - at least on Cyclone II - the dividers and
multipliers don't pan out. Might be safer to use 24MHz in your case...

If you want a file system, then yes, there are free FAT filesystems available that are highly portable. I've used "FatFs" on a NIOS-II with the opencores IDE controller. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:


That is interesting and I did not know that. So it is possible to run
the I/O of an FPGA with the internal PLL based clock, which will allow
to clock in data faster than the external applied clock?

Cheers,

Guenter

Günter Dannoritzer wrote:

Absolutely. An internal high-speed PLL is much more accurate than an external oscillator with associated variances due to - well, the physics of it all. That's why you clock PCIe cores running at Gbps for example, with 250MHz oscillators... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266