本篇博文中的分析是根據真實客戶問題撰寫的，該客戶的 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 []

審核編輯：郭婷