1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Trace length for SDRAM lines?

Discussion in 'Embedded' started by Not Really Me, Dec 19, 2006.

  1. 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, Dec 19, 2006
    #1
    1. Advertisements

  2. Not Really Me

    Tim Wescott Guest

    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
     
    Tim Wescott, Dec 19, 2006
    #2
    1. Advertisements

  3. Not Really Me

    PeteS Guest

    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
     
    PeteS, Dec 19, 2006
    #3
  4. Not Really Me

    rickman Guest

    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, Dec 20, 2006
    #4
  5. Not Really Me

    PeteS Guest

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

    Cheers

    PeteS
     
    PeteS, Dec 20, 2006
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.