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

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

（圖片來源ug1292, page 1）

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

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

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

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

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