本篇博文中的分析是根據(jù)真實(shí)客戶(hù)問(wèn)題撰寫(xiě)的，該客戶(hù)發(fā)現(xiàn)硬件中存在 DDR4 校準(zhǔn)后數(shù)據(jù)錯(cuò)誤，此問(wèn)題顯示為與時(shí)序有關(guān)，但時(shí)序報(bào)告中并未顯示任何違例，最初并未使用方法論報(bào)告 （Methodology report） 來(lái)確定問(wèn)題根源。

本篇博客將為您演示如何使用此報(bào)告來(lái)幫助加速調(diào)試，甚至完全避免硬件故障，最后確定此問(wèn)題根本原因是校準(zhǔn)完成時(shí)出現(xiàn)爭(zhēng)用狀況。出現(xiàn)爭(zhēng)用狀況的原因是由于某個(gè)多周期約束所覆蓋的時(shí)序例外，由此導(dǎo)致在時(shí)序分析報(bào)告中并未標(biāo)記此問(wèn)題。

這是使用方法論報(bào)告系列博文的第 5 部分。如需閱讀整個(gè)系列中的所有博文，請(qǐng)點(diǎn)擊下方標(biāo)題查看。

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

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

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

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

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

客戶(hù)在使用 UltraScale+ DDR4 IP 時(shí)，在硬件中遇到校準(zhǔn)后數(shù)據(jù)錯(cuò)誤。

根據(jù)設(shè)計(jì)的布線(xiàn)和實(shí)現(xiàn)，此問(wèn)題與構(gòu)建有關(guān)，換言之，在產(chǎn)品開(kāi)發(fā)期間對(duì)多個(gè)構(gòu)建鏡像進(jìn)行測(cè)試時(shí)，此問(wèn)題可能出現(xiàn)而后又消失。此外，此問(wèn)題可能僅在小部分板上出現(xiàn)。

時(shí)序報(bào)告顯示沒(méi)有任何違例。

調(diào)試方法：

由于重新實(shí)現(xiàn)后，此問(wèn)題可能就會(huì)消失，因此無(wú)法使用 ILA 調(diào)試。

我們?cè)谝巡季€(xiàn)的 DCP 中使用 ECO 來(lái)探測(cè)未使用的管腳的信號(hào)，通過(guò)示波器觀(guān)測(cè)信號(hào)發(fā)現(xiàn)哪個(gè)（些）信號(hào)開(kāi)始顯現(xiàn)錯(cuò)誤。

最終，我們將問(wèn)題范圍縮小到 1 個(gè)特定的信號(hào)線(xiàn)，在 DCP 中對(duì)該信號(hào)線(xiàn)進(jìn)行重新布線(xiàn)后，故障消失了。

隨后，我們檢查了與此信號(hào)線(xiàn)相關(guān)的路徑上的時(shí)序分析和時(shí)序約束：

1. 經(jīng)過(guò)該信號(hào)線(xiàn)的路徑的時(shí)序報(bào)告。在此報(bào)告中，我們得知，所涉及的路徑被多周期路徑約束所覆蓋

report_timing -through ［get_nets 《net_name》］

2. 打開(kāi)“Timing Constraints”Wizard，查找對(duì)應(yīng)的多周期路徑約束。

工具 （Tools） -》 時(shí)序 （Timing） -》 編輯時(shí)序約束 （Edit Timing Constraints）

我們?cè)凇癟iming Constraints”Wizard 中發(fā)現(xiàn)了以下多周期路徑約束：

set_multicycle_path -setup -from ［get_pins */u_ddr_cal_top/calDone*/C］ 8

set_multicycle_path -hold -end -from ［get_pins */u_ddr_cal_top/calDone*/C］ 7

基于以上分析，我們判定在這些路徑上存在爭(zhēng)用狀況問(wèn)題。

這些多周期路徑約束不應(yīng)添加，在此用例中，應(yīng)在每個(gè)時(shí)鐘周期內(nèi)正確捕獲數(shù)據(jù)，以避免出現(xiàn)爭(zhēng)用狀況，因此，這些路徑不屬于多周期路徑。

根本原因分析：

以下就是發(fā)生爭(zhēng)用狀況問(wèn)題的路徑。

其中 2 個(gè)目標(biāo)都應(yīng)在同一個(gè)周期內(nèi)接收到 calDone 信號(hào)，因?yàn)檫@兩者緊密相關(guān)。這 2 條路徑屬于不同時(shí)序路徑，各自都應(yīng)在不同時(shí)鐘周期達(dá)成時(shí)序收斂（根據(jù)多周期約束，應(yīng)在 1 到 8 個(gè)周期內(nèi)達(dá)成時(shí)序收斂）。這可能導(dǎo)致 calDone 在不同時(shí)間線(xiàn)到達(dá)目標(biāo)，導(dǎo)致功能異常。

另一方面，2 個(gè)目標(biāo)都沒(méi)有 CE 管腳控制（CE 管腳綁定到 VCC）。因此，未能在同一時(shí)鐘周期內(nèi)捕獲 2 條路徑上的數(shù)據(jù)，所以這些路徑并非合格的多周期路徑。

此多周期約束違例實(shí)際上是由 Methodology Report 捕獲的：

TIMING-46 警告 1

多周期路徑含綁定 CE 管腳

在寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_cal_top/calDone_gated_reg/Q

與寄存器

u_example_tb/init_calib_complete_r_reg/D

之間定義了 1 條或多條多周期路徑，并具有直接連接，且 CE 管腳已連接到 VCC（請(qǐng)參閱 Vivado IDE 中的“時(shí)序約束 （Timing Constraint）”窗口中的約束位置 6）。這可能導(dǎo)致路徑要求不準(zhǔn)確。

TIMING-46 警告 2

多周期路徑含綁定 CE 管腳

在寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_cal_top/calDone_gated_reg/Q

與寄存器

u_mig/inst/u_ddr4_mem_intfc/u_ddr_mc/u_ddr_mc_periodic/periodic_config_gap_enable_reg/D

之間定義了 1 條或多條多周期路徑，并具有直接連接，且 CE 管腳已連接到 VCC（請(qǐng)參閱 Vivado IDE 中的“時(shí)序約束 （Timing Constraint）”窗口中的約束位置 6）。

這可能導(dǎo)致路徑要求不準(zhǔn)確。

最好在流程初期階段盡早檢查 Methodology Report。在諸如此類(lèi)的示例中，它可幫助您捕獲并修復(fù)多周期違例，并避免發(fā)生硬件故障。您還可以在調(diào)試過(guò)程中先運(yùn)行 Methodology Report，并查看警告，其中高亮的違例將有助于加速問(wèn)題調(diào)查。

解決辦法：

【賽靈思答復(fù)記錄 73068】提供的補(bǔ)丁可用于解決在低于 2020.1 版的版本中發(fā)生的此問(wèn)題。（請(qǐng)掃碼參閱）

從 2020.1 版起，已移除了多周期路徑約束，并在路徑上添加了流水線(xiàn)階段，以簡(jiǎn)化時(shí)序收斂，同時(shí)確保所有目標(biāo)都能在同一個(gè)互連結(jié)構(gòu)周期內(nèi)達(dá)成時(shí)序收斂。

結(jié)論：

1. 在設(shè)計(jì)流程中盡早運(yùn)行 Methodology Report 以便捕獲并修復(fù)潛在問(wèn)題。

2. 請(qǐng)?jiān)诤壎ǖ?VCC 的 CE 管腳的路徑上謹(jǐn)慎使用多周期約束。

責(zé)任編輯：haq