Calculating SRAM Write Speed

[dreaquil]

I'm working on a uni project where I'm required to design an FPGA to camera interface which will run an image processing algorithm. So I'm currently looking for an FPGA dev board with some SRAM(or DDR) on board but I'm finding it difficult to calculate how fast I'd be able to write to the SRAM (MB/s). Can anyone help me out? . I'm planning to store 2 consecutive frames of a 640*480 16bit sensor in order to work on them using my image algorithm. I need to figure out how many frames a second I can handle since I've figured I'd be able to store 2 frames with 0.8MB leeway.

SRAM:  http://www.issi.com/WW/pdf/61-64WV20488.pdf
Camera: http://www.voti.nl/docs/OV7670.pdf
Dev Board: http://store.gadgetfactory.net/papilio-duo/

[kamtar]

10ns for write cycle - 100MB/s. But you will be limited by your FPGA clock (and your design!). If you have 50mhz clock then its only 50MB/s with 8bit data bus.

[dreaquil]

oh so it's as simple as that ? Thanks alot. Interesting ... how would i go about calculating write speed for this LPDDR RAM?http://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/Mobile%20DRAM/Low-Power%20DRAM/LPDDR/60-series/T67M_512Mb_mobile_lpddr_sdram.pdf

[kamtar]

DRAMs are little bit more complex and im not a expert in this. Read it and look at timing diagrams, you can see that for example write burst can go as fast as clock (200Mhz - 800MB/S for 32bit).

[miguelvp]

...
SRAM:  http://www.issi.com/WW/pdf/61-64WV20488.pdf
Dev Board: http://store.gadgetfactory.net/papilio-duo/

The papillio duo already has 2MB SRam (well, the higher priced one does).

[nuno]

Those SRAMs can be written at their graded speed, but note that you will need some signals that are not aligned with the edges of the clock... I'm currently having the same design problem.

[bktemp]

DRAMs are optimized for burst access: When reading or writing large blocks of data at adresses in the same bank you can reach a data rate near the clock rate. But when you need access to random adresses the datarate goes down to 1/10 or even more in extreme cases. Typically the datarate is in the range of 1/2 the clock rate multiplied by the bus witdh.

[dgtl]

You have to consider both the data bus width and the timing of the data bus. The data bus width is important, because wider bus means more throughput. At the same time, you have to use the full bus width to use that throughput; byte-wide read/write accesses on 64-bit wide bus is just wasting most of the bandwidth.

SRAM has a simple interface and can easily be interfaced to FPGAs, their bus access speeds do not have lower limit. The timings must be correct; when operating at high speeds, take care to ensure that the FPGA project timing constraints for the SRAM signals are set correctly and that the PCB board itself is laid out well (when designing PCB yourself). The SRAM interface in FPGA is simple and can be done yourself. You can use whatever access patterns at maximal speed as long as you use full bus width.

DRAMs(SDRAMs, DDR-SDRAMs etc) are much more complicated beasts. Do not expect to use DRAMs on prototyping boards; a PCB with proper layout is needed to get the thing working. You do not want to experiment with DRAM PCB layout if this is your first DRAM project, use a dev board with DRAM if you need to have DRAM. Ie Avnet Spartan-6 microboard is at the same price range as the papilio and has LPDDR. If possible, avoid DDR and use SRAM; there are a lot of complications when using DRAMs; especially when it's your first FPGA project.

For DRAM's, the memory is accessible in bank/row/column pieces and jumping around (changing the address) will take a lot of time. Also, the DRAM needs refreshing and it can not be used while refreshing. First, check what DRAM's are supported by your FPGA, you do not want to write SDRAM controller yourself. Use existing SDRAM controller, use SDRAM chips, that are supported by the controller (SDRAM? DDR? DDR2? SDRAM-LP? DDR-LP? etc). Check the lower limit of the speed for the DRAM chip, ie DDR2 will not work below 125MHz. This may force the internal memory bus to 125MHz and you have either support the same speed in your logic or use clock crossing bridges. Design your logic so that you will perform only large reads and that you do not need to change DRAM row addresses too often. Expect some delays due to refreshing and use FIFOs. You'll need usually some kind of caching or prefetch buffering so that different parts of the system can read larger bursts of data at once and then use the buffer when SDRAM is busy filling other buffers. Consider using all of the banks if the controller is capable of having open rows in all banks.

[marshallh]

Asynchronous SRAM have crap bandwidth but they are nice, deterministic and low latency. Every transaction is identical

Synchronous SRAM( SSRAM) is just with a source-synchronous bus, so you can crank up the data rate. They are very handy when you need high bandwidth, with a very small dataset (say <4mbyte). You don't need to worry about all the annoyances of DRAM. It's expensive!

SDRAM is also source synchronous and carries all the problems of typical DRAM with it.
Examples:

SDRAM, x16 @ 100mhz = 1600mbps total throughput. Divide by 8 and you get 200 megabytes throughput. This of course assumes you have the ram completely rapped out 24/7. In real life you will have to take breaks to send auto precharge commands.
DDR1, x16 @ 100mhz = 3200mbps (400mbyte/sec). Minimum access size of 16 bits. All DDR memories transfer two words in each clock cycle. This is a bit more annoying to deal with
DDR1, x16 @ 200mhz = 6400mbps (800mbyte/sec). Minimum access size of 32 bits without data masking. Many newer oldschool DDRs are rated up to DDR-400 (this means 200mhz bus clock).
DDR2, x16 @ 125mhz = 4000mbps (500mbyte/sec). Minimum access size of 64 bits without data masking. Due to internall DLLs Fmin you can't clock it slowly.
DDR3 - its pipelined even more and has higher Fmin. Not for the noob, difficult to use with garden variety FPGAs.

Of course you can change the bus width.. If you want a x32 bus (for 64bits per DDR clock) then you can do it by either:
1. Place 1 x32 chip (difficult to source)
2. Place 2 x16 chips and connecting all their signals except for DQ*
3. Place 4 x8

etc..
When doing this you should route the command/address lines in a split-T topology so all modules see the same signals at the same flight times, so that overall DQ skew is minimized.
What DDR3 does is it adds another trick in the pot: write leveling via flyby topology. You can google this and see why you'll never be able to use DDR3 dimms with cheap FPGAs...

[marshallh]

Also with asynchronous SRAM like the one on that crapililio board, 10ns is only the minimum pulse width of the /WE line. You have to factor in the time required for setup of hte address both before and after the write cycle. And also they must be quantized based on your controller's clock speed. So if I were you I would run it at 100mhz, and that would give you 30ns best case per word write.
That's if the device on the board is actually the 10ns grade...
So you're at 33mb/sec now. Each frame will be 600kb. *60fps = 35mb/sec bandwidth. This is just assuming you are only writing to the ram.
You will also need to read out the frames. You begin to see the problem...

I am currently building a 1080p HDMI upscaler with a x16 LPDDR, at DDR333 it is barely useful. You can never have enough ram bandwidth.

May I suggest the DE0-Nano, and write your own SDRAM burst DMA controller? If all you care about is imagery, you can just burst scanlines at a time, which is very easy to build a DRAM controller for.
Read the SDRAM datasheet, then consult existing code (hamster_nz posted one a while back).

[nuno]

Also with asynchronous SRAM like the one on that crapililio board, 10ns is only the minimum pulse width of the /WE line. You have to factor in the time required for setup of hte address both before and after the write cycle. And also they must be quantized based on your controller's clock speed. So if I were you I would run it at 100mhz, and that would give you 30ns best case per word write.

My interpretation of the SRAM's datasheet the OP posted is that it indeed can do a write cycle in 10ns (/WE is 7 or 8ns), problem is that it leaves only 2 or 3ns to change and stabilize the address bus.
I've been looking at these FIFOs, but boy, they are expensive (I wanted to do 100MHz SRAM write bursts in discrete logic)... http://www.mouser.com/ds/2/405/scas636e-110619.pdf

[miguelvp]

Not sure why you don't like the papilio duo, care to share? since I did back it up and have one in my hands I would like to know what is so wrong with it before I have time to play with it.

Back to the OP and I might be oversimplifying:

640*480 16bit = 614,400 bytes per frame
Camera can do up to 30 fps that's 1,8432,000 bytes per second (54.2535 ns per byte)
and needs 2 frames, he has 33.33 ms to do his computations before the next frame is ready, so he will need a triple buffer and another two buffers to store the results to be displayed so that's 5 buffers worth of frames with two being written and two being read in 33.33ms.

So buffer size is a bit under 3MB (3,072,000) for all 5 buffers.
2 buffers need to be written and read in 33ms (2,457,600 bytes) that's 13.56ns per byte giving little margin.
I would put the output buffer of the result in the fpga fabric to drive the output, or send it out or you'll need 6 buffers.

The memory module can write at 10ns minimum so that's 100MHz
The Spartan in the duo is a grade -2C (XC6SLX9-2TQG144C) and can handle 200MHz easy, at least I didn't find any switching speed lower than that but I didn't look too hard
http://www.xilinx.com/support/documentation/data_sheets/ds162.pdf

So doable at the max speed of 30fps that camera can do, but the timing constrains are going to be a pain.

Now for 60fps, there is no way but good thing his requirements don't call for that