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:裕度分析程序

Guru**** 2589300 points
Other Parts Discussed in Thread: ALP

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/838913/ds90ub954-q1-margin-analysis-program

器件型号:DS90UB954-Q1
主题中讨论的其他器件:ALP

]大家好、

我计划在我的板载 SoC 上实施等同于 ALP 利润分析的功能。

因此、我想通过查看 ALP 裕度分析脚本提出一些问题。

1、下面以黄色突出显示的 TIME_SLEEP (0、DON_TIME)是什么?

  我认为这是从数字复位到稳定的等待时间。

  正确吗?

2、如何确定驻留时间?

   我想知道驻留时间是500毫秒。

在绘制红线时、100ms 睡眠被插入到任何地方。

   这是否是必要的等待时间?

  缩短时间或消除等待是否会产生任何影响?

4.我认为最好不要删除10个循环中的蓝线。

  正确吗?

  换句话说、除了蓝线、我们不需要等待。

5. 错误判断重复10次。 第10个数字的原因是什么?

   与仅通过将测量时间乘以10次来判断误差的情况有什么区别?

此致、

Tomoaki Yoshida

   

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki、您好!

    我们可以帮助您在下周初进行此分析、以回答您的问题。 因此、我们确保提供正确的信息、这种集成的目的是允许在系统启动时进行这种裕量调节吗? 或者、您是否会将其更多地用于原型设计阶段的调试? 这可能决定如何最好地制定您的解决方案。

    此致、

    Casey

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki、您好!

    另请查看裕度分析中提供的此应用手册  

    www.ti.com/.../snla301

    供参考、驻留时间在应用手册的第4节中进行了说明。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki、您好!

    1、2:驻留时间不是从数字复位到稳定的等待时间。 驻留时间决定每个 EQ/SP 设置被监控的时间。 当我们对 EQ 和选通设置进行手动扫描时、 在每次新选择后、我们会等待这个时间以查看此时是否观察到任何链路错误或锁定故障。

    您还可以在 DS90UB954数据表中的 AEQ 时序(7.4.9.2.3)部分中查看 有关内置 AEQ 的驻留时间说明

    3、4:100ms 的等待时间是 ALP 执行这些指令时 USB 上的通信延迟。 当我们从 PC 进行一系列器件读/写访问时、最好具有此延迟以避免通信错误。 如果您使用嵌入式 SOC 进行裕度分析、则不需要这样做。

    5.我们多次测试它,以确保锁定稳定且没有错误。 选择10是任意的。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    很抱歉我迟到了。

    我检查了您的答案和实际脚本文件、但我不理解停留时间。

    驻留时间在脚本文件的顶部解释如下:

    实际上、即使在脚本正文中、驻留时间也在10次测量的循环之外。

    此外、由于0x4D 和0x4E 在驻留时间后立即读取、因此0x4D 和0x4E 应复位一次。

    我认为脚本中的此 dwell 时间不会影响裕度分析的结果。

    我认为在时间扫描(0.1)期间、将在绿色环路中检查链路错误或锁定故障。

    是这样吗?

    如果是、则不应删除绿色环路中的 TIME.SLEEP (0.1)。

    很抱歉、您再次花时间、但我们需要正确理解此脚本、以便在 SoC 上实施裕度分析。  

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    我认为从 ALP 的裕度分析选项卡和 PreDefScript 的 ub954_margin_analysis_script.py 执行的程序是相同的。

    可能不同?

    裕度分析选项卡上的驻留时间和脚本中的变量 dwell _time 具有相同的名称、但它们是否有不同的用途?

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、

    只要数字复位被赋予器件需要最短的重启时间、 因此、注释仅表示本手动扫描案例中的驻留时间不能小于该时间。 注意数字复位0不会复位寄存器值,因此在仍然有效之前,写入 REG_8 (更新了选通位置 SP)和 EQ 选择。 因此、在选择新的 EQ/SP 之后、我们至少等待选定的驻留时间(包括复位恢复)、然后再检查锁定条件。 请注意、所有日志记录、USB 访问和脚本延迟也会导致停留时间超过选定的最短时间。 您可以留出额外的时间来提高您的信心。

    在一个10的环路内进行多次锁定测试、只是为了确认它是稳定的并且没有变化或错误。 在重复检查锁定期间、在环路内提供一些额外的延迟是可以的。

    >>>我认为从 ALP 的“利润分析”选项卡和 PreDefScript 的 ub954_margin_analysis_script.py 执行的程序是相同的。

    是的、它们几乎相同。 页边距分析选项卡中的驻留时间的使用方式与脚本中的使用方式相同。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    感谢您的支持。

    我知道。

    在前面的解释中、可以删除 TIME_SLEEP、但绿色环路中的 TIME_SLEEP 也会影响结果、因为它是测量时间。

    对于裕度分析、是否有任何测量时间或总监控位的建议?

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、

    很抱歉耽误你的答复。

    >>>是否有任何裕度分析的测量时间或总监控位建议?

    测量时间和总监控位取决于系统。 我没有具体建议。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    很抱歉我迟到了。

    我知道驻留时间最短为500ms、但在正常操作中、复位释放(PDB:L→H)到锁定建立的时间为20ms、最大值约为300ms。

    为什么驻留时间需要这么长?

    当我查看脚本时、每次更改选通位置和 EQ 等级设置时都会执行数字复位(0x01)。

    是否有必要在每次更改设置时执行它?

    如果手动更改 SP 和 EQ 设置、是否需要数字复位来反映设置?

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、您好!

    >>>如果手动更改 SP 和 EQ 设置,是否需要数字复位来反映设置?

    我认为不需要数字复位。 您可以将其注释掉。 不需要每次都有。

    >>为什么驻留时间需要这么长?

    作为片上自适应 AEQ 一部分的默认驻留时间为2.62ms、最大值为21ms (寄存器0xD2)。 在手动测试中、您可以等待额外的时间(取决于您的系统要求)以获得信心。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    感谢您的支持。

    >>>为什么驻留时间需要这么长?

    >片上自适应 AEQ 的默认驻留时间为2.62ms,最大值为21ms (寄存器0xD2)。 在手动测试中、您可以等待额外的时间(取决于您的系统要求)以获得信心。

    我们打算在板上的 SoC 上实施裕度分析。

    在这种情况下、系统时间可以缩短、因此 dwell _time 可以更接近21ms?

    当然、我们将在考虑系统延迟的情况下设置一些裕度、但我们不认为像脚本那样有500ms 的限制。

    我们希望使 dwell _time 和 sleep 尽可能小、以减少执行时间。

    针对 PC 和软件系统设置了针对脚本的500ms 限制。

    最初、dwell Time 是 adaptive_EQ_RELCK_TIME 的等待时间、在 SoC 实现情况下可以缩短该时间。

    正确吗?

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、

    我建议首先验证至少200ms。 然后、您可以减少它并查看结果中是否有任何影响。

    此外、请参阅保持和移除软复位之间的结果是否有差异(寄存器不受影响)。

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    感谢您的支持。

    我知道驻留时间只需等待锁定时间。

    应用数字复位时、考虑到最长锁定时间、等待300ms。

    即使在数字复位后200ms 或更短的时间内也会出现问题吗?

    此致、

    Tomoaki Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、

    在手动扫描中、只要 EQ/SP 发生变化、器件就必须重新锁定。 除了重新锁定时间之外、最好等待额外的时间并检查是否有任何锁定丢失/错误。  

    谢谢、

    Vishy

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Vishy-San、

    感谢您的支持。

    我尝试使用脚本来查看在进行数字复位或不进行数字复位时结果是否相同。

    注释并执行下面以黄色突出显示的 RESET 命令、所有设置都被判定为 NG。

    在比较日志结果时、当在带有复位的 OK 判断条件下没有复位时、似乎经常检测到奇偶校验错误。

    查看蓝线的0x4D 日志结果。

    左侧是一个没有复位的日志、右侧是一个复位日志。

    复位是否会影响奇偶校验错误的检测?

    当我看到这一结果时、我认为需要进行复位。

    请告诉我您的意见。

    此致、

    Tomoski Yoshida

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Tomoaki-San、

    感谢您的观看。 无论何时更新 EQ/SP、当我们处于手动模式时、我认为复位(不会干扰寄存 器)会使器件适应并锁定到新设置。 否则您会遇到错误。  

    请保留重置说明、但尝试缩短停留时间以满足您的需求、请参阅。 同样、在这里、也请先检查较高的数字、看看降低的效果。

    谢谢、

    Vishy