本篇博文中的分析是根據真實客戶問題撰寫的，該客戶發(fā)現在現場出現罕見的比特翻轉， 本篇博文旨在演示用于縮小根本原因范圍以及修復此問題的部分調試技巧。

最終發(fā)現，此問題是由于時鐘域交匯 （CDC） 處理不當所導致的，在 report_methodology 和 report_cdc 報告中高亮顯示了相關處理錯誤。

這是使用方法論報告系列博文的第 4 部分。如需閱讀整個系列中的所有博文，請點擊如下標題查看。

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

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

第3部分：時序已滿足，但硬件中存在 DDR4 校準失敗

問題說明：

此客戶在現場部署了數萬個基于 Zynq-7000 系列的產品，這些產品都是使用 Vivado 2013.4 開發(fā)的，其最終客戶報告稱大量卡上出現數據包損壞，調查顯示在所有數據包損壞案例中，設計中的相同位置都發(fā)生了比特翻轉。

根本原因分析：

為了縮小范圍，我們首先要求客戶提供網表中這些寄存器的位置：

我們要求客戶提供 DCP 以便我們使用各項報告來審查設計。

雖然通常隨機問題是由電源問題所導致的，但我們同時還要求客戶提供操作期間的 VCCINT/VCCAUX/VCCIO 測量方法，以便測量電平和噪聲，如（賽靈思答復記錄 62181-點擊閱讀原文可查看）中的硬件調試最佳實踐中所述。

我們還要求其提供板級原理圖 （schematic） 以復查使用的去耦電容是否足夠。

很快我們就把電源問題排除在原因之外。

收到 DCP 后，我們首先使用最新版本的 Vivado 運行

report_timing_summary、report_methodology、report_drc 和 report_cdc。

有多個問題馬上顯現了出來。

最重要的發(fā)現與可疑 FF 相關，report_methodology LUTAR-1 檢查標記出了這些可疑 FF：LUT 驅動異步復位警告

FF 具有異步復位，由邏輯級數深度為 2 的路徑驅動：

其危險性在于 LUT（紅色箭頭）可出現毛刺并觸發(fā)意外復位。

第二項最嚴重的發(fā)現與時鐘域交匯和約束有關。

Report_cdc 發(fā)現約有 40000 條路徑采用非推薦 CDC 架構：

不安全的時鐘域交匯可能導致翻轉 FF 下游或上游出現問題，并且可能成為所觀測到的行為的真正根源。

就約束而言，report_methodology 的“TIMING-24：僅最大延遲數據路徑已被覆蓋”檢查發(fā)現多項嚴重違例。

在移除 set_clock_groups -asynchronous 約束并將其替換為 set_max_delay -datapath_only 和時鐘對的最小時鐘周期后，發(fā)現出現了非常嚴重的時序違例：-5.8ns，原因是異步時鐘之間的邏輯級數達到 11。

第二輪審查發(fā)現設計中幾乎所有復位上都存在偽路徑約束，這些約束是為了幫助達成時序收斂而添加的，根據經驗，我們知道這是非常危險的：如果狀態(tài)機的各個位在不同時間脫離復位，則可能進入非法狀態(tài)、無法恢復并且導致設計運行錯誤。

即使復位為異步，取消復位仍需達成時序收斂，因此永遠不能忽略復位上的時序收斂，您應該盡可能明確自己實際是否需要復位，因為不使用復位可節(jié)省寶貴的布線資源，并且使 SR 管腳可用于控制置位的重映射，從而減小設計規(guī)模，因為邏輯函數可部分映射到這些 SR 管腳。

修復所報告的問題（LUT 驅動異步復位、CDC、CDC 約束）并在現場部署一些新固件后，這些罕見的比特翻轉就沒有再出現。

結論：

Vivado 報告功能（方法論、CDC）的進步使我們得以成功調試并解決罕見的比特翻轉問題。

無論何時遇到任何疑問，都應該首先考慮使用最新版本的 Vivado 來重新審查設計，最新版本的 Vivado 中包含 CDC 分析和最新的方法論檢查，這些都是進行原始設計所沒有的。

責任編輯：haq