DDR FPGA Design

I'm planning an FPGA design that will be using SDRAM (DDR Winbond W9425G6DH5) and NAND Flash (ST NAND018W3B2AN6E). I'm not particularly experienced in DDR memory design and there are other issues that need my attention other then just DDR RAM design.

I keep hearing horror stories about engineers getting into trouble with DDR RAM designs. Do you have any experience integrating DDR to FPGAs and how do you recommend I kkep out of trouble.

Thanks

Reply to
Mounard Le Fougueux
Loading thread data ...

Be realistic and don't let yourself fooled by succes stories. If you stay within the timing limits of the FPGA, you'll be just fine. And remember: there are no free DDR implementations available. So either roll your own or buy one.

Clocking the data from the memory is an issue if you use fpga's. Timing may vary a bit from device to device. The more layers of logic you add to the data input path, the bigger the variation in timing, the worse things get (this is why the MIG tool from Xilinx makes such a kludge of a DDR implementation). Use the flipflops in the IO cell to clock the data into the fpga. If you take all the timing variations and jitter into account, you can determine a window (with respect to the DDR clock) in which the data will be stable. The only thing you need is a (shifted) clock with an edge inside that window. If you can't get the window big enough, lower the frequency or use a faster fpga.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

Huh? In which sense is the OpenCore DDR controller not free (Thanks to David Ashley it runs just fine on my Spartan 3E kit)? Also ISTR seeing other alternatives, but they may have had slightly more restrictive licences.

That said, I think there plenty of room for a clean, simple, and unencumbered (ie., free) DDR controller in Verilog.

Tommy

Reply to
Tommy Thorn

I checked with our Applications memory interface group, and this is their answer:

"It depends on the target frequency and the target FPGA device. He is targeting a DDR SDRAM at 200 MHz which is possible in V5 at any speed grade.

In V2Pro and Spartan-3 a template router must be used for data capture using memory strobe and this requires adhering to pin placement rules which makes it less flexible. In V4 we have two techniques, the Direct Clocking technique (does not use the memory strobe instead calibrates to center align data from memory to FPGA clock using the IDELAY) for

240 MHz (-12 device) and below. The other technique uses the ISERDES and the BUFIO clocking resource to route the memory strobe for first stage capture in the strobe domain and transfer to the FPGA clock domain. The ISERDES technique supports up to 300 MHz in a -12 device. In V5 we use the ISERDES also and we support up to 333 MHz in the fastest speed grade device (-3)."

All of these designs are "free", no license fees, and Xilinx has several memory-interface evaluation boards. Contact a Xilinx FAE to guide you through these different design approaches.

200 MHz = 400 Mbps is not difficult anymore. Twice that speed is challenging,... Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

Is there a minimum transfer speed for ddr & ddr2 memories ..? Ie should you want to clock them at 10 MHz, then you can't etc..

Reply to
pbFJKD

The Opencores DDR controller has serious limitations (burst length and IIRC the kludgy clocking scheme for instance). If you want the full version, you're supposed to pay.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

Some memories can operate down to 83MHz. A Spartan 3 series speedgrade

4 FPGA can be interfaced with DDR memory at 100MHz without problems.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

This is the answer I got from the Xilinx Memory Interface group: It depends on the target frequency and the target FPGA device. He is targeting a DDR SDRAM at 200 MHz which is possible in V5 any speed grade.

In V2Pro and Spartan-3 a template router must be used for data capture using memory strobe and this requires adhering to pin placement rules which makes it less flexible. In V4 we have two techniques, the Direct Clocking technique (does not use the memory strobe instead calibrates to center align data from memory to FPGA clock using the IDELAY) for

240 MHz (-12 device) and below. The other technique uses the ISERDES and the BUFIO clocking resource to route the memory strobe for first stage capture in the strobe domain and transfer to the FPGA clock domain. The ISERDES technique supports up to 300 MHz in a -12 device. In V5 we use the ISERDES also and we support up to 333 MHz in the fastest speed grade device (-3).

All these designs are free (no fees). I suggest you call a Xilinx FAE to sort out the possibilities.

200 MHz = 400 M reads or writes are not a problem anymore. Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

DDR2 memories have a guaranteed bottom end of 125 MHz. In either case, the memory data sheet will show you the minimum frequency your memory device is specified for. If the chip uses a DLL to align the strobes, a minimum frequency spec is necessary.

- John_H

Reply to
John_H

I think what Nico was trying to say is you get what you pay for. In my experience, the free DDR designs are generally not worth much. Either they only support basic operation, or they won't work at full speed, or they are so littered with bugs that you are better off starting from scratch. Yes, there are "free" cores out there, but you'll likely put as much effort into getting them to work in your design as you would starting with a clean sheet.

Reply to
Ray Andraka

I checked with the Xilinx Applications group, and here is their answer:

"The free memory interface designs developed by the Xilinx memory applications team have one primary goal: to prove that the FPGA device can interface with given external memory devices at the specified performance, using the IO standard specified by the memory vendor (JEDEC). We therefore focus on the physical layer that comprises the read data capture logic, and the write data transmit logic. The memory controller that we provide with the interface design is very basic, handling memory initialization, auto refresh commands, and other user requested commands like reads and writes. Such a basic controller can be efficient (high data throughput) for streaming video applications with consecutive reads and writes to the same row and bank. But such a controller is very inefficient in applications requiring random accesses to different rows and banks. Therefore, in the Virtex-5 DDR/DDR2 SDRAM memory controller, we now provide multiple-bank support to increase the efficiency of data throughput. Multiple-bank support may still not be the solution for certain applications, and our customers usually replace just the Xilinx-provided controller with one that they designed to specifically handle their system's traffic pattern.

With our free Virtex-5 applications the memory interface designs are modular and provide a clean partition between the optimized physical layer and the controller, making it easy to replace the controller while retaining the physical layer design."

Hope this explanation helps. Peter Alfke, Xilinx

Reply to
Peter Alfke
[snip]

Any hope that this will migrate down to the V4 and Spartan 3 designs??

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

Having read through a bunch of Xilinx DDR app notes, I'm confused. It seems that the only way to use DDR with a Spartan-3 at high speed is to deal with a carefully constructed LUT-delay chain, subject to manual routing and other nightmares. Other competing products, such as the Cyclone I & II have programmable delays in some of the IOBs, making centering on the DQS trivial in comparison.

The OP (Mounard Le Fougueux) didn't mention *which* FPGA he was targeting. It seems to me the answer depends crucially on this.

Tommy

Reply to
Tommy Thorn

Tommy,

I've done my own DDR controller (targeted at the Spartan3E-Starter Kit) some months ago and it wasn't that hard. It interfaces 16 Bit, 130MHz DDR to a 64 bit wishbone bus at 65 MHz. [1]

It's not very felxible, and in retrospective i should have done an asyncronous design where the wishbone bus can be arbitraty clocked... But.. hey, it was one of my very first VHDL projects.

j.

[1]
formatting link
Reply to
joerg

I wouldn't go that route. It will require regular delay calibrations because of temperature changes and aging. Worse, it will make your design behave different in every product you make because each fpga will have different delays. An FPGA which is just within spec may trigger a bug in your design! The best way in a Spartan3 and similar devices is using a shifted clock to feed the IOB flipflops.

You can use the IOB delay in the Spartan3 to center the DQS, but the routing of the DQS clock to the IOB flipflops is very restricted and not (well) documented. You'll need to design the FPGA first and then the PCB. Also, the timing is more critical then when using a shifted clock! I posted some messages in this newsgroup on this topic before.

Expect a Spartan3 DDR design to run at 100MHz in speedgrade 4 and at

125MHz in a speedgrade 5 device.
--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.