DDR or SDR ? Memory controller in FPGA

S

Sylvain Munaut

Guest
Hi,

I'd like to design a small board with a Spartan 3 and some Dynamic RAM memory.
Since I'd like not to be limited by memory bandwith, I was thinking to use DDR.

However I'm not an exepert in High speed board design and don't have big tool to simulate my board signal integrity, cross talk, ...

I've seen some "amateur" (in the good sense of the term) board with SDRAM and simple SDRAM controller in VHDL. However for DDR, not much.

So I'd like to know if it's possible to do one that would be clocked at 100Mhz DDR ( 200Mhz ) 32 bits, without eating 2000 slice of my FPGA for the DDR controller ... I'm willing to give about 500 slices for it.

Of course, I've seen Xilinx app notes, but they say to simulate it all with IBIS models and I have no clue ... So just by doing a careful routing of signals ( ensure same length for all signals, preferably short, with minimum vias ), should it be possible ? Any advice ?



Thanks,

Sylvain Munaut
 
Sylvain Munaut wrote:

Hi,

I'd like to design a small board with a Spartan 3 and some Dynamic RAM
memory. Since I'd like not to be limited by memory bandwith, I was
thinking to use DDR.

However I'm not an exepert in High speed board design and don't have big
tool to simulate my board signal integrity, cross talk, ...

I've seen some "amateur" (in the good sense of the term) board with SDRAM
and simple SDRAM controller in VHDL. However for DDR, not much.

So I'd like to know if it's possible to do one that would be clocked at
100Mhz DDR ( 200Mhz ) 32 bits, without eating 2000 slice of my FPGA for
the DDR controller ... I'm willing to give about 500 slices for it.

Of course, I've seen Xilinx app notes, but they say to simulate it all
with IBIS models and I have no clue ... So just by doing a careful routing
of signals ( ensure same length for all signals, preferably short, with
minimum vias ), should it be possible ? Any advice ?
For 100 Mhz this should be rather trivial. Biggest concern
is how many memory chips you decide to drive. e.g. what will
be your configuration for the 32 bits. Will you use a single
chip (not sure if they make them that wide), two 16 bit chips
or 4 8 bit chips.

If you go for 4 or more, it will be tough to do the layout
without proper tools and previous knowledge how to do it.

If you stick to two chips and follow all the regular
recommendations (short, balanced traces, etc) you shouldn't
have any problems.

Regards,
rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis


Thanks,

Sylvain Munaut
 
For 100 Mhz this should be rather trivial. Biggest concern
is how many memory chips you decide to drive. e.g. what will
be your configuration for the 32 bits. Will you use a single
chip (not sure if they make them that wide), two 16 bit chips
or 4 8 bit chips.

If you go for 4 or more, it will be tough to do the layout
without proper tools and previous knowledge how to do it.

If you stick to two chips and follow all the regular
recommendations (short, balanced traces, etc) you shouldn't
have any problems.
Thanks for your answer.

I was indeed planning 2 x 16 bits chips as I don't know any 32 bits ones.

I've also seen some reference to a micro app note about terminations, I'll have a look.

IIRC, the best way to connect two chips would be



Sylvain Munaut
 
Simon wrote:
Sylvain Munaut wrote:



For 100 Mhz this should be rather trivial. Biggest concern
is how many memory chips you decide to drive. e.g. what will
be your configuration for the 32 bits. Will you use a single
chip (not sure if they make them that wide), two 16 bit chips
or 4 8 bit chips.

If you go for 4 or more, it will be tough to do the layout
without proper tools and previous knowledge how to do it.

If you stick to two chips and follow all the regular
recommendations (short, balanced traces, etc) you shouldn't
have any problems.



Thanks for your answer.

I was indeed planning 2 x 16 bits chips as I don't know any 32 bits ones.

I've also seen some reference to a micro app note about terminations,
I'll have a look.

IIRC, the best way to connect two chips would be


(perhaps something missing ?)
Yes ;)
I meant that I should avoid T in the lines but instead put the chips inline. iow, the tracks go from fpga to first chip then from there to the second one. And avoid going from the fpga then split in two branch, one to chip1 the other to chip2.

I'm thinking of the same sort of thing - it depends on how much RAM you
want, but there's a Micron 1Mx32x4 chip I found (Farnell order #5088793)
that's a TSOP package that might be of interest...
That chip would be more that enough in fact I was planning for 8Mbytes. But with 32 bit width, I'll have 16Mb, that's ok.
But these are SDRam, not DDR. Well I'll see what I take because DDR seem harder to drive than SDR and I also'd like to spare space in the FPGA, else I won't have any space to put stuff that could use the extra bandwidth.


Sylvain Munaut
 
Sylvain Munaut wrote:

For 100 Mhz this should be rather trivial. Biggest concern
is how many memory chips you decide to drive. e.g. what will
be your configuration for the 32 bits. Will you use a single
chip (not sure if they make them that wide), two 16 bit chips
or 4 8 bit chips.

If you go for 4 or more, it will be tough to do the layout
without proper tools and previous knowledge how to do it.

If you stick to two chips and follow all the regular
recommendations (short, balanced traces, etc) you shouldn't
have any problems.


Thanks for your answer.

I was indeed planning 2 x 16 bits chips as I don't know any 32 bits ones.

I've also seen some reference to a micro app note about terminations,
I'll have a look.

IIRC, the best way to connect two chips would be
(perhaps something missing ?)

I'm thinking of the same sort of thing - it depends on how much RAM you
want, but there's a Micron 1Mx32x4 chip I found (Farnell order #5088793)
that's a TSOP package that might be of interest...

Simon.
 
Sylvain Munaut wrote:
Simon wrote:
Sylvain Munaut wrote:
Thanks for your answer.

I was indeed planning 2 x 16 bits chips as I don't know any 32 bits ones.

I've also seen some reference to a micro app note about terminations,
I'll have a look.

IIRC, the best way to connect two chips would be


(perhaps something missing ?)

Yes ;)
I meant that I should avoid T in the lines but instead put the chips inline. iow, the tracks go from fpga to first chip then from there to the second one. And avoid going from the fpga then split in two branch, one to chip1 the other to chip2.

I'm thinking of the same sort of thing - it depends on how much RAM you
want, but there's a Micron 1Mx32x4 chip I found (Farnell order #5088793)
that's a TSOP package that might be of interest...

That chip would be more that enough in fact I was planning for 8Mbytes. But with 32 bit width, I'll have 16Mb, that's ok.
But these are SDRam, not DDR. Well I'll see what I take because DDR seem harder to drive than SDR and I also'd like to spare space in the FPGA, else I won't have any space to put stuff that could use the extra bandwidth.
Even more important than avoiding T connections, is keeping them short,
very short. You can even drive a star arrangement if you can keep all
traces to about 1 inch (2.5 cm) or so. The reflections are then a small
fraction of the rise time and will not be significant. Or you can make
every memory pin a separate net and use simple series resistors (which
can be integrated in some FPGAs) on the outputs. Point to point drivers
are very simple and hard to screw up.

Also, if you are at all concerned about a long life for your product,
you should go with DDR. SDRAM is already on the way down the curve and
will only get more expensive in the future (unless we have another bust
cycle). 32 bit parts are niche parts like most SRAM, 16 bit parts are
more mainstream, but not quite jellybean while the 8 bit parts which are
used widely in PCs are fully commodities which will be the low cost per
bit of any memory. You can even get them in extra small packages (which
are used for laptops). I don't know if any of this is a consideration
for you.

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 
Sylvain Munaut wrote:
<snip>
That chip would be more that enough in fact I was planning for 8Mbytes.
But with 32 bit width, I'll have 16Mb, that's ok.
But these are SDRam, not DDR. Well I'll see what I take because DDR seem
harder to drive than SDR and I also'd like to spare space in the FPGA,
else I won't have any space to put stuff that could use the extra
bandwidth.
With wider memory, you get more Bytes/ns, and I would suggest a look
at std Sync SRAM, as well as the Celluar PSRAM from Micron, as these
are getting to this Size in a single device.
Package may be more an issue ?
A single RAM device will be much easier to route, than many devices.
-jg
 
Hi

Even more important than avoiding T connections, is keeping them short,
very short. You can even drive a star arrangement if you can keep all
traces to about 1 inch (2.5 cm) or so. The reflections are then a small
fraction of the rise time and will not be significant. Or you can make
every memory pin a separate net and use simple series resistors (which
can be integrated in some FPGAs) on the outputs. Point to point drivers
are very simple and hard to screw up.
I'll try to keep as short and matched as I can.

I was a little worried because in all datasheet/application notes/... they say to simulate with IBIS models. I've tried the HyperLynx demo and that's sure looks a good tool. But I can't afford a 18000$ soft ... (and the demo is VERY limited).


Also, if you are at all concerned about a long life for your product,
you should go with DDR. SDRAM is already on the way down the curve and
will only get more expensive in the future (unless we have another bust
cycle). 32 bit parts are niche parts like most SRAM, 16 bit parts are
more mainstream, but not quite jellybean while the 8 bit parts which are
used widely in PCs are fully commodities which will be the low cost per
bit of any memory. You can even get them in extra small packages (which
are used for laptops). I don't know if any of this is a consideration
for you.
I'm interested in "long" life yup ;)
I was planning to use 16bits parts because 32bits are too rare/expensive/... And 8 bits, you need 4 to make a 32bits bus. That becomes a lot harder to route and get it right.


Sylvain
 
Jim Granville wrote:
Sylvain Munaut wrote:
snip

That chip would be more that enough in fact I was planning for
8Mbytes. But with 32 bit width, I'll have 16Mb, that's ok.
But these are SDRam, not DDR. Well I'll see what I take because DDR
seem harder to drive than SDR and I also'd like to spare space in the
FPGA, else I won't have any space to put stuff that could use the
extra bandwidth.


With wider memory, you get more Bytes/ns, and I would suggest a look
at std Sync SRAM, as well as the Celluar PSRAM from Micron, as these
are getting to this Size in a single device.
Package may be more an issue ?
A single RAM device will be much easier to route, than many devices.
-jg
Package is not a concern.
What concerns me with SyncSRAM & Cellular PSRAM would be the higher cost. But I'll have a look.


Sylvain Munaut
 
Sylvain Munaut wrote:
Hi

Even more important than avoiding T connections, is keeping them short,
very short. You can even drive a star arrangement if you can keep all
traces to about 1 inch (2.5 cm) or so. The reflections are then a small
fraction of the rise time and will not be significant. Or you can make
every memory pin a separate net and use simple series resistors (which
can be integrated in some FPGAs) on the outputs. Point to point drivers
are very simple and hard to screw up.

I'll try to keep as short and matched as I can.

I was a little worried because in all datasheet/application notes/... they say to simulate with IBIS models. I've tried the HyperLynx demo and that's sure looks a good tool. But I can't afford a 18000$ soft ... (and the demo is VERY limited).
Yes, I feel your pain. Simulation is a good idea, but there is more
than one way to skin a cat. A simulation is just a handy way to save
some work, but if you keep your designs very simple and follow the
rules, you won't have any real trouble. You can even use series
termination with multiple receivers as long as the signal is not a clock
and you have your stubs total no more than an inch. Using two chips,
you can put them on opposite sides of the board and get nearly no stub
length.


Also, if you are at all concerned about a long life for your product,
you should go with DDR. SDRAM is already on the way down the curve and
will only get more expensive in the future (unless we have another bust
cycle). 32 bit parts are niche parts like most SRAM, 16 bit parts are
more mainstream, but not quite jellybean while the 8 bit parts which are
used widely in PCs are fully commodities which will be the low cost per
bit of any memory. You can even get them in extra small packages (which
are used for laptops). I don't know if any of this is a consideration
for you.

I'm interested in "long" life yup ;)
I was planning to use 16bits parts because 32bits are too rare/expensive/... And 8 bits, you need 4 to make a 32bits bus. That becomes a lot harder to route and get it right.
I don't know that 16 bit chips are or will be hard to buy. I just know
that they are not as common as the 8 bit chips. But then we are using
the 16 bit SDRAM chips on a board that we expect to make for at least 5
years!

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
 

Welcome to EDABoard.com

Sponsor

Back
Top