在描述時(shí)序約束時(shí)，一個(gè)重要的原則是確保約束簡潔高效。簡潔高效意味著約束只針對指定的對象，即約束對應(yīng)的對象的個(gè)數(shù)（通常這些對象由命令get_pins、get_cells、get_nets、get_ports或get_clocks獲取）盡可能少，少的同時(shí)還要足夠的精確，能夠安全地覆蓋到期望的時(shí)序路徑。

既不會(huì)出現(xiàn)遺漏某些對象也不會(huì)出現(xiàn)包含了不期望的對象，兩者都會(huì)造成工具無法對相關(guān)路徑按照指定要求進(jìn)行時(shí)序分析，從而造成設(shè)計(jì)“偽收斂”。這通常會(huì)出現(xiàn)在使用-from、-to或-through等選項(xiàng)的約束中，例如：

set_clock_groups，set_false_path

set_max_delay，set_multicycle_path

等時(shí)序例外約束。

Vivado提供了一些方法用于分析時(shí)序例外約束的有效性，其中之一就是用命令report_exceptions生成時(shí)序例外報(bào)告。這里我們首先介紹一下這個(gè)命令的使用方法。 report_exceptions -scope_override

選項(xiàng)-scope_override可用于查看是否存在作用于某個(gè)子模塊的約束（約束的作用域僅限于該子模塊）被頂層約束部分或者全部覆蓋。注意這里僅限于子模塊約束與頂層模塊約束之間的覆蓋情況，而不會(huì)報(bào)告不同子模塊之間的約束覆蓋情況。借助此選項(xiàng)查看IP的約束是否被用戶約束所覆蓋將變得非常容易。如下圖所示，我們可以在生成報(bào)告的Status列發(fā)現(xiàn)IP約束被用戶約束覆蓋。

report_exceptions -coverage

選項(xiàng)-coverage可查看約束的覆蓋率，其描述形式是時(shí)序例外約束所施加的路徑的起點(diǎn)或終點(diǎn)的pin個(gè)數(shù)與-from/-through/-to選項(xiàng)所獲得的pin的個(gè)數(shù)的百分比。我們看一個(gè)例子，如下圖所示報(bào)告。其中的紅色方框可以看到這里使用的是set_max_delay，-from是通過get_cells獲得的，因?yàn)橹挥?個(gè)cell且時(shí)序路徑的起點(diǎn)是觸發(fā)器的時(shí)鐘端口，所以From的覆蓋率就是100%（觸發(fā)器只有1個(gè)時(shí)鐘端口）。

-to也是通過get_cells獲取，獲取到1個(gè)cell，這個(gè)cell也是觸發(fā)器，其數(shù)據(jù)端口是該約束對應(yīng)的時(shí)序路徑的終點(diǎn)。但實(shí)際上，觸發(fā)器除了數(shù)據(jù)端口之外，還有時(shí)鐘使能端口/復(fù)位端口，所以To的覆蓋率就是1/3也就是這里的33.33%。顯然，覆蓋率越高表明我們描述得越精確。

report_exceptions -ignored

選項(xiàng)-ignored可報(bào)告出設(shè)計(jì)中被完全覆蓋的約束（Totallyoverridden），需要注意的是不會(huì)報(bào)告部分被覆蓋的約束（PartiallyOverridden）。下圖中可以看到set_multicycle_path被set_max_delay所覆蓋。 ?

report_exceptions -ignored_objects

選項(xiàng)-ignored_objects可報(bào)告出被忽略的起點(diǎn)或終點(diǎn)。之所以被忽略是因?yàn)檫@些路徑不存在，例如下圖中觸發(fā)器的D端口恒接地，這樣在使用set_false_path -to時(shí)，-to的值如果是通過get_pins獲取到該觸發(fā)器的D端口， 那么這條路徑的終點(diǎn)就會(huì)被工具忽略，從而這條約束也就無效。

從編譯時(shí)間的角度看，描述約束時(shí)越精確越好。一個(gè)事實(shí)是在網(wǎng)表中pin的個(gè)數(shù)通常是cell個(gè)數(shù)的幾倍甚至幾十倍，因此直接搜索pins會(huì)比較耗時(shí)，Xilinx推薦的方法是利用cell和pin的關(guān)系，先找到cell再找到對應(yīng)的pin，例如：需要對下圖所示的兩個(gè)觸發(fā)器對應(yīng)的時(shí)序路徑進(jìn)行FalsePath約束，采用了三種方式。顯然，方案1和方案2會(huì)覆蓋到不期望的路徑，方案3最為精確，耗時(shí)也較少。



尤其是當(dāng)get_pins命令使用了通配符時(shí)，先get_cells再get_pins更為高效，如下圖所示方式。

另外，在約束中避免使用all_registers，該命令會(huì)返回設(shè)計(jì)中的所有觸發(fā)器。如果確需用all_registers，那么可通過選項(xiàng)-clock限定作用域，或者用get_clocks取代，如下圖所示。

時(shí)序約束的描述順序?qū)幾g時(shí)間也有很大影響。當(dāng)時(shí)序約束被加載到內(nèi)存時(shí)，時(shí)序引擎會(huì)對每條約束進(jìn)行驗(yàn)證。對于可能存在問題的約束，時(shí)序引擎會(huì)打印出相關(guān)的信息。一些約束可能會(huì)導(dǎo)致部分時(shí)序數(shù)據(jù)庫無效，還有一些約束可能需要更新時(shí)序數(shù)據(jù)庫以便正常運(yùn)行。

例如，MMCM自動(dòng)生成的時(shí)鐘若頻率或相位發(fā)生了改變，那么用到這個(gè)時(shí)鐘的相關(guān)約束就需要更新。交織的時(shí)序約束以及影響到時(shí)序數(shù)據(jù)庫的約束會(huì)對編譯時(shí)間產(chǎn)生較大影響。如下表格顯示了會(huì)對時(shí)序數(shù)據(jù)庫產(chǎn)生影響的一些Tcl命令。



其中最為耗時(shí)的描述方式是同時(shí)使用了set_disable_timing和all_fanin或all_fanout，如下圖所示。



根據(jù)上述表格，從編譯時(shí)間的角度來看，最優(yōu)的約束描述順序是：

（1）set_disable_timing，

set_case_analysis，

set_external_delay

（2）影響時(shí)序數(shù)據(jù)庫的約束如create_clock

（3）不需要更新時(shí)序數(shù)據(jù)庫的約束，例如

set_max_delay 我們看一個(gè)案例，如下圖所示：代碼第3至第10行為原始約束順序，這里將set_disable_timing和set_case_analysis放在了create_clock之后。

代碼第14行至第20行為推薦的約束順序，可以看到先描述set_disable_timing，之后是set_case_analysis，然后才是create_clock，同時(shí)將set_max_delay放在了最后。










審核編輯：劉清