簡(jiǎn)介

許多 FPGA 設(shè)計(jì)都難以達(dá)成所期望的性能目標(biāo)。原因不盡相同，以下列出的只是其中部分可能的原因：

未遵循 UltraFast 設(shè)計(jì)方法

時(shí)序約束不良

過高資源利用率

控制集過多

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

邏輯層次過多，難以達(dá)成目標(biāo)性能

布局規(guī)劃不良

布線擁塞

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

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

Report QoR Suggestions

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

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

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

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

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

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

在“建議運(yùn)行”流程中，用戶可以再次調(diào)用“report_qor_suggestions”。這整個(gè)流程是可重復(fù)的，通過將來(lái)自前一輪運(yùn)行的建議與當(dāng)前輪次的建議累積起來(lái)即可組成單個(gè)文件并饋送到最新一輪的建議運(yùn)行中。

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

write_qor_suggestions -of_objects ［get_qor_suggestions -filter {some_fillter}

如果在此流程中多次運(yùn)行“report_qor_suggestions”，并在流程的不同階段生成相同的建議，那么 RQS 將自動(dòng)對(duì)重復(fù)的建議進(jìn)行管理。

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

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

案例分析示例

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

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

建議名稱

首先請(qǐng)注意名稱。第一項(xiàng)建議的名稱 （NAME） 為 RQS_XDC-1-1。NAME 用于指示建議的類別。這項(xiàng)建議來(lái)自于 XDC 類別。

總共有 6 個(gè)類別：

? 利用率 （Utilization）

? XDC

? 時(shí)鐘設(shè)置 （Clocking）

? 擁塞 （Congestion）

? 時(shí)序 （Timing）

? 策略 （Strategy）

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

這些建議通常會(huì)對(duì)大量路徑產(chǎn)生影響，并且還能降低設(shè)計(jì)收斂流程后期的擁塞和時(shí)序問題的嚴(yán)重程度。解決時(shí)序和擁塞問題的建議與解決時(shí)鐘設(shè)置、利用率和 XDC 問題的建議總是一并應(yīng)用，無(wú)法拆分，但前兩類建議可能導(dǎo)致利用率增高，并且時(shí)鐘設(shè)置修復(fù)后可能就不再需要。

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

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

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

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

report_qor_suggestions -max_paths 《大于 100 的值》

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

自動(dòng)建議

接下來(lái)請(qǐng)看表中的最后一條建議 RQS_CLOCK-1-1。在該表格中可以看到這是一項(xiàng) AUTOMATIC 建議。此建議將對(duì) BUFG 驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用 CLOCK_DELAY_GROUP 屬性。

倒數(shù)第二條建議 RQS_CLOCK-2-1 為手動(dòng) （AUTOMATIC = 0） 建議。它建議更改時(shí)鐘設(shè)置拓?fù)浣Y(jié)構(gòu)，通過將 BUFGCE + MMCM 除法器更換為含內(nèi)置除法器的 BUFGCE_DIV 來(lái)進(jìn)一步優(yōu)化此拓?fù)浣Y(jié)構(gòu)。Vivado 無(wú)法自動(dòng)交換這些Buffer，因此需要用戶手動(dòng)執(zhí)行 RTL 編輯。

顧名思義，AUTOMATIC 建議簡(jiǎn)單易用，而手動(dòng)建議則更為復(fù)雜。以下顯示了自動(dòng)建議和手動(dòng)建議所需的不同方法。

自動(dòng)

? 將屬性應(yīng)用于對(duì)象

? 將開關(guān)應(yīng)用于命令

? 對(duì)約束稍作修改

手動(dòng)

? 需要執(zhí)行 RTL 設(shè)計(jì)編輯

? 需要更新約束

? 需要更多用戶分析

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

QoR 增益

以下顯示的是 30 個(gè)設(shè)計(jì)使用如下條件后所得結(jié)果：

? “place_design”Explore 指令

? 不含建議的“參考運(yùn)行 （Reference Run）”與相同流程的“建議運(yùn)行 （Suggestion Run）”對(duì)比結(jié)果

“place_design”生成的時(shí)鐘設(shè)置建議

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

僅對(duì)自動(dòng) （AUTOMATIC） 建議進(jìn)行比較

QoR 增益通過兩種方式來(lái)測(cè)量：

通過觀察 WNS 的絕對(duì)提升量（易于理解的指標(biāo)）。

觀察建議運(yùn)行相比參考運(yùn)行中所有失敗的時(shí)鐘的幾何平均增益（更可靠的 QoR 增益指標(biāo)）。

以下示例來(lái)自于先前表格對(duì)應(yīng)的設(shè)計(jì)：

藍(lán)色高度表示“參考運(yùn)行”，橙色高度表示“建議運(yùn)行”的新 WNS。可以看到，RQS 對(duì)設(shè)計(jì)的 WNS 的提升效果顯著。全部 30 項(xiàng)設(shè)計(jì)的平均 WNS 增益達(dá) 0.648 ns。

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

這些設(shè)計(jì)中的幾何平均值的平均增益為 12.1%。

當(dāng)然其中有特別突出的增益。在排名前 4 的設(shè)計(jì)中，QoR 平均提升 34.7%。

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

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

解決時(shí)鐘設(shè)置問題時(shí)，QoR 增益超過 10%

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

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

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