DFX設(shè)計(jì)無(wú)法連貫布線的根本原因及修護(hù)

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

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

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

第2部分：方法違例對(duì)于QoR的影響

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

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

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

問(wèn)題說(shuō)明：

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

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

根本原因分析：

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

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

注: 要詳細(xì)分析含估算的布線延遲的時(shí)序，請(qǐng)?jiān)?Vivado GUI 的“時(shí)序匯總 (Timing Summary)”報(bào)告中針對(duì)互連 (interconnect) 使用“估算 (estimated)”選項(xiàng)。

您可使用以下選項(xiàng)來(lái)檢查自己的設(shè)計(jì)的“Timing Summary”：

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

運(yùn)行以下 Tcl 命令：

report_timing_summary -file/timingreport.txt

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

或者，也可以使用以下 Tcl 命令來(lái)分析含估算的布線延遲的時(shí)序。

set_delay_mode -interconnect estimated

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

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

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

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

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

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

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

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

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

布線器始終優(yōu)先修復(fù)保持時(shí)間違例，而后才是修復(fù)建立時(shí)間違例，因?yàn)榇嬖诒３謺r(shí)間違例的設(shè)計(jì)無(wú)法正常運(yùn)行，而存在建立時(shí)間違例的設(shè)計(jì)則仍能按較低頻率運(yùn)行。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)論：

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

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

set_max_delay -datapath_only -from [] -to []

審核編輯：郭婷