• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 132 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM62D-Q1: Help interpreting DDR-MARGIN-FW results for pass vs. fail criteria

Jay Coggin
Prodigy 40 points

Part Number: AM62D-Q1
Other Parts Discussed in Thread: SYSCONFIG

We are running the DDR-MARGIN-FW tool suite v1.9.0 to evaluate the DDR performance on our custom board based on the AM62D-Q1. So far, we've been successful running the read test, acquiring the measurement logs, and generating the PDF test reports with the included python script. Now, we are trying to establish pass vs. fail criteria for our board using these test reports, but it's not explicit from any documentation we found how to interpret these reports or relate them back to requirements for safe operation. So below is how we are currently interpeting them:

In the LPDDR4 Guidelines for AM62D App Note, Table 3-3 specifies the eye for READ as a diamond with a minimum width and height for a given DDR clock speed. I'm taking these as the spec to meet for our read measurements.

In a simple interpretation of the generated report, I'm guessing our "Worst Delta mV" from the Overview section should be above Read eye mask VdIVW from Table 3-3, and "Worst Delta UI" should be above Read eye mask TdIVW in Table 3-3. Is that a correct interpretation?
 
Assuming it is, our board fails on the majority of DQ lines at our planned DDR speed of 1866MHz. If we lower the speed to 1600MHz, we pass across all DQ lines relative to the 1600MHz thresholds in Table 3-3.
 
As a sanity check, I ran the read test on my AM62D EVM using the default EVM DDR configuration. Interestingly, it does not pass this criteria at 1866MHz either. It does appear the voltage margin is stronger on the EVM relative to our board, but both the EVM and our board are bottleknecked by the eye width not meeting spec. I'll attach a PDF report from both the EVM and our board @ 1866MHz.
 
If my interpretation of these plots is not correct, could you provide any insight on establishing pass/fail criteria? If it is correct, what is the severity of a measurement below the threshold? We have been using our board and the EVM at the 1866MHz clock speed with no perceived issues thus far. Is there any detection and retry mechanism that could be masking these errors?
 
One note on the attached reports: In order to establish a more apples-to-apples comparison with the spec, we modified the parse_eye_diagrams.py script to compute and overlay the largest diamond that fits in the passing region and added a pass/fail page at the end. This is a stricter requirement, but even just the "Worst Delta mV" and "Worst Delta UI" values fail to meet the Table 3-3 spec.
  • 0
    TI__Expert 7195 points

    Greetings Jay,

    We do not make determinations of pass/fail for customers, the criteria or methodology for that is up to your discretion. Often times the decisions of whether a system is good or bad comes down to a tradeoff of signal integrity vs. board cost vs. design cycles vs, timelines, etc. The eye tool is commonly used as a part of a greater validation plan or pre-existing flow that usually starts with board level simulations using IBIS models and ends with some level of real board testing (commonly as a suite of boards running across temp chambers with memory testers, but I've seen other customers with a variety of flows), so it is not the sole indicator of system pass/fail.

    Sincerely,

    Lucas

  • 0
    TI__Guru* 94931 points

    Jay, can you provide the DDR configuration (.dtsi or .h and .syscfg) from the Sysconfig DDR register configuration tool that you are using for the 1866MHz configuration? 

    Also, it is my understanding that you are using RTOS, with SBL bootloader, is this correct?  

    If your configuration file has these two lines:

    #define DDRSS_PLL_FREQUENCY_1 933000000
    #define DDRSS_PLL_FREQUENCY_2 933000000

    try changing them to this and retest:

    #define DDRSS_PLL_FREQUENCY_1 933333333
    #define DDRSS_PLL_FREQUENCY_2 933333333

    Regards,

    James