• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 4 answers
  • Subscribers 101 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM4378: DDR3 trace length question

AM4378: using EMIF tool entering trace lengths "Routing Limit Exceeded"

cobsonchael
Mastermind 7910 points
Part Number: AM4378

 when trying to enter in the trace length values (which some art larger than 1") i get "Routing Limit Exceeded" from the tool "SPRAC70_AM437x_EMIF_CONFIGURATION_TOOL_V20. i get this anywhere i try to use 1 or greater as a value, even though i see the pre-loaded values are over 1. what am i doing wrong here?

  • 0
    TI__Guru 68950 points
    Try setting all the entries to 0, then input the trace length values for this board. If that doesn't work, send a snapshot of the error. After recreating the error here, it seemed to work better after zeroing everything out.

    Regards,
    James
  • 0 in reply to cobsonchael
    Mastermind 7910 points
    this seems to work ok in excel. i was using libre office with my ubuntu machine and that seems to be what has the issue
  • 0 in reply to cobsonchael
    TI__Guru 68950 points

    That is strange.  It may be an issue with LibreOffice and the data validation formulas we have put in.  I will have to look at this next week.

    In the meantime, i have attached a spreadsheet which now just gives an informational warning, but still allows you to proceed entering values.

    The data validation just looks for trace length values that exceed certain limits imposed by the design guidelines (eg, byte 0 microstrip+stripline length has to be <= 2.5in)

    Regards,

    james

    SPRAC70_AM437x_EMIF_Configuration_Tool_V20_routing_workaround.xlsx

  • 0 in reply to JJD
    TI__Guru 68950 points
    Did some checking, and i did identify some discrepancies in the data validation formulas for the trace lengths which was being interpreted differently in OfficeLibre. The fix will show up in the next EMIF tool release (excel spreadsheet v21).

    Thanks,
    James
  • 0 in reply to JJD
    Mastermind 7910 points

    looks like i spoke too soon: one of our trace lengths is a little over 3" in the stripline. i can't get it to accept anything over 2.5" even with everything else zero'd out. it seems like i can't go over 2.5" combined striplne/microstrip (for byte 0 anyway)

  • 0 in reply to cobsonchael
    TI__Guru 68950 points
    That would be violating the layout guidelines in the datasheet. Depending on which length you a talking about (CLK or DQSn), the layout guidelines in the datasheet impose maximum lengths for these traces.

    For CLK, check table 5-58 in the datasheet. You will see A1+A2 length = 2500mils, and every subsequent memory can be an additional 660mils further (A3)

    For DQS, check table 5-59. Max lengths are shown in Manhattan lengths, which if you refer back to Figure 5-54 for placement, you can see these would be 2500mils for the first byte, and so on.

    Regards,
    James
  • 0 in reply to JJD
    Mastermind 7910 points
    ok, so here is a question: if the fly-by topography that we used puts the high order bytes closer (byte 2 & 3 is first and then it goes to byte 0 & 1) does that violate the layout as well?

    our layout looks like ARM ->16 bit DDR3 bytes 2 and 3 -> 16 bit DDR bytes 0 and 1. i do not know why they are like that. the length given are:

    CLK, byte 0, microstrip: .291”
    CLK, byte 0, stripline: 3.106”
    CLK, byte 1, microstrip: Same as byte 0
    CLK, byte 1, stripline: “
    CLK, byte 2, microstrip: .291”
    CLK, byte 2, stripline: 2.457”
    CLK, byte 3, microstrip: Same as byte 2
    CLK, byte 3, stripline: “


    i should mention that i did not design the board so i will have to go back to our board guy with your answer.
  • 0 in reply to cobsonchael
    TI__Guru 68950 points
    I think you may still be OK, although your placement is not optimal. You are slightly violating the length to the first memory (total of 2.748, should be <= 2.5in).

    The byte lanes are independent, they don't necessarily have to correspond to the actual memory byte. So you can just plug in bytes 2&3 into 0&1 in the table, and so on. The information in Board Details tab is just checking the routing limitation and is not really used elsewhere in the spreadsheet. So your routing violation will not affect the rest of the configuration You will get an error because of the limitation above. Just re-adjust it back down to 2.5in.

    The h/w leveling should resolve the delays to each of the memories. If your board designer was diligent in the other board guidelines, i think you should be able to get things functional.

    Regards,
    James
  • 0 in reply to JJD
    Mastermind 7910 points
    well except that the reverse of the bytes seems to violate the layout rules as well. 2.457 + .291 = 2.748 > 2.5. do you think that will make a difference? if the tool doesn't allow me to enter in the values because they exceed the length should i just use the max lengths?
  • 0 in reply to cobsonchael
    TI__Guru 68950 points
    Yes, just use max lengths. The info in this particular tab isn't used in the rest of the configuration

    REgards,
    James