DFX设计无法连贯布线的根本原因及修护

本篇博文中的分析是根据真实客户问题撰写的，该客户的 DFX 设计无法连贯布线，存在布线重叠。本篇博文旨在演示用于缩小根本原因范围以及修复此问题的部分调试技巧。

这是“使用方法论报告”系列博文的第 6 部分。

第1部分：时序以满足，但硬件功能出现错误

第2部分：方法违例对于QoR的影响

第3部分：时序已满足，但硬件中存在 DDR4 校准失败

第4部分：罕见的比特翻转

第5部分：DDR4 IP 校准后硬件故障，指示存在时序问题，但时序报告中无任何违例

问题说明：

在此示例中，用户的 DFX 设计遇到 1 个奇怪的问题，它无法连贯布线，部分信号线保持处于未布线状态。

运行 Tcl 命令 report_route_status 显示如下结果，有 165 条信号线未布线：

根本原因分析：

通过观察设计发现，时钟间路径存在超大保持时间违例，约 - 4.6 ns，如下所示。

但在已布线的检查点上未出现这些违例。route_design 开始处的日志中可以看到这些违例。

注: 要详细分析含估算的布线延迟的时序，请在 Vivado GUI 的“时序汇总 (Timing Summary)”报告中针对互连 (interconnect) 使用“估算 (estimated)”选项。

您可使用以下选项来检查自己的设计的“Timing Summary”：

在 Vivado GUI 中，转至“报告 (Reports)”选项卡 ->“时序 (Timing)”->“时序汇总报告 (Report Timing Summary)”

运行以下 Tcl 命令：

report_timing_summary -file/timingreport.txt

互连设置用于控制信号线延迟计算方式：根据估算的叶节点单元管脚间布线距离来计算，或者根据实际布线的信号线来计算，或者从时序分析中排除信号线延迟。

或者，也可以使用以下 Tcl 命令来分析含估算的布线延迟的时序。

set_delay_mode -interconnect estimated

借助时钟交互报告 (Report Clock Interaction)，即可在所有特定时钟域中发现这些时钟间路径违例，如下所示。

如需在 Vivado GUI 中查看时钟交互报告，请依次选择“报告 (Reports)”->“时序 (Timing)”->“时钟交互报告 (Report Clock Interaction)”。

通过观察这些严重的保持时间违例，可以得出如下结论：时钟拓扑结构存在问题，或者设计未正确约束。

而这两种可能性都需要加以详细分析。

通过观察发现，此时钟间路径存在保持时间违例（如下所示），且其时钟路径偏差非常高，看上去很可疑。

默认情况下，Vivado 将所有时钟都视作为同步时钟来处理。因此，这些 CDC 异步时钟路径同样被视为同步，因此导致在路径中此处添加错误的时钟偏差。在此示例中，偏差约为 4 ns。

那么我们是如何发现这些异步 CDC 未正确约束的呢？

我们是从时钟对分类 (Clock Pair Classification) 和时钟间约束 (Inter clock Constraints) 列中得到此信息的（如下所示）。

这导致出现严重的保持时间违例，因而导致布线器执行大量保持时间修复，从而导致布线拥塞。

布线器始终优先修复保持时间违例，而后才是修复建立时间违例，因为存在保持时间违例的设计无法正常运行，而存在建立时间违例的设计则仍能按较低频率运行。

由于布线绕行导致的布线拥塞可能导致时序违例，也可能导致无法布线。

拥塞严重会导致布线器无法找到任何资源用于布线。此处示例的问题正来自于此。

您可以观察到由于欠约束 CDC 路径，会导致布线器花费大量的布线资源用于修复保持时间违例。

最终，它导致了在此例中所发生的信号线拥塞/未布线问题。

以下截屏显示的保持时间违例中，时钟偏差为 4 ns。

下图显示了发生保持时间违例的非安全 CDC 路径中所使用的布线资源总量。

并且，分析还发现利用率在可控范围内，并未超出阈值。而根本原因同样源于约束不正确。

要在 Vivado GUI 中查看资源利用率，请转至“报告 (Reports)”选项卡 ->“报告利用率 (Report Utilization)”。

或者，您可在 Tcl 控制台内运行 report_utilization 命令。

那么在此情况下，方法论报告又如何发挥作用呢？

通过观察此报告可以发现，在设计中存在大量方法警告。

以下列出了影响设计 QoR 且需要优先解决的主要警告。

要在 Vivado GUI 中打开方法论报告，请转至“报告 (Report)”选项卡 ->“方法论报告 (Report Methodology)”，或者在 Tcl 控制台中，使用 report_methodology。

以下截屏显示的方法论报告包含有关 TIMING-6、7、8、15 和 35 的警告消息。

根据 TIMING-6、TIMING-7、TIMING-8 和 TIMING-35 警告，可以得出结论，即设计未正确约束，并且必须对其加以正确约束。

因此，用户需参阅时钟交互报告以了解时钟间路径的时序是否安全。如需获取有关“时钟交互报告 (Clock Interaction Report）”的更多信息，请参阅 (UG906：https://china.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/c... )。

TIMING-15 警告显示在时钟间路径上存在严重的保持时间违例，必须先加以解决，然后才能生成比特流。

由于布线器始终会尝试解决保持时间违例，并且这也会影响布线，因此建议正确约束设计，并清除上述警告消息中提及的时钟间路径中的错误。

通过检查时序汇总可以发现，时钟间路径的保持时间违例非常高，达到约 -3 ns。

如需获取有关这 5 条警告消息及其解决方案的更多信息，请参阅 (UG906：https://china.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/c... ) 附录 A。

结论：

通过观察分析可以发现，如果在调试初始阶段，客户遵循方法论报告中的警告将其逐一解决，那么即可大幅缩短调试此信号线未布线问题的时间。

添加如下约束后，即可解决这些幽灵时序违例：

set_max_delay -datapath_only -from [] -to []

审核编辑：郭婷