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.


Reply to
Not Really Me
Loading thread data ...

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
 Click to see the full signature
Reply to
Tim Wescott

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)

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



Reply to

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.

Reply to

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

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 :)



Reply to

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.