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

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

set_clock_groups，set_false_path

set_max_delay，set_multicycle_path

等時序例外約束。

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

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

report_exceptions -coverage

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

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

report_exceptions -ignored

選項-ignored可報告出設計中被完全覆蓋的約束（Totallyoverridden），需要注意的是不會報告部分被覆蓋的約束（PartiallyOverridden）。下圖中可以看到set_multicycle_path被set_max_delay所覆蓋。 ?

report_exceptions -ignored_objects

選項-ignored_objects可報告出被忽略的起點或終點。之所以被忽略是因為這些路徑不存在，例如下圖中觸發器的D端口恒接地，這樣在使用set_false_path -to時，-to的值如果是通過get_pins獲取到該觸發器的D端口， 那么這條路徑的終點就會被工具忽略，從而這條約束也就無效。

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



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

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

時序約束的描述順序對編譯時間也有很大影響。當時序約束被加載到內存時，時序引擎會對每條約束進行驗證。對于可能存在問題的約束，時序引擎會打印出相關的信息。一些約束可能會導致部分時序數據庫無效，還有一些約束可能需要更新時序數據庫以便正常運行。

例如，MMCM自動生成的時鐘若頻率或相位發生了改變，那么用到這個時鐘的相關約束就需要更新。交織的時序約束以及影響到時序數據庫的約束會對編譯時間產生較大影響。如下表格顯示了會對時序數據庫產生影響的一些Tcl命令。



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



根據上述表格，從編譯時間的角度來看，最優的約束描述順序是：

（1）set_disable_timing，

set_case_analysis，

set_external_delay

（2）影響時序數據庫的約束如create_clock

（3）不需要更新時序數據庫的約束，例如

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

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










審核編輯：劉清