ug1292深度解析

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

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

（圖片來(lái)源ug1292, page 1）

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

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

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

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

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