Report QoR Suggestions助力解決Vivado設計問題

簡介

許多 FPGA 設計都難以達成所期望的性能目標。原因不盡相同，以下列出的只是其中部分可能的原因：

未遵循 UltraFast 設計方法

時序約束不良

過高資源利用率

控制集過多

未采用最優(yōu)化時鐘設置

邏輯層次過多，難以達成目標性能

布局規(guī)劃不良

布線擁塞

因約束導致工具優(yōu)化受限

如何才能輕松發(fā)現(xiàn)并快速修復這些問題？

Report QoR Suggestions

Report QoR Suggestions （RQS） 可識別設計問題，并提供工具開關和可影響工具行為的設計單元屬性的解決方案，即便在無法自動執(zhí)行解決方案的情況下也可提供文本修改建議。

早在 Vivado 2019.1 中，RQS 就已經開始輸出建議對象文件。這使我們可以對建議進行跟蹤、自動完成其實現(xiàn)、改進每一項建議的驗證工作并提供更復雜的建議。在此過程中新的命令和一些流程修改應運而生，如下所述：

1. “report_qor_suggestions”命令將生成新建議并提供現(xiàn)有建議的相關報告。如下圖所示，此命令可在實現(xiàn)過程的任意階段完成后運行。

2. 審核建議完成后，將使用“write_qor_suggestions”寫出一個包含所選建議的 RQS 文件。期間，建議的狀態(tài)將自動被設置為 ENABLED（大寫表示它屬于建議對象的屬性。

3. 通常下一步就是將此 RQS 文件應用到“建議運行 （Suggestion Run）”流程中，可以在 synth_design 或 opt_design 之前讀入。在此流程中，處于“自動 （AUTOMATIC）”狀態(tài)的建議經 APPLICABLE_FOR 階段后即可被應用。

要使 AUTOMATIC 建議狀態(tài)變更為 APPLIED，應在“建議運行”中調用 APPLICABLE_FOR 階段的同時將其設置為 ENABLED。下圖顯示了流經 APPLICABLE_FOR 階段的建議的處理過程：

在“建議運行”流程中，用戶可以再次調用“report_qor_suggestions”。這整個流程是可重復的，通過將來自前一輪運行的建議與當前輪次的建議累積起來即可組成單個文件并饋送到最新一輪的建議運行中。

如果有部分建議不符合您的期望，那么您可以使用以下命令來對寫入文件的建議加以過濾：

write_qor_suggestions -of_objects ［get_qor_suggestions -filter {some_fillter}

如果在此流程中多次運行“report_qor_suggestions”，并在流程的不同階段生成相同的建議，那么 RQS 將自動對重復的建議進行管理。

出現(xiàn)的建議可能會重復。例如，通過運行綜合或“opt_design”建議可得到相同的結果。在此情況下，RQS 僅允許將其中一項建議設置為 APPLIED，并且傾向于采用綜合建議。

此外，編寫 checkpoint 時，建議的當前狀態(tài)將存儲在 checkpoint 中。因此，只要建議已被讀取，即可寫出 checkpoint，而重新打開 checkpoint 時，則無需重新讀取建議。

案例分析示例

示例分析是了解建議效果的最佳途徑。

以下是針對此具體設計示例執(zhí)行“place_design”之后出現(xiàn)的建議列表。

建議名稱

首先請注意名稱。第一項建議的名稱 （NAME） 為 RQS_XDC-1-1。NAME 用于指示建議的類別。這項建議來自于 XDC 類別。

總共有 6 個類別：

? 利用率 （Utilization）

? XDC

? 時鐘設置 （Clocking）

? 擁塞 （Congestion）

? 時序 （Timing）

? 策略 （Strategy）

根據(jù)經驗，影響利用率、XDC 和時鐘設置的建議應在設計周期內盡早解決，如下圖所示：

這些建議通常會對大量路徑產生影響，并且還能降低設計收斂流程后期的擁塞和時序問題的嚴重程度。解決時序和擁塞問題的建議與解決時鐘設置、利用率和 XDC 問題的建議總是一并應用，無法拆分，但前兩類建議可能導致利用率增高，并且時鐘設置修復后可能就不再需要。

有鑒于此，通常在根據(jù)賽靈思 UltraFast 方法建議調整時序和 XDC 之前，不建議嘗試解決時序問題或擁塞問題。

時序和擁塞問題主要出現(xiàn)在特定模塊或特定時序路徑上。

擁塞僅出現(xiàn)在布局之后，并且在布線后準確性可有所提升。

通常僅在 RQS 發(fā)現(xiàn)時序路徑違例的路徑上才會報告時序建議。默認情況下，RQS 可在每個時鐘組中發(fā)現(xiàn) 100 條時鐘路徑。如果有的路徑有時序問題但未出現(xiàn)在這 100 條路徑中，那么 RQS 將不會提供有關這些路徑的建議。要增加路徑數(shù)量，請運行以下命令：

report_qor_suggestions -max_paths 《大于 100 的值》

有關策略建議的相關話題將在后續(xù)博客中進行探討。

自動建議

接下來請看表中的最后一條建議 RQS_CLOCK-1-1。在該表格中可以看到這是一項 AUTOMATIC 建議。此建議將對 BUFG 驅動的網(wǎng)絡應用 CLOCK_DELAY_GROUP 屬性。

倒數(shù)第二條建議 RQS_CLOCK-2-1 為手動 （AUTOMATIC = 0） 建議。它建議更改時鐘設置拓撲結構，通過將 BUFGCE + MMCM 除法器更換為含內置除法器的 BUFGCE_DIV 來進一步優(yōu)化此拓撲結構。Vivado 無法自動交換這些Buffer，因此需要用戶手動執(zhí)行 RTL 編輯。

顧名思義，AUTOMATIC 建議簡單易用，而手動建議則更為復雜。以下顯示了自動建議和手動建議所需的不同方法。

自動

? 將屬性應用于對象

? 將開關應用于命令

? 對約束稍作修改

手動

? 需要執(zhí)行 RTL 設計編輯

? 需要更新約束

? 需要更多用戶分析

總之，接近 80% 的建議為自動建議。鑒于手動建議所需工作量更大，因此可以考慮先跳過部分手動時鐘設置 （CLOCKING） 或利用率 （UTILIZATION） 建議，直接嘗試自動 （AUTOMATIC） 擁塞建議。但要實現(xiàn)最佳 QoR，必須先解決這些問題。

QoR 增益

以下顯示的是 30 個設計使用如下條件后所得結果：

? “place_design”Explore 指令

? 不含建議的“參考運行 （Reference Run）”與相同流程的“建議運行 （Suggestion Run）”對比結果

“place_design”生成的時鐘設置建議

“route_design”生成的所有其他建議

僅對自動 （AUTOMATIC） 建議進行比較

QoR 增益通過兩種方式來測量：

通過觀察 WNS 的絕對提升量（易于理解的指標）。

觀察建議運行相比參考運行中所有失敗的時鐘的幾何平均增益（更可靠的 QoR 增益指標）。

以下示例來自于先前表格對應的設計：

藍色高度表示“參考運行”，橙色高度表示“建議運行”的新 WNS?？梢钥吹?，RQS 對設計的 WNS 的提升效果顯著。全部 30 項設計的平均 WNS 增益達 0.648 ns。

此圖顯示了一種更為完善的測量措施。它通過觀察所有運行失敗的時鐘來計算幾何平均數(shù)的提升百分比 （%）。此方法可以平滑掉單一時鐘出現(xiàn)重大錯誤蓋過其他多個時鐘出現(xiàn)時序設置故障的數(shù)值。

這些設計中的幾何平均值的平均增益為 12.1%。

當然其中有特別突出的增益。在排名前 4 的設計中，QoR 平均提升 34.7%。

通過對增益進行分析可以發(fā)現(xiàn)：

存在對少量路徑產生重大影響的單一特定問題時，QoR 增益超過 20%。解決此類問題易如反掌。

解決時鐘設置問題時，QoR 增益超過 10%

解決通常接近設計收斂周期末尾的個別時序路徑中的問題所得到的增益較少。

簡單問題全部解決后，再要繼續(xù)提升增益就不那么容易了。這段解析展示了 RQS 在整個設計周期內產生的影響，應在完成設計中的重大修改后再運行。

除了此處展示的數(shù)字之外，并沒有其他簡單方法可用來測量手動建議所實現(xiàn)的增益，因此執(zhí)行手動修改后，用戶所能實現(xiàn)的 QoR 增益甚至可能超過此處所示的數(shù)字。