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

Mounard Le Fougueux <blinkingCursor@NonEventHorizon.com> wrote:

>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.

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

On Jan 31, 9:35 am, n...@puntnl.niks (Nico Coesel) wrote:
> 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.

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

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


On Jan 31, 10:13 am, "Tommy Thorn" <tommy.th...@gmail.com> wrote:
> On Jan 31, 9:35 am, n...@puntnl.niks (Nico Coesel) wrote:
>
> > 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.
>
> 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

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


On Jan 31, 8:39 am, Mounard Le Fougueux
<blinkingCur...@NonEventHorizon.com> wrote:
> 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

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:45c10209.1209218664@news.kpnplanet.nl...
> pbFJKD@ludd.invalid wrote:
>
<snip>
>>
>>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..
>>
>
> Some memories can operate down to 83MHz. A Spartan 3 series speedgrade
> 4 FPGA can be interfaced with DDR memory at 100MHz without problems.

<snip>

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 

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.

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


On Feb 1, 5:55 pm, Ray Andraka <r...@andraka.com> wrote:
> 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.

Peter Alfke wrote:

[snip]

> Therefore, in the Virtex-5 DDR/DDR2 SDRAM memory controller, we now
> provide multiple-bank support to increase the efficiency of data
> throughput. 

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


---
Joe Samson
Pixel Velocity

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


On Feb 5, 10:18 am, "Peter Alfke" <p...@xilinx.com> wrote:
> 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
>
> On Feb 1, 5:55 pm, Ray Andraka <r...@andraka.com> wrote:
>
> > 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.