• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 7 answers
  • Subscribers 34 subscribers
  • Views 754 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.

DS90UB954-Q1: Margin Analysis Program

Tomoaki Yoshida91
Genius 5255 points
Part Number: DS90UB954-Q1
Other Parts Discussed in Thread: ALP

]Hi team,

I am planning to implement functions equivalent to ALP's Margin Analysis on the SoC on my board.

So, I want to ask a few questions by looking at the ALP margin analysis script.

1. What is time_sleep (0, dwell_time) highlighted in yellow below to do?

   I thought it was the waiting time from Digital reset to stabilization.

   Is it correct?

2. How should I determine dwell time?

    I want to know what the dwell time is 500ms.

3. A 100ms sleep is inserted everywhere as the red line is drawn.

    Is this a necessary wait time?

   Will shortening the time or eliminating the wait have any impact?

4. I think it is better not to delete the blue line in the 10 loops.

   Is it correct?

   In other words, I think we don't need waits other than the blue line.

5.  The error judgment is repeated 10 times. What is the reason for the 10th number?

    Is there any difference from the case where the error is judged only once by multiplying the measurement time by 10 times?

Best regards,

Tomoaki Yoshida

   

  • 0
    TI__Guru* 98535 points

    Hello Tomoaki,

    We can help do this analysis early next week to answer your questions. Just so we make sure we are providing the right information, is the intent of this integration to allow for doing this kind of margining on startup of the system? Or would you be using it more for debugging in the prototype phase? That may determine how to best craft your solution.

    Best Regards,

    Casey

  • 0 in reply to Casey McCrea
    TI__Mastermind 21685 points

    Hello Tomoaki,

    Please also look into this app note available on Margin Analysis 

    www.ti.com/.../snla301

    FYI, Dwell time is explained in section 4 of the app note.

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    TI__Mastermind 21685 points

    Hello Tomoaki,

    1, 2: Dwell time is not wait time from digital reset to stabilization. Dwell time determines how long each EQ/SP setting is monitored. When we do a manual sweep over EQ and strobe settings,  after each new selection, we wait this time to see if any link error or lock failure was observed in this time.

    You can see also in DS90UB954 Data Sheet section AEQ Timing (7.4.9.2.3)  explanation of dwell time with respect to the builtin AEQ

    3, 4: The 100ms wait time is to account for the communication delay over USB when these instructions are executed by ALP. It's better to have this delay to avoid communication errors when we do a series of device read/write accesses from PC. If you are doing margin analysis using an embedded SOC then you don't need this.

    5. We test it multiple times to make sure lock is stable and there are no errors. Choosing 10 is arbitrary.

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    I'm sorry for my late reply.

    I checked your answer and the actual script file, but I don't understand dwell time.

    The dwell time is explained at the top of the script file as follows:

    In fact, even in the body of the script, dwell time is outside the loop of 10 measurements.

    Also, since 0x4D and 0x4E are read immediately after the dwell time, 0x4D and 0x4E should be reset once.

    I think that this dwell_time in the script does not affect the result of margin analysis.

    I think that the link error or lock failure will be checked during time.sweep (0.1) in the green loop.

    Is this correct?

    If yes, time.sleep (0.1) in the green loop should not be deleted.

    Sorry for taking your time again, but we need to understand this script correctly in order to implement Margin analysis on the SoC. 

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    Genius 5255 points

    Hi Vishy-san,

    I thought that the program executed from the Margin Analysis tab of ALP and the ub954_margin_analysis_script.py of PreDefScript are the same thing.

    Maybe it is different?

    Dwell time on the margin analysis tab and the variable dwell_time in the script have the same name, but do they have different uses?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Tomoaki-san,

    Any time digital reset is given device needs a minimum time to restart. So the comment is only to say that dwell time in this manual sweep case cannot be less than that. Note digital reset0 doesn’t reset the register values so write to reg_8 (which updates strobe position SP) and EQ selection before that are still valid. So after a new EQ/SP selection we wait at least the selected dwell time (which includes reset recovery) before checking lock condition. Note all the logging, usb access and script delays also contribute to dwell time over and above the selected minimum time. You can give additional time to increase your confidence.

    Lock testing is done multiple times inside a loop of 10 just to confirm it is stable and there's no change or errors. It is fine to give some additional delay inside the loop during repeated checking of the lock.

    >>>I thought that the program executed from the Margin Analysis tab of ALP and the ub954_margin_analysis_script.py of PreDefScript are the same thing.

    Yes they are almost the same. Dwell time in the margin analysis tab is used in the same way as in the script.

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    Thank you for your support.

    I understand.

    In the previous explanation, it was possible to delete time_sleep, but time_sleep in the green loop also affects the result because it is the measurement time.

    Is there any recommendation of measurement time or total monitor bits for margin analysis?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Tomoaki-san,

    Sorry for the delay in reply.

    >>>>Is there any recommendation of measurement time or total monitor bits for margin analysis?

    Measurement time and total monitor bits are system dependent. I don't have specific recommendation.

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    Sorry for my late reply.

    I understand that the dwell time is a minimum of 500ms, but in normal operation it is typ20ms from reset release (PDB: L → H) to lock establishment, and about 300ms at the maximum.

    Why do dwell times need to be so long?

    When I look at the script, digital reset (0x01) is executed every time the strobe position and EQ level settings are changed.

    Is it necessary to execute it every time the setting is changed?

    If the SP and EQ settings are changed manually, is a digital reset required to reflect the settings?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Hello Tomoaki-san,

    >>>If the SP and EQ settings are changed manually, is a digital reset required to reflect the settings?

    I don't think digital reset is required. You can comment it out. No need to have it every time.

    >>>Why do dwell times need to be so long?

    The default dwell time as part of on-chip adaptive AEQ is 2.62ms and maximum is 21ms (register 0xD2). In manual testing you can wait additional time (depending on your system requirement) for confidence.

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    Thank you for your support.

    >>>>Why do dwell times need to be so long?

    >The default dwell time as part of on-chip adaptive AEQ is 2.62ms and maximum is 21ms (register 0xD2). In manual testing you can wait additional time (depending on your system requirement) for confidence.

    We intend to implement Margin analysis on the SoC on the board.

    In that case, the system time can be reduced, so can dwell_time be closer to 21ms?

    Of course, we will set some margins in consideration of system delays, but we don't think there is a limit of 500ms like the script.

    We want to make dwell_time and sleep as small as possible to reduce the execution time.

    The 500ms limit for scripts is set for PC and software systems.

    Originally, dwell_time is a waiting time for ADAPTIVE_EQ_RELCK_TIME, which can be shortened in the case of SoC implementation.

    Is it correct?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Tomoaki-san,

    I would suggest first validating with say 200ms at least. Then you can reduce it and see if there is any impact in results.

    Also, see if there is any difference in results between keeping and removing the soft reset (registers not affected).

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    Thank you for your support.

    I understand that dwell time only has to wait for the time it takes to lock.

    When applying a digital reset, wait for 300ms in consideration of the maximum lock time.

    Is there a problem in 200ms or less even after a digital reset?

    Best regards,

    Tomoaki Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Tomoaki-san,

    In manual sweep whenever EQ/SP are changed, device has to relock. In addition to relock time it is good to wait additional time and check for any lock drop / errors. 

    Thanks,

    Vishy

  • 0 in reply to Vishy Viswanathan
    Genius 5255 points

    Hi Vishy-san,

    Thank you for your support.

    I tried using script to see if the result is the same with or without digital reset.

    Commenting out and executing the reset command highlighted in yellow below, it was judged as NG for all settings.

    When comparing the log results, it seems that a parity error is often detected when there is no reset under the condition of OK judgment with reset.

    Looking at the 0x4D log results for the blue line.

    The left side is a log with no reset and the right side is with a reset.

    Does resetting affect the detection of parity errors?

    I feel that reset is necessary when I see this result.

    Could you tell me your opinion?

    Best regards,

    Tomoski Yoshida

  • 0 in reply to Tomoaki Yoshida91
    TI__Mastermind 21685 points

    Tomoaki-san,

    Thanks for checking that. Whenever EQ/SP are updated, as we are in manual mode, I think reset (without disturbing registers) is making the device to readapt  and lock to the new settings. Otherwise you are getting errors. 

    Please keep the reset instruction but try reducing the dwell time to your need and see. Again, here also please check initially with a higher number and see the effect of reducing.

    Thanks,

    Vishy