1
\$\begingroup\$

If you imagine basic motion detection where you have two frames stored in memory: a previous 640x480 frame and the current 640x480 frame, what type of memory (SRAM, DRAM, SDRAM, DDR SDRAM, etc) would allow for the most parallel read/write operations per clock cycle? For example, the perfect solution would allow the simultaneous read of two frames, (307,200 x 2 pixels) in one clock cycle. What is the best memory for this, the SRAM built into the FPGA, or an external chip like DDR SDRAM? (In the bigger picture I'd be looking for the a FPGA dev board that has the smallest cost and size with the largest parallel read/write ability.)

\$\endgroup\$
  • 1
    \$\begingroup\$ Really? If you assume 24bit colour, that would require 14.74Mbit per clock cycle - so even if you used DDR that would require 7 million pins! Why do you need such speeds? \$\endgroup\$ – Tom Carpenter Apr 28 '15 at 0:57
  • 1
    \$\begingroup\$ With a high end FPGA and a 64bit wide DDR3 memory running at 800MHz clock frequency you'd be able to transfer data at roughly 100Gbps. So that would take roughly 150uS to copy two frames. \$\endgroup\$ – Tom Carpenter Apr 28 '15 at 1:00
  • \$\begingroup\$ A Virtex-7 X1140T has 1880 BlockRAMs each with a 72 bit interface -> 135.360 bits per cycle. Back to normal devices ... Normally, one would estimate how many MiByte/s are needed by a certain algorithmn ... \$\endgroup\$ – Paebbels Apr 28 '15 at 1:16
  • \$\begingroup\$ Virtex-7 or DDR3 800MHz fpga are not "smallest cost and size". @user2514676, I think you don't approach the problem the right way. Most video application (never done motion detection, but I'm pretty sure it's not "special") read each frame pixel once per pass, keeping it in register/blockRAM as long as required for the algorithm, which is usually a limited amount of line. As such, your requirement is being able to write 1 pixel and read 2 pixels every cycle, which for 640x480@60fps will be achievable for any memory technology from the past 15 years. \$\endgroup\$ – Jonathan Drolet Apr 28 '15 at 2:54
  • 1
    \$\begingroup\$ You are going about this the wrong way. If your frames are from a normal speed camera, you have ~30 frames per second and e.g. 600,000,000 clock cycles per second. Therefore you do not process a frame in one clock cycle and then sit idle for the remaining millions of clock cycles until the next frame. You do it a pixel or region at a time. \$\endgroup\$ – pjc50 Apr 28 '15 at 8:49
3
\$\begingroup\$

Dual port block RAM and LUT RAM is pretty much impossible to beat as it is on the FPGA die and accessing it does not require using any I/O pins. If you don't have enough capacity in block RAM, then you can throw external memory at the problem. QDR SRAM is dual ported and so has double the bandwidth of SDRAM, this can be useful for some applications, though it is very expensive. DDR3 SDRAM is probably the cheapest option, but even this is relatively slow compared to what you can do with LUT RAM and block RAM.

I think you're going about your design the wrong way. Besides, if you need to do any real processing on that many inputs, the logic alone would consume an absolutely gigantic amount of area, and may not fit on the largest FPGAs available today. What FPGAs excel at are very high speed pipelined processing operations. What you should do is figure out how many pixels per second you need to process (640x480xfps) and then figure out how to implement your image processing algorithm to get that level of performance. Generally the idea is to read in a small number of pixels per clock cycle and then process them in an orderly fashion.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.