本篇博文中的分析是根據(jù)真實客戶問題撰寫的，該客戶發(fā)現(xiàn)硬件中存在 DDR4 校準(zhǔn)錯誤，不同板以及不同構(gòu)建 （build） 之間出現(xiàn)的故障并不一致。

本篇博文旨在演示用于縮小根本原因范圍以及修復(fù)此問題的部分調(diào)試技巧。

最后，問題是由于用戶 XDC set_false_path 約束覆蓋 MIG IP 約束所導(dǎo)致的，錯誤使用 set_false_paths 的危險性由此可見一斑。

這是使用方法論報告系列博文的第 3 部分。如需閱讀本系列中的其他博文，請點擊查閱。

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

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

問題說明：

用戶的設(shè)計使用的是 Vivado 和 SDx 流程。此設(shè)計包含 2 個 DDR4 64 位接口，運行速度為 2000 Mbps。此設(shè)計已達成時序收斂，但在某一個 DDR4 接口或者有時在 2 個接口上都會觀察到校準(zhǔn)失敗。

硬件故障與構(gòu)建有關(guān)：

■成功的構(gòu)建在多個板上都成功完成

■而失敗的構(gòu)建則在多個板上都失敗

■大部分情況下其中一個接口或者 2 個接口都會發(fā)生故障

■失敗的比特因構(gòu)建而不同

調(diào)試方法：

失敗特征表明存在時序約束或 CDC 問題，因此我們使用以下步驟進行調(diào)試。

1） 添加 ILA 并重新運行設(shè)計實現(xiàn)?，F(xiàn)在，故障消失了，或者轉(zhuǎn)移到其它比特。

2） 使用增量實現(xiàn)流程，以保留失敗特征。

3） 向 ILA 添加流水線階段以簡化時序收斂。此測試的目標(biāo)是在失敗的階段中尋找期望的模式，以便縮小失敗的比特的范圍。

4） 嘗試 Pblock 以使 MIG IP 的布局保持彼此接近。在此情況下，失敗特征并未發(fā)生改變：

■成功完成時序收斂的接口在硬件中失敗

■未完成時序收斂的接口在硬件中則能成功完成時序收斂

根據(jù)以上結(jié)果可見，問題可能在于某些 MIG 約束被用戶或者被 Vivado 流程所覆蓋。

下一步是復(fù)查用戶的 XDC 約束。

執(zhí)行此操作時，我們注意到時鐘間的 false_paths 約束是由用戶設(shè)置的。

現(xiàn)在，運行以下建議的報告組合。關(guān)鍵的報告是 report_methodology 和 report_cdc。

■Report CDC

■Report Methodology

■Report Exception

■Report MIG set_max_delay（用于確認(rèn)這些約束是否被忽略）

根本原因分析：

MIG set_max_delay 路徑并未被忽略。

report_timing 報告了最大延遲

我們在部分 MIG 路徑（互連結(jié)構(gòu) （fabric） 到 PHY）上發(fā)現(xiàn)了以下 CDC 嚴(yán)重警告。

現(xiàn)在，將這些路徑與 MIG 設(shè)計示例中的示例進行比對，這些示例是使用 IP integrator 流程創(chuàng)建的，且已安全完成時序收斂。

根據(jù)發(fā)現(xiàn)的結(jié)果，我們移除了用戶添加的所有 false_paths 約束，并在未重新實現(xiàn)整個設(shè)計的情況下重新報告時序。

報告顯示針對 2 個 DDR4_rx/tx，在最差情況下存在超過 3ns 的時序收斂失敗，如下所示。

我們可以利用時序匯總報告 （Report Timing Summary） 的限定機制僅對 MIG 接口進行集中分析。

現(xiàn)在，我們發(fā)現(xiàn)用戶添加的 false_paths 約束導(dǎo)致從互連結(jié)構(gòu) （fabric） 到 PHY 路徑被忽略。

解決辦法：

■從目標(biāo) XDC 移除上述 false_paths 并重新運行設(shè)計實現(xiàn)。

■設(shè)計重新恢復(fù)正常時序。

■現(xiàn)在，CDC 報告顯示先前忽略的路徑已安全達成時序收斂。

■測試硬件上的比特文件時，2 個 DDR4 接口都一致通過校準(zhǔn)。

結(jié)論：

請務(wù)必謹(jǐn)慎處理 set_false_path 約束。

此約束很容易導(dǎo)致必須達成時序收斂的路徑被忽略。在此類約束中使用通配符時或者在整個時鐘域之間設(shè)置 false_paths 時，除非您確定這些時鐘域之間沒有任何路徑需達成時序收斂，否則請務(wù)必謹(jǐn)慎操作。操作錯誤可能導(dǎo)致硬件故障，并導(dǎo)致調(diào)試流程難以持續(xù)且耗時冗長。

面臨在時序無錯誤的設(shè)計上遇到硬件故障的情況時，可在 Vivado 中運行幾項檢查。下列檢查應(yīng)始終運行，尤其是在布局布線之后。僅僅確認(rèn)時序無錯是不夠的，您仍需要完成這些檢查：

1） 時鐘交互報告 （Report Clock Interaction）：

提供有關(guān)設(shè)計中所有時鐘的信息。

2） 方法論報告 （Report Methodology）

如果觀察到不安全的路徑或用戶忽略的路徑，則可使用 Report Methodology 并集中解決嚴(yán)重警告。

3） CDC 報告 （Report CDC）

在此示例中，Report CDC 幫助發(fā)現(xiàn)了由于用戶約束導(dǎo)致被忽略的關(guān)鍵路徑。

將這些結(jié)果與 MIG 設(shè)計示例進行比對有助于從設(shè)計中存在的數(shù)百萬條路徑中發(fā)現(xiàn)可疑路徑。

使用限定機制可將分析范圍縮小到選定的模塊。

4） 例外報告 （Report exception）：

此報告可提供有關(guān)由于時序例外（如果有）而被忽略的路徑的信息，例如，set_false_paths 或 set_clock_groups。

一些小技巧：

對于超大型設(shè)計，解析數(shù)百萬條路徑是非常困難且耗時的。

為了加速周轉(zhuǎn)，可使用以下命令縮小報告范圍：

要在原理圖視圖中高亮實例，請執(zhí)行以下操作：

report_cdc -cells ［get_selected_objects］ -details -name 《cdc_report_xyz》

report_timing_summary -cells ［get_selected_objects ］ -name 《report_xyx》

要檢查是否已忽略 set_max delay，請執(zhí)行以下操作：

report_timing -from ［get_pins */*/*/*/slave_rdy_cptd_sclk_reg/C］ -to ［get_pins */*/*/*/u_slave_rdy_cptd_sync/SYNC［*］.sync_reg_reg［0］/D］ -name t3

可從 MIG XDC 找到以上時序路徑?！?name”開關(guān)將在 GUI 中生成報告。

責(zé)任編輯：haq