Anyone designed a DDR RAM controller? - Page 1
Forum section: electronics / projects

author: deephaven
author_rank: Frequent Contributor
timestamp: April 09, 2012, 04:11:22 pm
content: I have a requirement for around 700 Mbits of RAM running at around 150 MHz.DDR RAM seems up to the job and I know you can buy IP from Altera (my favoured FPGA) to do the job.I need a constant data rate both in and out of the RAM, so I can see extensive use of FIFOs will probably be required.I just wondered if anyone has designed such a thing (either using pre-made IP or designing it from scratch) as I would like to get some comments about possible pitfalls.

author: tnt
author_rank: Regular Contributor
timestamp: April 09, 2012, 08:44:09 pm
content: I designed a DDR controller a few years back.I originally tried to use the one from Xilinx but it was bulky and didn't really work, so I designed my own.It turned out to be pretty easy. You end up with a control block and a data path. The control is a simple state machine with some timer to limit when/what state transitions is possible/insert wait cycle and such.The datapath has the physical interface which can be tricky and has to include the DQS capture logic (for read) as well as a programmable phase clock logic. For low speed ( ~ 100 MHz clock ), you can calibrate manually by trial and error. But for 133 & more you'll need to include auto-calibration logic.What took the biggest time to debug for me, turned out to be a bug in the tools ... I had a OSERDES followed by a differential output buffer (to generate DQS), and the tool converted that to two OSERDES with inverted data each followed by single ended buffer. Except the reset logic was not good and sometimes they wouldn't start synchronized and DQS# was not sync with DQS, one was shifted by 1/2 clock cycle vs the other ...We had to use a scope to figure that out ...

author: IanB
author_rank: Super Contributor
timestamp: April 09, 2012, 08:47:29 pm
content: You could look at tesla500's work on his high speed camera. I think he was designing a memory interface for that to capture the image data.

author: nctnico
author_rank: Super Contributor
timestamp: April 09, 2012, 08:50:58 pm
content: The biggest hurdle is to calculate the timing to determine whether there is a stable data window. Otherwise you'll need calibration. Your best bet is to use the flipflops in the I/O cells for capturing the incoming data. The more logic you string between the memory and the flipflop inside the fpga the larger the variation in timing.I don't know about Altera's IP but Xilinx's MIG tool is overengineered.

author: deephaven
author_rank: Frequent Contributor
timestamp: April 09, 2012, 09:40:48 pm
content: Thanks for the replies, guys. It always impresses me how much expertise there is on this forum.I'm a bit concerned about this data timing that has been mentioned by more than one of you. I would have thought that it would be possible to hold the timing tightly enough if the data was going to go straight into a register on the FPGA. The FPGA will have to be a Cyclone 3 or similar as there wouldn't be the budget for anything fancier.

author: tesla500
author_rank: Regular Contributor
timestamp: April 10, 2012, 12:39:22 am
content: If you want something that just works*, the Altera (or your FPGA vendor of choice's) controller is your best bet. The Altera Cyclone DDR2 controllers have autocalibration for read timing. It's needed here because they're not using DQS to capture the read data, but a phase shifted version of the clock sent to the memory. But it's all taken care of by the core so you normally don't have to worry about it. I believe the newer Cyclone IV parts have proper DQS capture hardware built into the IO buffers, so this calibration shouldn't be needed. The Altera controller is quite large, the Cyclone 3 DDR2 controller is 4000 LE for a 16 bit interface.* With proper board layoutAs you said you'll want some reasonably sized FIFOs to allow efficient burst transfer, the read delay is around 20-25 clock cycles from read request to first data available so using bursts much longer than this is essential. A FIFO depth of perhaps 10x the latency should do.To get multiple access ports to the RAM (IE for read and write, and perhaps another for a CPU to access the RAM), you can use Qsys (formerly SOPC builder) to make a system and take advantage of the Avalon switch fabric. Create a system with a master to connect to the RAM controller and slaves to connect to your read/write hardware and anything else like a CPU. All the bus arbitration is taken care of for you. One caveat, a NIOS core may be required for this to work.I personally would stay away from writing my own DDR controller due to the work involved, but as tnt has shown it can be done. One of the big problems is that you'll be using a lot of FPGA family and vendor specific features like DDR IO buffers, so the data path part of the design won't be too easily portable to other devices/vendors. This is probably why there aren't too many open source DDR memory controllers.There are a couple of open source controllers, but I'm not sure if they actually work or are reliable.DDR Controller for Virtex2http://opencores.org/project,ddr_sdrDDR2 controller for Spartan-3Ahttp://opencores.org/project,ddr2_sdramDavid

author: deephaven
author_rank: Frequent Contributor
timestamp: April 10, 2012, 08:22:30 pm
content: David, many thanks for your extensive and useful reply. I enjoyed looking at your YouTube time lapse videos on your DDR PCB layout and your high speed camera stuff. Can I ask what clock speed you run your DDR RAM at?I don't really need multiple ports into the RAM as I will only be doing writing or reading blocks at different times, so no need for any sort of arbitration. I need to get my head round this calibration function, I assume this means that, when doing a read, the phase of the DQS signal can vary with respect to the clock?I am tempted to go with a layout such that I can either use a home made controller or the Altera so that I leave a couple of options open.

author: nctnico
author_rank: Super Contributor
timestamp: April 10, 2012, 11:18:07 pm
content: Actually the phase delay of DQS is also specified in the Jedec standard. I think you can go up to 125 maybe 133MHz without need for calibration. The IP Xilinx and Altera provide is aimed to achieve the maximum possible speed so these implementations are big and clunky. You may be better off doubling the number of bits and go for the lowest speed the memory allows (125MHz for DDR2).

author: Scrts
author_rank: Frequent Contributor
timestamp: April 12, 2012, 07:02:06 am
content: Afaik DDR2 controller from Altera is free. Why not to use that? Personally I use SDRAM (125MHz clock, up to 200Mbit/s), which is also free. However timing issues become a bigger issue, when You need a lot of memory. E.g. now I use 5 SDRAM chips: 4 video buffers plus one for Nios, but I suppose I could better do going for wider bus DDR2 and doing at least 2K bursts.