开发者分享 | 使用方法论报告5: DDR4 IP 校准后硬件故障，指示存在时序问题，但时序报告中无任何违例

周三, 15 九月 2021 - 14:45

本篇博文中的分析是根据真实客户问题撰写的，该客户发现硬件中存在 DDR4 校准后数据错误，此问题显示为与时序有关，但时序报告中并未显示任何违例,最初并未使用方法论报告 (Methodology report) 来确定问题根源。

本篇博客将为您演示如何使用此报告来帮助加速调试，甚至完全避免硬件故障，最后确定此问题根本原因是校准完成时出现争用状况。出现争用状况的原因是由于某个多周期约束所覆盖的时序例外，由此导致在时序分析报告中并未标记此问题。

这是使用方法论报告系列博文的第 5 部分。如需阅读整个系列中的所有博文，请点击下方标题查看。

<a href="http://xilinx.eetrend.com/content/2021/100552904.html">第1部分：时序以满足，但硬件功能出现错误</a> 

<a target="_blank" href="http://xilinx.eetrend.com/content/2021/100553104.html" textvalue="第2部分：方法违例对于QoR的影响" data-itemshowtype="0" tab="innerlink" data-linktype="2" hasload="1" wah-hotarea="click">第2部分：方法违例对于QoR的影响</a>
<a target="_blank" href="http://xilinx.eetrend.com/content/2021/100553324.html" textvalue="第3部分：时序已满足，但硬件中存在 DDR4 校准失败" data-itemshowtype="0" tab="innerlink" data-linktype="2" hasload="1" wah-hotarea="click">第3部分：时序已满足，但硬件中存在 DDR4 校准失败</a>
<a href="http://xilinx.eetrend.com/content/2021/100553572.html">第4部分：罕见的比特翻转</a>

问题说明：

客户在使用 UltraScale+ DDR4 IP 时，在硬件中遇到校准后数据错误。

根据设计的布线和实现，此问题与构建有关，换言之，在产品开发期间对多个构建镜像进行测试时，此问题可能出现而后又消失。此外，此问题可能仅在小部分板上出现。

时序报告显示没有任何违例。

调试方法：

由于重新实现后，此问题可能就会消失，因此无法使用 ILA 调试。

我们在已布线的 DCP 中使用 ECO 来探测未使用的管脚的信号，通过示波器观测信号发现哪个（些）信号开始显现错误。

最终，我们将问题范围缩小到 1 个特定的信号线，在 DCP 中对该信号线进行重新布线后，故障消失了。

随后，我们检查了与此信号线相关的路径上的时序分析和时序约束：

1. 经过该信号线的路径的时序报告。在此报告中，我们得知，所涉及的路径被多周期路径约束所覆盖
<pre>report_timing -through [get_nets <net_name>]</pre>

2. 打开“Timing Constraints”Wizard，查找对应的多周期路径约束。
<pre>工具 (Tools) -> 时序 (Timing) -> 编辑时序约束 (Edit Timing Constraints)</pre>

我们在“Timing Constraints”Wizard 中发现了以下多周期路径约束：

<pre>set_multicycle_path -setup -from [get_pins */u_ddr_cal_top/calDone*/C] 8

set_multicycle_path -hold -end -from [get_pins */u_ddr_cal_top/calDone*/C] 7</pre>

基于以上分析，我们判定在这些路径上存在争用状况问题。

这些多周期路径约束不应添加，在此用例中，应在每个时钟周期内正确捕获数据，以避免出现争用状况，因此，这些路径不属于多周期路径。

根本原因分析：

以下就是发生争用状况问题的路径。
<center><img src="http://xilinx.eetrend.com/files/2021-09/wen_zhang_/100553691-220496-tu1…; alt=""></center>

其中 2 个目标都应在同一个周期内接收到 calDone 信号，因为这两者紧密相关。这 2 条路径属于不同时序路径，各自都应在不同时钟周期达成时序收敛（根据多周期约束，应在 1 到 8 个周期内达成时序收敛）。这可能导致 calDone 在不同时间线到达目标，导致功能异常。

另一方面，2 个目标都没有 CE 管脚控制（CE 管脚绑定到 VCC）。因此，未能在同一时钟周期内捕获 2 条路径上的数据，所以这些路径并非合格的多周期路径。

此多周期约束违例实际上是由 Methodology Report 捕获的：

TIMING-46 警告 1

多周期路径含绑定 CE 管脚

在寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_cal_top/calDone_gated_reg/Q

与寄存器

u_example_tb/init_calib_complete_r_reg/D

之间定义了 1 条或多条多周期路径，并具有直接连接，且 CE 管脚已连接到 VCC（请参阅 Vivado IDE 中的“时序约束 (Timing Constraint)”窗口中的约束位置 6）。这可能导致路径要求不准确。

TIMING-46 警告 2

多周期路径含绑定 CE 管脚

在寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_cal_top/calDone_gated_reg/Q

与寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_mc/u_ddr_mc_periodic/periodic_config_gap_enable_reg/D

之间定义了 1 条或多条多周期路径，并具有直接连接，且 CE 管脚已连接到 VCC（请参阅 Vivado IDE 中的“时序约束 (Timing Constraint)”窗口中的约束位置 6）。

这可能导致路径要求不准确。

最好在流程初期阶段尽早检查 Methodology Report。在诸如此类的示例中，它可帮助您捕获并修复多周期违例，并避免发生硬件故障。您还可以在调试过程中先运行 Methodology Report，并查看警告，其中高亮的违例将有助于加速问题调查。

解决办法：

从 2020.1 版起，已移除了多周期路径约束，并在路径上添加了流水线阶段，以简化时序收敛，同时确保所有目标都能在同一个互连结构周期内达成时序收敛。

结论：

1. 在设计流程中尽早运行 Methodology Report 以便捕获并修复潜在问题。

2. 请在含绑定到 VCC 的 CE 管脚的路径上谨慎使用多周期约束。