• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 101 subscribers
  • Views 1650 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.

TMS320C6678: clock routing for DDR3

Naoki Kawada
Guru 19890 points
Part Number: TMS320C6678

Hi

My customer is now trying to launch the DDR3 on their new PCB design. They have 4 DDR parts (2Gb, x16, 666Mhz) to achieve 64bit bus. Their problem is that the lower 32bit does not work correctly (upper side looked fine). The STATUS register indicated 0x40000074 and it seems like having the issue in the leveling. They are now reviewing :

And they found the clock is routed in the order of byte lane 0, 1, 2, .... In the actual HW, it has been in reverse order. Is this critical in the HW leveling ?

Best Regards,
NK

  • 0
    TI__Guru**** 161600 points
    Hi,

    I've notified the team. They will post their feedback directly here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Mastermind 46460 points

    Naoki,

    Please post the length-matching report and the completed PHY_CALC and REG_CALC worksheets.  More background is available at this DDR3 interface commissioning wiki:

    http://processors.wiki.ti.com/index.php/KeyStone_I_DDR3_Interface_Bring-up

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points

    Hi Tom,

    Thanks for your reply. I`ve shared the sheets as attached. I`m asking to the customer about the length matching sheet. I`ll get back you later.

    Best Regards,
    NK

    3113.DDR3 PHY Calc v11.xlsx

    4265.DDR3 Register Calc v4.xlsx 

  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    The length-matching report is the item that I need first.  Please provide it when available.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points

    Here is length matching report. Could you double check ?

    Best Regards,
    NK

    length-matching.xlsx

  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    The data provided is sufficient to validate the Data Group routing.  It is not sufficient for Address, Command and Control group routing.  It is not sufficient to list the pin-to-pin length between subsequent SDRAM devices.  This is usually a combination of stubs and vias.  The length matching requirement requires that you accumulate the length from the Controller (DSP) to each of the SDRAM memories.  This is not the same as adding 2 sets of number from the previously provided table.  Please have this information provided.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points

    Hello Tom,

    Thank you for your reply.
    Ok, length-matching requires the information for the connection between DSP to each DDR3, rather than each DDR3s. I`ll ask the same to the customer, but could you clarify what is intended by :

    Tom Johnson 16214 said:
    This is not the same as adding 2 sets of number from the previously provided table.  Please have this information provided.

    Best Regards,
    NK

  • 0 in reply to Naoki Kawada
    Guru 19890 points

    Hi Tom,

    Here is revised length matching report. Please see "connection from DSP perspective" sheet.

    Best Regards,

    NKlength-matching_1.xlsx

  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    Unfortunately, it appears that they simply summed the lengths from the different sections of the previous report.  This is what I was warning was not acceptable.  Unless all fly-by nets are routed on the same layer as the SDRAMs, the routed length from the controller to each SDRAM will not be equal to the sum of the net lengths between each SDRAM.  The segments need to be summed from the controller to each SDRAM.

    Tom

  • 0 in reply to Tom Johnson 16214
    TI__Mastermind 46460 points

    Naoki,

    I added a draft checklist to the end of the wiki page that I previously referenced.  It contains detailed instructions to assist understanding the length match requirements for the fly-by nets.

    http://processors.wiki.ti.com/index.php/KeyStone_I_DDR3_Interface_Bring-up

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points

    Thanks, Tom. The sheet you suggested was very helpful. My customer filed their configurations as attached. Can you see any issue in length-matching ?

    KeyStone DDR3 Length Rules Template v1p0_20180604.xlsx

    Just a question, but what does VTT stab affect to DDR3 behavior ?

  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    The fly-by nets have stubs at every SDRAM.  Every stub creates a reflected signal.  Part of the careful length control is to manage these reflections.  Having the VTT routing stubs also of similar length results in consistent signal integrity across all fly-by nets.

    Tom

  • 0 in reply to Tom Johnson 16214
    TI__Mastermind 46460 points

    Naoki,

    The lengths in the latest spreadsheet look good.  All of the recommendations are met.  Now that they have measured the actual fly-by routing length to each SDRAM, they need to update the PHY_CALC worksheet with the corrected clock lengths to each SDRAM.

    I do have a few comments about the length matching worksheet.  They did not update the net names to match with their design.  It took me longer to cross-check.  I expect that if they need to refer back to this in the future, this will cause confusion.  I recommend that they upate the net names too.  Also, it does not appear that they updated the fly-by stub lengths to each SDRAM.  The table still contains the template values.  It is important that the stub lengths are properly managed.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points
    Tom,

    Ok, I suggested the same to the customer. As for net-name, yes, the was typo but the filed values themselves were actually correct.
    They would try the revised register set. Let you know the result later, but in the meanwhile, do you have any other issues / suspicions on the sheet ? If in length-matched and correct register set used, the issue should not happen even if the fly-by routing is in reverse order... Correct ? Or, should we move to normal order for next assembly ?

    Best Regards,
    NK
  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    That was the original question.  I apologize for not answering previously.  The fly-by order is not significant.  All leveling logic operates individually for each byte lane.  The important part is making sure the PHY_CALC worksheet is properly filled out so that the correct routing skew and round trip delay calculations are correct for each byte lane.

    Tom

  • 0 in reply to Tom Johnson 16214
    Guru 19890 points

    Hi Tom,

    I got the feedback from the customer. Yes, they worked out with revised register values. Thank you for your support.

    Lastly, One more clarification -- The fly-by order is not significant, but the recommendation is still in normal order specified in DDR3 Design Requirements for KeyStone Devices(SPRABI1C). Correct ? The customer is wondering if the reason maybe the description of 6.3.1.9. They are saying the better skew margin in normal order rather than reverse order.

    Any comment on this ?

    Best Regards,
    NK

  • 0 in reply to Naoki Kawada
    TI__Mastermind 46460 points

    Naoki,

    These are independent topics.  As it said previously, the order is not significant.  However, they must be routed in a fly-by topology and the length matching rules must be met.  This then provides proper initial values from the PHY_CALC worksheet.

    The other topic referenced is about the write leveling skew calculation.  The basic assumption with all write leveling is that the fly-by (ADDR, CMD, CNTL, CLK Groups) track length from the Controller to each SDRAM is longer than the Data Group track length to that SDRAM.  This supports the PHY leveling logic which delays the launch of the Data Group signals such that they arrive at the SDRAM at the same time as the Fly-by Group signals.  Again, this is independent for each byte lane.  This requirement is not affected to teh Fly-by routing order.

    Tom