Trace length for SDRAM lines?

How important is the trace length balance on signal lines to SDRAM?  I 
recall coming across a  document saying that the trace lengths needed to 
have less than .5 inch difference from shortest to longest.  But I think 
that was a DDR2 doc.

I see some very obvious S curves in the lines on an Atmel SAM9261 EK board 
that uses PC100 speed SDRAMS.  We will be using similar parts on a new 
design.  Someone else I have been chatting with says not to worry about it.

It doesn't seem to be a very straight forward thing to do, although possibly 
some pcb layout software can do this automatically.

Does anyone have strong support for using or not using length balancing?  If 
it's important, processor is the SAM9261 and there will be two 16 bit SRAMS 
(for 32 bit wide data path) and 1 16bit Flash.

Scott

Not Really Me wrote:

> How important is the trace length balance on signal lines to SDRAM?  I 
> recall coming across a  document saying that the trace lengths needed to 
> have less than .5 inch difference from shortest to longest.  But I think 
> that was a DDR2 doc.
> 
> I see some very obvious S curves in the lines on an Atmel SAM9261 EK board 
> that uses PC100 speed SDRAMS.  We will be using similar parts on a new 
> design.  Someone else I have been chatting with says not to worry about it.
> 
> It doesn't seem to be a very straight forward thing to do, although possibly 
> some pcb layout software can do this automatically.
> 
> Does anyone have strong support for using or not using length balancing?  If 
> it's important, processor is the SAM9261 and there will be two 16 bit SRAMS 
> (for 32 bit wide data path) and 1 16bit Flash.
> 
> Scott
> 
> 
> 
I would go with the SDRAM manufacturer's recommendations on this.  One 
of the critical enabling ideas behind SDRAM is that it regenerates the 
clock back to the processor, which uses the SDRAM's clocks to drive it's 
receive state machine.  This only works if all the pins act the same 
way, which only happens if they all see similar loads.

I expect that at lower than maximum speeds and at benign temperatures 
you can get away with violating this to some extent -- after all, 
there's got to be some margin in there anyway.  However, I'd rather 
spend a known amount of time laying out these traces by hand than I 
would spending an unknown amount of time discovering whether dissimilar 
traces would work well enough over temperature and part-part variations. 
  Better yet, I'd rather do it by the manufacturer's guidelines without 
drama rather than having things fail in the field.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Not Really Me wrote:
> How important is the trace length balance on signal lines to SDRAM?  I 
> recall coming across a  document saying that the trace lengths needed to 
> have less than .5 inch difference from shortest to longest.  But I think 
> that was a DDR2 doc.
> 
> I see some very obvious S curves in the lines on an Atmel SAM9261 EK board 
> that uses PC100 speed SDRAMS.  We will be using similar parts on a new 
> design.  Someone else I have been chatting with says not to worry about it.
> 
> It doesn't seem to be a very straight forward thing to do, although possibly 
> some pcb layout software can do this automatically.
> 
> Does anyone have strong support for using or not using length balancing?  If 
> it's important, processor is the SAM9261 and there will be two 16 bit SRAMS 
> (for 32 bit wide data path) and 1 16bit Flash.
> 
> Scott
> 
> 
> 

SDRAMs (and their variants) require a timing budget [as do many other 
things]. I'm assuming you are using single data rate SDRAM, so let's set 
up the budget:

Things you need to know:

1. Clock to address/command skew from the controller
2. Clock to data skew from the controller (write)
3. Valid window at the controller (read)
4. Clock/address/command valid timing at the SDRAM
5. Clock to data skew at the SDRAM (read)
6. Clock to data valid timing at the SDRAM (write)

7. An app note with the details of timing budgets (Micron certainly has 
one, not sure about the other manufacturers).

There are other things - CAS latency for example, which address line is 
used for precharge commands and so forth.

So you'll need a thorough datasheet for both (SDRAM is a JEDEC standard, 
the number of which escapes me at present, but the best datasheets are 
done by Micron). I have no idea of the controller you are using, so 
you'll have to get those numbers.

Choose the appropriate SDRAM, and then do the budget. Read timing is 
usually most difficult as the SDRAM will drive the data lines in 
response to clock, so roundtrip time becomes important.

Get the numbers / parts and then the allowable relative delays can be 
calculated. Sometimes it's an inch. Sometimes it's 1/20 of that - it 
depends on specifics.

At 100MHz, properly terminated and impedance controlled tracks are a 
must, incidentally.

The last time I did one of these was for DDR, and it took 2 days (but I 
was calculating two independent systems on the same PCB).

Cheers

PeteS

Not Really Me wrote:
> How important is the trace length balance on signal lines to SDRAM?  I
> recall coming across a  document saying that the trace lengths needed to
> have less than .5 inch difference from shortest to longest.  But I think
> that was a DDR2 doc.
>
> I see some very obvious S curves in the lines on an Atmel SAM9261 EK board
> that uses PC100 speed SDRAMS.  We will be using similar parts on a new
> design.  Someone else I have been chatting with says not to worry about it.
>
> It doesn't seem to be a very straight forward thing to do, although possibly
> some pcb layout software can do this automatically.
>
> Does anyone have strong support for using or not using length balancing?  If
> it's important, processor is the SAM9261 and there will be two 16 bit SRAMS
> (for 32 bit wide data path) and 1 16bit Flash.

I have never heard anyone say that it was important to balance trace
lengths to SDRAMS.  In general it is important to keep trace length as
short as possible since that will minimize delays and improve signal
integrity.  The only possible issue with relative timing on SDRAM
traces is the length of the clock line relative to the other signal
lines.  If the clock line is significantly longer than the other signal
traces it could cause the signals to violate the hold time at the
SDRAM.  But this would be a reach depending on the parts.

The specified timing for each of the parts is at the pins of that part.
 You have to consider how trace delay affects your timing at the other
end of the wire.  For example, all of the signals flow from the
controller to the SDRAM other than the data bus (which goes both ways)
and possibly the clock.  The chips I have worked with generated the
clock so that flowed the same as the other signals.  When you read from
the SDRAM, the clock has to leave the controller and travel to the
SDRAM, then the data is clocked out and has to travel back to the
controller.  This round trip delay has to be considered in the timing
at the controller.  If the clock is sourced from a central point with
equal delays to both devices then you only need to consider the delay
on the data signals.  But this does not require matching of any paths.


It is so much easier to work with maximum delays than it is to try to
match trace lengths.  Do a timing analysis and see what range the trace
delays can be.  Be sure to include a figure for the range of the clock
trace delay.

rickman wrote:
> Not Really Me wrote:
>> How important is the trace length balance on signal lines to SDRAM?  I
>> recall coming across a  document saying that the trace lengths needed to
>> have less than .5 inch difference from shortest to longest.  But I think
>> that was a DDR2 doc.
>>
>> I see some very obvious S curves in the lines on an Atmel SAM9261 EK board
>> that uses PC100 speed SDRAMS.  We will be using similar parts on a new
>> design.  Someone else I have been chatting with says not to worry about it.
>>
>> It doesn't seem to be a very straight forward thing to do, although possibly
>> some pcb layout software can do this automatically.
>>
>> Does anyone have strong support for using or not using length balancing?  If
>> it's important, processor is the SAM9261 and there will be two 16 bit SRAMS
>> (for 32 bit wide data path) and 1 16bit Flash.
> 
> I have never heard anyone say that it was important to balance trace
> lengths to SDRAMS.

Only insofar as the tracks must be length matched to meet the timing 
budget. I've never had an issue with drive levels (with associated 
signal loss) due to PCB issues at these (relatively low) frequencies. 
The edge rates are typically well above the skin effect knee, though, so 
a long track might induce extra jitter as well as low pass filtering the 
edges themselves.

   In general it is important to keep trace length as
> short as possible since that will minimize delays and improve signal
> integrity.  The only possible issue with relative timing on SDRAM
> traces is the length of the clock line relative to the other signal
> lines.  If the clock line is significantly longer than the other signal
> traces it could cause the signals to violate the hold time at the
> SDRAM.  But this would be a reach depending on the parts.
> 
> The specified timing for each of the parts is at the pins of that part.
>  You have to consider how trace delay affects your timing at the other
> end of the wire.  For example, all of the signals flow from the
> controller to the SDRAM other than the data bus (which goes both ways)
> and possibly the clock.  The chips I have worked with generated the
> clock so that flowed the same as the other signals.  When you read from
> the SDRAM, the clock has to leave the controller and travel to the
> SDRAM, then the data is clocked out and has to travel back to the
> controller.  This round trip delay has to be considered in the timing
> at the controller.  If the clock is sourced from a central point with
> equal delays to both devices then you only need to consider the delay
> on the data signals.  But this does not require matching of any paths.
> 
> 
> It is so much easier to work with maximum delays than it is to try to
> match trace lengths.  Do a timing analysis and see what range the trace
> delays can be.  Be sure to include a figure for the range of the clock
> trace delay.
> 

Well, when setting up the rules for moderate to high speed interfaces 
such as this, I use a mixture of maximum trace lengths and relative 
match (trace to trace difference) depending on the signals. 100MHz SDRAM 
signalling is not particularly high speed although the edge rates are.

As an example, I set the maximum round trip delay for SDRAM which sets 
the maximum trace length. Then I analyze the timing windows for length 
match between Address/command <-> clock and data <-> clock. As I noted, 
those may be quite large margins, but I still specify it to prevent 
autorouters from doing weird things on the signal or at least tell me it 
can't route automatically with the rules I have set (it happens quite 
frequently).

This is a case where an ounce of prevention is worth a ton of cure :)

Cheers

PeteS