[参考译文] AM3351：eMMC 时序分析

关于输入时序分析、您的设置裕度公式显示了从时钟周期中减去的 CPU 保持要求。 这应该是 CPU 设置要求、而不是 CPU 保持要求。 您在计算中使用了正确的值、因此我同意您的利润率结果。 注意：您的计算假设所有 PCB 延迟相等。

我也同意您对输出时序(标准模式)的分析。

我发现了三个输出时序分析问题(高速模式)。

1. AM4376设置裕度计算中的 CPU 最大输出延迟值过去是错误的。 正确的值为7.4ns 而不是4.4ns、这将裕度从13.43ns 降低到了10.43ns。
2. 您忘记在 AM3351保持裕度计算中包含时钟周期。 结果应为20.83ns + 3ns–3ns = 20.83ns。
3. 您忘记在 AM4376保持裕度计算中包含时钟周期。 结果应为20.83ns + 0.8ns–3ns = 18.63ns。

显示在标准模式下运行的 AM3351负裕度的参数基于 CPU 的14ns 最大输出延迟。 此延迟是最坏情况、只能在最坏情况下的加工角器件上观察到、同时在最坏情况下的温度和电压下运行。 在标称工作条件下运行的典型器件的输出延迟很可能远小于14ns。 我不确定您测试了多少个系统，但在一个小样本中很难找到最坏情况下的处理设备。 我怀疑 eMMC 器件也有裕度来考虑工艺、温度和电压。

希望这能解答您的问题。

此致、
Paul

您好 Paul、

感谢您的支持。 您的结论证实了我自己的假设。 我同意您在我的时间分析中发现的问题。

我们将在下星期一对我们团队的结果进行分析。 如果有相关问题、我将保持此主题打开。  

此致

Stefan

您好！

在我看来、时间计算不完全正确：

(1)输入时序保持裕度：

计算得出的时间(2、5ns + 0、64ns)是 CPU 输入端存在的保持时间(非裕度)。 然而、CPU 侧的最小保持要求为3、76ns、所以我们有一个裕度(2、5ns + 0、64ns)- 3、76ns =-0、62ns

(2) AM335x 的输出时序、HS 模式、保持

时钟周期对输出保持时间无关紧要。 CPU 输出延迟最小为3ns、这意味着在最坏的情况下、在时钟低电平-高电平转换后的最早3ns 内、CPU 可以更改其数据/cmd 输出。 由于 clk、数据的延迟相等、cmd 这直接转换为 eMMC 上的保持时间、这意味着 eMMC 上的数据保持也是3ns、这正是 JEDEC 的最低要求、且裕度= 0。

我的假设/计算中是否有任何错误？

Tom

Tom、您回答正确。  

我 完全错过了您强调的第一个问题、不知道在高速模式下运行时、在 eMMC 保持裕度计算中添加时钟周期时会有什么想法。

我应该已经知道第一个问题看起来不对的事情。  满足 CPU 保持时间要求始终是一项挑战。 在这种情况下、可能需要添加 PCB 迹线延迟以解决此保持时间问题。 这可以通过增加所有信号布线的长度、或者只增加 CMD/DAT、或者只增加 CLK 来解决。 但是、您需要查看 eMMC 器件时序以确定哪个选项与其时序裕度兼容。

最好在高速模式下运行 AM3351、在高速模式下、当所有信号布线长度相等时、eMMC 器件具有3.83ns 的设置裕度和0ns 的保持裕度。 对于此处讨论的情况、我们需要添加至少620ps 的跟踪延迟以解决 CPU 保持问题。 这可以通过增加 CMD/DAT 信号的长度来实现、这也为 eMMC 器件提供了额外的保持裕度、而不会影响 eMMC 设置裕度。

最好在标准模式下运行 AM436、在该模式下、当所有信号布线长度相等时、eMMC 器件具有3.415ns 的设置裕度和0.015ns 的保持裕度。 这里也是如此、其中需要添加至少620ps 的跟踪延迟以解决 CPU 保持问题。 这可以通过增加 CMD/DAT 信号的长度来实现、这也为 eMMC 器件提供了额外的保持裕度、而不会影响 eMMC 设置裕度。

此致、

Paul