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

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

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

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

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

說明：

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

根本原因分析：

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

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

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

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

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

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

report_timing_summary、report_methodology、report_drc 和 report_cdc。 

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

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

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

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

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

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

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

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

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

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

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

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

結論：

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

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

審核編輯：湯梓紅