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

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

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

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

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

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

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

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

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

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

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

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

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

調(diào)試方法：

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

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

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

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

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

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

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

根據(jù)以上結(jié)果可見(jiàn)，問(wèn)題可能在于某些 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)告了最大延遲

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

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

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

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

我們可以利用時(shí)序匯總報(bào)告 （Report Timing Summary） 的限定機(jī)制僅對(duì) 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í)序收斂。

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

結(jié)論：

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

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

面臨在時(shí)序無(wú)錯(cuò)誤的設(shè)計(jì)上遇到硬件故障的情況時(shí)，可在 Vivado 中運(yùn)行幾項(xiàng)檢查。下列檢查應(yīng)始終運(yùn)行，尤其是在布局布線之后。僅僅確認(rèn)時(shí)序無(wú)錯(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)行比對(duì)有助于從設(shè)計(jì)中存在的數(shù)百萬(wàn)條路徑中發(fā)現(xiàn)可疑路徑。

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

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

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

一些小技巧：

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

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

要在原理圖視圖中高亮實(shí)例，請(qǐng)執(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，請(qǐng)執(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)告。

責(zé)任編輯：haq