• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 102 subscribers
  • Views 1079 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.

keystone II DDR3 layout constraint issue

shervin hojati
Intellectual 350 points

We have designed our custom SBC based on Advantech EVM XTCIEVMK2X and using 6638K2H12 SOC. We are in the process of constraining our layout for the second time.

According to DDR3 guidlines DDR3 Design Requirements for KeyStone Devices May 2014, the min skew between "Coomand delay" and "data delay"  on any SDRAM must meet a MIN delay of 325 ps. Looking at the advantech EVM we see the routing violates this requirement As we see approximately a delay of 144 ps. Yet the eval board seems to work fine. We need assistance for our layout constraints, as this is our second attempt.

  • 0
    TI__Mastermind 43660 points
    Hello Shervin,

    Which version of EVM you are referring ?

    I believe Advantech has followed the design guidelines and set the layout constraints accordingly during their design. Could you please elaborate how you are finding the delay between command and data, also please mention the exact signal group.

    Regards,
    Senthil
  • 0 in reply to Senthilkumar Srinivasan
    Intellectual 350 points

    Hi Senthil,

    We have used the K2H_K2EVM-HK Rev 3.0 as reference. The layout file we have is 19C2830502-01-JOB.brd for the Advantech.  A report on the routing lengths of the DDR3B traces is attached.

    U39 is the first DDR3 memory that DDR3B signals from the Keystone reach. Let us look at the clock signal on line 54: the trace length is 2947.95 mils.  The data line from Keyston pin AK39 to U39 pin E3 (line 251 in the report) is 1579.24 The skew between these two lines is:  2947.95 – 1579.24 = 1368.71 mils

    With 180 ps/in, this skew translates to (1368.71/1000)*180 ps = 246.37 ps.  The TI document SPRABI1B Table 18 states that minimum write leveling skew for DDR3-1600 is 325 ps.

    Obviously the skew violates the minimum requirement.

    Could there be another interpretation of the document?

    Regards,

    Shervin

     

  • 0
    TI__Mastermind 42545 points

    Hi Shevin,

    The skew requirement you are referring to appears in section 4.3.1.10 titled 'Write Leveling Limit Impact on Routing – KeyStone I'. Since you are routing a DDR interface for a KeyStone II part, this requirement doesn't apply as shown by the routing of the EVM. 

    Regards,

    Bill

  • 0 in reply to Bill Taboada
    Intellectual 350 points
    Bill,
    What are the guidelines for keystone II? We could not find any references, and we assumed that the same document for Keystone I applies.
    Can you point to any documents?

    Regards,
    Shervin
  • 0 in reply to shervin hojati
    TI__Mastermind 42545 points
    Hi Shervin,
    The same document is used for KeyStone I and KeyStone II. If a requirement is specific to only one family, it is specified in the header of the section. If not the requirement applies to both families.
    Regards,
    Bill
  • 0 in reply to Bill Taboada
    TI__Guru**** 1225701 points
    Hi Bill,

    I have two follow-up questions. Is there a stated upper and lower limit skew similar to what is in Table 18 for Keystone II? I be missing it somewhere in the document. I was looking for something similar in section 4.3.2.9

    Secondly, following the EVM should be the way to proceed forward without worrying of breaking any requirement/specification here, correct?

    Thanks and have a great weekend!
    Nic
  • 0 in reply to _nic
    TI__Mastermind 42545 points
    Hi Nic,

    There are not upper or lower limits specified for the KeyStone II implementation. The KeyStone I DDR PHY was only able to level across a signal clock period so limits were needed to ensure that leveling completed correctly. The KeyStone II DDR PHY was improved to allow leveling across multiple clock periods. This eliminated the length differential requirement between command and data. Note that even the KeyStone I requirements are fairly easy to meet if the invert clock is used.

    Following the EVM is reasonable but very difficult to accomplish. Remember that the impedance requirement makes the trace width dependent on the stack-up of the board. If you are using a different stack-up the trace width may be effected which could cause the spacing requirements to be violated. In addition, the routing can't just 'look like' the EVM routing. The length matching must be performed to ensure that the requirements are met. Using the stack-up for the EVM and keeping the byte lanes on the same layers as the EVM is a good start but this may not meet the requirements for your design.

    Regards,
    Bill
  • 0 in reply to Bill Taboada
    Intellectual 350 points

    Bill,

    We have already layed out our PCB with keystone I constraints:
    min skew between data line and command lines of 2.1".
    Would this work for Keystone II or we need to make modifications.

    thanks

  • 0 in reply to shervin hojati
    TI__Mastermind 42545 points
    Hi Shervin,
    You shouldn't have to make any changes. The KeyStone II device should be able to work with the skew you've created.
    Regards,
    Bill
  • 0 in reply to Bill Taboada
    Intellectual 350 points
    Bill,
    To be sure I would like to verify that we understand the references in the
    to fly-by groups constraints.

    Do we need to have the clk pairs, Address and command lines, and control lines
    all be length matched to +/-20 mils since they are all fly-by nets?

    Thanks
  • 0 in reply to shervin hojati
    TI__Mastermind 42545 points

    Hi Shervin,

    To be specific, the guideline states the following.

    • All nets in the address and command fly-by groups must be length-matched from the controller to each SDRAM separately within +/- 20 mils of the clock along the same route.

    This is an important distinction. The length must be matched from the SOC to the memory for all address/command signals within +/-20mils and this measurement must be checked for each of the memories on the flyby chain.  As these signals are routed down the flyby chain there will be a stub between the flyby trace and the ball of the memory for each device. Do not include the stub in the measurement for devices farther down the chain.

    In the image below the length from the SOC to memory 1 is L1+S1, the length from SOC to memory 2 is L1+L2+S2, the length from SOC to memory 3 is L1+L2+L3+S3, and the length from SOC to memory 4 is L1+L2+L3+L4+S4. You need to match these lengths for all the flyby signals.

    Regards,Bill