本篇博文中的分析是根據(jù)真實客戶問題撰寫的，該客戶的 DFX 設(shè)計無法連貫布線，存在布線重疊。本篇博文旨在演示用于縮小根本原因范圍以及修復(fù)此問題的部分調(diào)試技巧。

這是“使用方法論報告”系列博文的第 6 部分。

第1部分：時序以滿足，但硬件功能出現(xiàn)錯誤

第2部分：方法違例對于QoR的影響

第3部分：時序已滿足，但硬件中存在 DDR4 校準(zhǔn)失敗

第4部分：罕見的比特翻轉(zhuǎn)

第5部分：DDR4 IP 校準(zhǔn)后硬件故障，指示存在時序問題，但時序報告中無任何違例

問題說明：

在此示例中，用戶的 DFX 設(shè)計遇到 1 個奇怪的問題，它無法連貫布線，部分信號線保持處于未布線狀態(tài)。

運行 Tcl 命令 report_route_status 顯示如下結(jié)果，有 165 條信號線未布線：

根本原因分析：

通過觀察設(shè)計發(fā)現(xiàn)，時鐘間路徑存在超大保持時間違例，約 - 4.6 ns，如下所示。

但在已布線的檢查點上未出現(xiàn)這些違例。route_design 開始處的日志中可以看到這些違例。

注: 要詳細(xì)分析含估算的布線延遲的時序，請在 Vivado GUI 的“時序匯總 (Timing Summary)”報告中針對互連 (interconnect) 使用“估算 (estimated)”選項。

您可使用以下選項來檢查自己的設(shè)計的“Timing Summary”：

在 Vivado GUI 中，轉(zhuǎn)至“報告 (Reports)”選項卡 ->“時序 (Timing)”->“時序匯總報告 (Report Timing Summary)”

運行以下 Tcl 命令：

report_timing_summary -file/timingreport.txt

互連設(shè)置用于控制信號線延遲計算方式：根據(jù)估算的葉節(jié)點單元管腳間布線距離來計算，或者根據(jù)實際布線的信號線來計算，或者從時序分析中排除信號線延遲。

或者，也可以使用以下 Tcl 命令來分析含估算的布線延遲的時序。

set_delay_mode -interconnect estimated

借助時鐘交互報告 (Report Clock Interaction)，即可在所有特定時鐘域中發(fā)現(xiàn)這些時鐘間路徑違例，如下所示。

如需在 Vivado GUI 中查看時鐘交互報告，請依次選擇“報告 (Reports)”->“時序 (Timing)”->“時鐘交互報告 (Report Clock Interaction)”。

通過觀察這些嚴(yán)重的保持時間違例，可以得出如下結(jié)論：時鐘拓?fù)浣Y(jié)構(gòu)存在問題，或者設(shè)計未正確約束。

而這兩種可能性都需要加以詳細(xì)分析。

通過觀察發(fā)現(xiàn)，此時鐘間路徑存在保持時間違例（如下所示），且其時鐘路徑偏差非常高，看上去很可疑。

默認(rèn)情況下，Vivado 將所有時鐘都視作為同步時鐘來處理。因此，這些 CDC 異步時鐘路徑同樣被視為同步，因此導(dǎo)致在路徑中此處添加錯誤的時鐘偏差。在此示例中，偏差約為 4 ns。

那么我們是如何發(fā)現(xiàn)這些異步 CDC 未正確約束的呢？

我們是從時鐘對分類 (Clock Pair Classification) 和時鐘間約束 (Inter clock Constraints) 列中得到此信息的（如下所示）。

這導(dǎo)致出現(xiàn)嚴(yán)重的保持時間違例，因而導(dǎo)致布線器執(zhí)行大量保持時間修復(fù)，從而導(dǎo)致布線擁塞。

布線器始終優(yōu)先修復(fù)保持時間違例，而后才是修復(fù)建立時間違例，因為存在保持時間違例的設(shè)計無法正常運行，而存在建立時間違例的設(shè)計則仍能按較低頻率運行。

由于布線繞行導(dǎo)致的布線擁塞可能導(dǎo)致時序違例，也可能導(dǎo)致無法布線。

擁塞嚴(yán)重會導(dǎo)致布線器無法找到任何資源用于布線。此處示例的問題正來自于此。

您可以觀察到由于欠約束 CDC 路徑，會導(dǎo)致布線器花費大量的布線資源用于修復(fù)保持時間違例。

最終，它導(dǎo)致了在此例中所發(fā)生的信號線擁塞/未布線問題。

以下截屏顯示的保持時間違例中，時鐘偏差為 4 ns。

下圖顯示了發(fā)生保持時間違例的非安全 CDC 路徑中所使用的布線資源總量。

并且，分析還發(fā)現(xiàn)利用率在可控范圍內(nèi)，并未超出閾值。而根本原因同樣源于約束不正確。

要在 Vivado GUI 中查看資源利用率，請轉(zhuǎn)至“報告 (Reports)”選項卡 ->“報告利用率 (Report Utilization)”。

或者，您可在 Tcl 控制臺內(nèi)運行 report_utilization 命令。

那么在此情況下，方法論報告又如何發(fā)揮作用呢？

通過觀察此報告可以發(fā)現(xiàn)，在設(shè)計中存在大量方法警告。

以下列出了影響設(shè)計 QoR 且需要優(yōu)先解決的主要警告。

要在 Vivado GUI 中打開方法論報告，請轉(zhuǎn)至“報告 (Report)”選項卡 ->“方法論報告 (Report Methodology)”，或者在 Tcl 控制臺中，使用 report_methodology。

以下截屏顯示的方法論報告包含有關(guān) TIMING-6、7、8、15 和 35 的警告消息。

根據(jù) TIMING-6、TIMING-7、TIMING-8 和 TIMING-35 警告，可以得出結(jié)論，即設(shè)計未正確約束，并且必須對其加以正確約束。

因此，用戶需參閱時鐘交互報告以了解時鐘間路徑的時序是否安全。如需獲取有關(guān)“時鐘交互報告 (Clock Interaction Report）”的更多信息，請參閱 (UG906：https://china.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/c... )。

TIMING-15 警告顯示在時鐘間路徑上存在嚴(yán)重的保持時間違例，必須先加以解決，然后才能生成比特流。

由于布線器始終會嘗試解決保持時間違例，并且這也會影響布線，因此建議正確約束設(shè)計，并清除上述警告消息中提及的時鐘間路徑中的錯誤。

通過檢查時序匯總可以發(fā)現(xiàn)，時鐘間路徑的保持時間違例非常高，達(dá)到約 -3 ns。

如需獲取有關(guān)這 5 條警告消息及其解決方案的更多信息，請參閱 (UG906：https://china.xilinx.com/support/documentation/sw_manuals/xilinx2020_1/c... ) 附錄 A。

結(jié)論：

通過觀察分析可以發(fā)現(xiàn)，如果在調(diào)試初始階段，客戶遵循方法論報告中的警告將其逐一解決，那么即可大幅縮短調(diào)試此信號線未布線問題的時間。

添加如下約束后，即可解決這些幽靈時序違例：

set_max_delay -datapath_only -from [] -to []

審核編輯：郭婷