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

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

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

這是使用方法論報(bào)告系列博文的第 3 部分。如需閱讀本系列中的其他博文，請點(diǎn)擊

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

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

問題說明：

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

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

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

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

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

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

調(diào)試方法：

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

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

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

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

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

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

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

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

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

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

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

■Report CDC

■Report Methodology

■Report Exception

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

根本原因分析：

MIG set_max_delay 路徑并未被忽略。

report_timing 報(bào)告了最大延遲

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

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

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

報(bào)告顯示針對 2 個(gè) DDR4_rx/tx，在最差情況下存在超過 3ns 的時(shí)序收斂失敗，如下所示。

我們可以利用時(shí)序匯總報(bào)告 (Report Timing Summary) 的限定機(jī)制僅對 MIG 接口進(jìn)行集中分析。

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

解決辦法：

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

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

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

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

結(jié)論：

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

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

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

1) 時(shí)鐘交互報(bào)告 (Report Clock Interaction)：

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

2) 方法論報(bào)告 (Report Methodology)

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

3) CDC 報(bào)告 (Report CDC)

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

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

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

4) 例外報(bào)告 (Report exception)：

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

一些小技巧：

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

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

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

report_cdc -cells [get_selected_objects] -details  -name 
report_timing_summary -cells [get_selected_objects ] -name 

要檢查是否已忽略 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 找到以上時(shí)序路徑。“-name”開關(guān)將在 GUI 中生成報(bào)告。

審核編輯：湯梓紅