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

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

（圖片來源ug1292, page 1）

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

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

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

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

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