ug1292深度解析

ug1292第一頁的主題是初始設(shè)計檢查。這一步是針對綜合后或者opt_design階段生成的dcp。盡管在Vivado下，從功能仿真到綜合、布局布線、直至生成.bit文件是相對自動化的流程，但是解決時序違例仍然是一個復(fù)雜且耗時的過程。僅僅靠log信息或者布線后的時序報告往往很難定位，這是因為實現(xiàn)過程中的每一步（opt_design邏輯優(yōu)化，place_design布局, phys_opt_design物理優(yōu)化, route_design布線）都會做一些優(yōu)化，這些優(yōu)化可能會導(dǎo)致關(guān)鍵路徑被掩蓋，例如，有時發(fā)現(xiàn)設(shè)計中邏輯級數(shù)（Logic Level）較高的路徑時序收斂了，反倒是邏輯級數(shù)較低甚至為0的路徑出現(xiàn)時序違例。因此，采取按部就班的策略，檢查每一步的結(jié)果，及時且盡早發(fā)現(xiàn)設(shè)計中的問題是很有必要的。

初始設(shè)計檢查流程如下圖所示。對象是綜合后或opt_design階段生成的dcp。會依次執(zhí)行三個命令（圖中紅色標(biāo)記），生成三個報告：FailFast報告、時序報告和UFDM（UltraFast Design Methodology）報告。

（圖片來源ug1292, page 1）

report_failfast的一個便利之處是可以給出各類資源利用率的上限，如下圖所示，這是Vivado自帶例子工程cpu的FailFast報告?？梢钥吹?，對于LUT，利用率應(yīng)控制在70%以內(nèi)；觸發(fā)器（FD）應(yīng)控制在50%以內(nèi)；BlockRAM和DSP48可以達(dá)到80%。在這個報告中尤其要關(guān)注Status為Review的條目，這是會給時序收斂帶來負(fù)面影響的，需要優(yōu)化的。對于設(shè)計中存在Pblock情形，report_failfast提供了-pblock選項，對于SSI器件，report_failfast提供了-slr和-by_slr（需要在place_design階段生成的dcp下使用）選項。這樣，可針對某個pblock或某個SLR進(jìn)行分析。

report_timing_summary可以生成時序報告，除了查看時序違例路徑之外，該報告還可顯示時序約束是否存在潛在問題。如下圖所示，Check Timing下包含12個條目，這個階段需要格外關(guān)注是否有未約束的時序路徑，是否有Timing loop，同時還要關(guān)注時鐘約束是否合理。

report_methodology可以生成UFDM報告。該命令不僅可以檢查RTL代碼存在的問題，例如Block RAM沒有使用內(nèi)部Embedded Registers，DSP48用做乘法器時沒有使能MREG等，還可以檢查時序約束存在的問題。如圖所示，要尤其關(guān)注其中的Bad Practice。

對于這三個報告中存在的問題，要盡可能地在綜合階段或者opt_design階段加以解決，最終確保這三個報告足夠“干凈”，即所有隱患都被消除。

此外，對于大規(guī)模的設(shè)計，可針對設(shè)計中的關(guān)鍵模塊使用上述三個命令，因為這些關(guān)鍵模塊很有可能成為時序收斂的瓶頸。為了使用這三個命令，可以對關(guān)鍵模塊采用OOC（Out-of-Context）的綜合方式或單獨創(chuàng)建Vivado工程以便生成相應(yīng)的dcp。