DDR SDRAM Trace matching

[yy7d6]

Hi,
What is the trace mismatch tolerance of DQ and DQS signals of
200Mhz-DDR. Should i just keep them within 2.5" and it will be ok?

 

[PeteS]

Hi,
What is the trace mismatch tolerance of DQ and DQS signals of
200Mhz-DDR. Should i just keep them within 2.5" and it will be ok?

To calculate the trace mismatch you can have, you'll need to do a proper
timing budget. It's more than just the DQ set (which includes DQS) and
you have to run the budget for both read and write (they are different).

'Keeping them all within 2.5"' will _not_ do it. I almost had a C|N>K
moment when I read that.

Micron has a nice app note describing the process. Post what you are
using (controller, memory type etc) and we might help guide you through
the process.

Cheers

PeteS

 

[Didi]

Micron has a nice app note describing the process. Post what you are

using (controller, memory type etc) and we might help guide you through
the process.

Actually most if not all about length matching in these application
notes
is just scaremongering. At apr. 150 pS/inch, doing even a 1/2" inch
length
mismatch will add 75 pS of skew - hardly an issue at 200 MHz DDR.
To relate to another recent thread here, sometimes even the plain
arithmetics can be fairly helpful... .

Dimiter

 

[PeteS]

Actually most if not all about length matching in these application
notes
is just scaremongering. At apr. 150 pS/inch, doing even a 1/2" inch
length
mismatch will add 75 pS of skew - hardly an issue at 200 MHz DDR.
To relate to another recent thread here, sometimes even the plain
arithmetics can be fairly helpful... .

Dimiter

Hi Dimiter

Well, it depends.

At 200MHz, (400MT/s), the maximal data window is 2.5nS. When one
subtracts a typical 0.7nS for the DDR controller skew (that depends on
the controller, of course) and an access window of +/- 0.7nS, subtract
the DQ jitter [and a number of other parameters] and board jitter
(mostly deterministic) and that 75pS is no longer a small matter.

The OP can get a lot of free support information here:
http://www.micron.com/support/designsupport/tools/ddrtoolbox/ddrtoolbox.aspx

Although one _may_ get away with 0.5 inch mismatch, it probably won't be
guaranteed timing across temperature and parts. I like to design for
guaranteed margins. The last time I designed DDR onto a board (not
DIMM/SODIMM) I ended up with 120pS of guaranteed margin. SODIMM can be
just as tight.

For the OP - it's not just the DQ set - the timing budget has to be set
against the Clock pair -> Address/control, Clock pair -> DQ set. As the
strobes are driven from the memory diring a write cycle, you have to
subtract the outbound time from your receive data window. I strongly
suggest you read a typical datasheet and the file 'Plat7Justin.pdf' on
the page referenced, at the very least.

Cheers

PeteS

Cheers

PeteS

 

[Ancient_Hacker]

Hi,
What is the trace mismatch tolerance of DQ and DQS signals of
200Mhz-DDR. Should i just keep them within 2.5" and it will be ok?

Look at a PC motherboard. Do you think they put in all those squiggles
just for the heck of it?

 

[yy7d6]

Hi,
I use spartan-3 fpga for ddr controller, also for info i'm using the
SSTL with DCI. I had a simulation of 10 inch trace and i got a couple
of hundred of ps of skew, why keeping the trace lengths <2.5inch will
not do? Is it ok to have at least 1/3 data window of total data period.
BTW, my main concern is to identify the effective trace length from the
fpga to the ddr address/ and dQ lines...

--yy

 

[PeteS]

Hi,
I use spartan-3 fpga for ddr controller, also for info i'm using the
SSTL with DCI. I had a simulation of 10 inch trace and i got a couple
of hundred of ps of skew, why keeping the trace lengths <2.5inch will
not do? Is it ok to have at least 1/3 data window of total data period.
BTW, my main concern is to identify the effective trace length from the
fpga to the ddr address/ and dQ lines...

--yy

I understand you want to read the minimum necessary.

The reality is that DDR timing budgets require a reasonable amount of
time to calculate.

Read the app notes on the page I referenced and then ask again,
referencing the appropriate timing results from post PAR timing on your
FPGA.


Cheers

PeteS