設計約束概述

設計約束就是定義編譯過程中必須滿足的需求，只有這樣才能保證在板子上工作時功能正確；但不是全部約束在所有過程中都會使用，比如物理約束只用在布局和布線過程中；Vivado工具的綜合和實現算法是時序驅動型的，因此必須創建合適的時序約束；我們必須根據應用需求選擇合理的約束，過度約束或約束不足都會造成問題；

老版的ISE開發工具使用UCF（User Constraints File）文件進行約束；新的Vivado開發工具使用XDC（Xilinx Design Constraints）進行約束；在描述設計約束方面，標準SDC（Synopsys Design Constraints）格式已經發展超過了20年，且應用最為廣泛，XDC約束正是基于SDC格式，再加入Xilinx的一些物理約束；

XDC約束可以用一個或多個XDC文件，也可以用Tcl腳本實現；XDC文件或Tcl腳本都要加入到工程的某個約束集（set）中；雖然一個約束集可以同時添加兩種類型約束，但是Tcl腳本不受Vivado工具管理，因此無法修改其中的約束；

管理約束

Vivado支持使用一個或多個約束文件，對于大型設計來說，僅使用一個約束文件往往不便于維護；最好的做法是將時序約束和物理約束分別保存到不同的文件中，或者某些特定模塊使用一個單獨的約束文件 ；

約束文件（XDC文件或Tcl腳本）需要添加到約束集中，一個工程可以包含多個約束集，一個文件也可以添加到多個約束集中；下圖顯示了一個工程中的約束集，該約束集包括兩個約束文件，分別為物理約束和時序約束：

另外注意，生成IP核時，IP核的約束文件不會顯示在上圖列表中，只會顯示在IP Sources窗口中；

默認情況下，所有的XDC約束文件會同時應用于綜合和實現過程中。在XDC文件的屬性窗口中修改如下圖中選項，可以選擇XDC文件的使用階段，對應的屬性為USED_IN_SYNTHESIS和USED_IN_IMPLEMENTATION：

但是DONT_TOUCH屬性不受上述設置的限制，比如在綜合XDC中使用了DONT_TOUCH屬性，即使Used In沒有選中Implementation，該屬性仍會傳遞到實現過程中 ；

排列約束的順序

XDC約束會遵循一套優先級規則，按順序應用于設計中；當多個物理約束之間產生矛盾時，順序靠后的約束會覆蓋之前的約束；比如一個I/O端口前后綁定了兩個管腳位置，則順序上靠后的約束會起作用；推薦的約束順序如下：

時序聲明部分：主時鐘、虛擬時鐘、生成的時鐘、時鐘組、總線斜率約束、輸入與輸出延遲約束。

時序異常部分：虛假路徑、最大延遲/最小延遲、多時鐘路徑、個例分析、屏蔽的時序。

物理約束部分：可以放在時序約束之前或之后，最好存儲在一個單獨的約束文件中

約束應該以時鐘定義開始，因為時鐘必須在被其它約束引用之前定義好；如果在定義之前便引用了時鐘，會導致錯誤發生，該約束將被忽略掉；約束文件的順序相當重要，設計者應該確保每一個文件中的約束不依賴于其它文件中的約束；如果這種情況發生，應該考慮合并兩個文件，或者按照更合理地方式重新組織約束文件；

所有新的約束都會保存到標記為target的XDC文件的末尾；如果約束集中有多個XDC文件，大多數情況下target文件不是最后一個XDC文件，這就導致保存到磁盤上的約束順序和內存中的約束順序并不相同（內存中執行相當于在最后插入一個新約束，而存儲到磁盤中確是在中間插入了一個新約束），因此設計者需要驗證最終存儲的約束順序可以正確工作；

一般來說，在不包含IP核的工程中，所有的約束被放在一個約束集中，約束的排列順序表明了約束的讀取順序，排在最前面的約束最先被讀取，可以通過上下移動約束文件來改變約束讀取的順序，如下圖所示：

許多IP核會自帶一個或多個XDC文件，如下圖所示：

默認情況下，IP核的XDC文件在用戶編寫的XDC文件之前讀取，在該情況下允許IP核創建一個參考時鐘，同時也允許用戶XDC文件覆蓋IP核的物理約束；但是也有例外，如IP核需要用到用戶定義的時鐘時，此時IP核的XDC文件在用戶XDC文件之后讀??！

每個約束文件都有PROCESSING_ORDER屬性，屬性值可以是：EARLY，必須首先被讀?。籒ORMAL，默認；LATE：必須最后被讀??；

注意IP核的XDC文件只會是early或者late，而不會是normal!對于包含依賴時鐘的IP核，XDC文件的讀取順序屬性設置為late；對于不包含依賴時鐘的IP核，XDC文件的讀取順序設置為early；同時，對于多個IP核的XDC文件，如果他們有相同的PROCESSING_ORDER屬性，則讀取順序由IP核的導入順序決定，一般無法更改！

下面對XDC文件的讀取順序做一個總結，從上到下的讀取順序：

1.用戶XDC文件，標記為early;

2.IP核XDC文件，標記為early;

3.普通的用戶XDC文件(normal)；

4.IP核XDC文件，標記為late(對用戶時鐘存在依賴);

5.用戶XDC文件，標記為late;

屬性值為LATE的IP核XDC文件名稱為_clocks.xdc；在Tcl控制臺中使用report_compile_order -constraints命令可以報告所有約束文件的狀態，其中就包括PROCESSING_ORDER屬性;

約束方法

完成約束有兩種方法：（1）.直接編輯XDC文件；（2）.打開某一階段的設計，Elaborated設計、綜合后設計或實現后設計，直接對某對象進行約束；采用第2種方法，在編輯約束時，Tcl控制臺中會顯示等價的XDC命令，該命令是存儲在內存中的，在綜合或實現前，必須點擊Save Constraints保存約束；如果是新的約束，則會添加到標記為target的約束文件中；如果是對已存在的約束進行修改，則會修改XDC文件中原來位置的命令；

上述兩種約束方法最好不要同時使用，否則容易混淆導致約束沒有起作用；如果需要在兩種約束方法之間切換，要確保保存了當前約束，或者重新導入一下設計，下圖給出了約束的流程圖：

管腳賦值與平面規劃

本節介紹兩種使用GUI完成約束的方法。第一種是創建與編輯頂層端口位置，即通常所說的管腳賦值（Pin Assignment）；打開某一階段設計后，將視圖切換為“I/O Planning”，如下圖：

切換到該視圖后會自動打開如下4個窗口：

Device：編輯端口在器件平面規劃圖中的位置；

Package：編輯端口在器件封裝中的位置；

I/O Ports：可以選擇一個端口，拖動到Package或Device窗口中的某個位置，也可以觀察每個端口的各個屬性；

Package Pins：觀察每個I/O Bank的資源利用率；

另一種是平面規劃（Floorplanning），主要是創建和編輯Pblock來限制某些對象的布局范圍；打開某一階段設計后，將視圖切換為“Floorplanning”，如上圖；切換到該視圖后會自動打開如下3個窗口：

Netlist：選擇賦值到某個Pblock的單元對象；

Physical Constraints：觀察設計中的Pblock和各自的屬性；

Device：創建或編輯Pblock在器件中的形狀和位置；

在Netlist窗口中選擇某些單元，將其拖動到Device窗口的目標位置中，即可將單元位置約束到某一特定的BEL或SITE。這兩個部分都可以稱作“物理約束”，另外還有“時序約束”，需要借助時序約束向導；

XDC模板

vivado為verilog和XDC文件提供了大量的語言模板，如下圖所示：

XDC模板主要分為三大類，如下圖所示：時序約束；物理約束；配置

創建綜合約束

Vivado綜合引擎將設計的RTL描述轉換為一個工藝映射網表，在這個階段可以使用約束來指導綜合引擎解決設計需求。涉及到的約束包括4個方面：

RTL屬性：綜合屬性在綜合篇中有詳細介紹，這些約束通常與某些邏輯部分的映射方式直接相關，比如保留特定的寄存器和網絡防止被優化、控制最終網表中的設計層次等等；

時序約束：可以在該階段起作用的時序約束有create_clock、create_generated_clock、set_input_delay、set_output_delay、set_clock_groups、set_false_path、set_max_delay和set_multicyclye_path；

物理與配置約束：這部分約束不會作用于該階段，因此會被綜合引擎忽略；

Elaborated設計約束：在綜合階段，網絡延遲模型還不精確，因此主要目標是得到一個滿足時序或時序違背程度較小的綜合網表，可以對Elaborated設計分析RTL設計得到的對象進行約束；可以利用Tcl控制臺來測試想要執行的XDC命令是否有語法錯誤，再保存到XDC文件中；

一些RTL名稱在Elaborated設計中會被修改或刪除，因此不能直接使用RTL設計中的對象名稱；部分對象如頂層端口、實例化原語在RTL和Elaborated設計中總是相同的，下面給出一些名稱會發生變化的例子，需要特別注意：

單bit寄存器：RTL中的信號名稱添加后綴_reg，如RTL中定義reg data，則對應的寄存器名稱為data_reg；

多bit寄存器：與單bit寄存器相同，但約束時必須單獨約束每個bit或直接當作一組約束，如定義reg [3:0] data，可以對reg[0]或reg[*]約束，但不能對reg[1:0]約束；

合并的寄存器和網絡：存儲塊、DSP、移位寄存器等接口會將幾個設計對象合并到一個資源中，導致RTL源文件中的一些寄存器或網絡不會出現在Elaboratd設計中，對于這類對象，無法直接約束，應該尋找與其相連的其它寄存器或網絡；

層次名稱：默認情況下，綜合可能會將某些層次結構展開，融為一體（可以用-flatten_hierarchy設置），約束時要使用完整的層次名稱來指定對象，而不要使用通配符‘*’，如‘inst_A/inst_B/data_reg’；

總而言之，就是要明確約束的對象，否則很容易造成約束沒有按設計者意圖進行；比如不要對層次接口的管腳做約束，因為這些管腳僅僅起到了連接各個層次的作用；也不要對與組合邏輯運算符相連的網絡做約束，因為組合邏輯運算會采用查找表方式實現，導致該網絡并不會出現在綜合網表中 ；

創建實現約束

綜合過后，將綜合網表和XDC文件（或Tcl腳本）一同導入到內存中，用于實現過程；導入時必須觀察Vivado報告的消息，據此來驗證和修改那些沒有應用成功的約束；正如綜合約束使用的Elaborated設計對象名稱會和RTL中名稱不同，實現約束使用的綜合網表對象名稱也可能會和Elaborated設計中的名稱不同；如果發生上述情況，則必須重新創建某些約束，并僅作用于實現階段；

前文也說過物理和配置約束僅會在實現階段起作用，因此也最好存儲到一個單獨的XDC文件中，設置為僅作用于實現階段。綜合過程中可能會復制某些寄存器，以提高設計性能，必須使用get_cells/get_pins -include_replicated_objects命令獲取對象，才能確保XDC約束也作用于復制出來的寄存器；當然很難直接感覺到哪個對象需要像上述這樣做，幸好在Vivado中運行Methodology檢查時，相關信息會報告在XDCV-1和XDCV-2檢查信息中，供設計者參考；

約束作用域

一個特定的XDC文件中的約束可以選擇僅作用于一個特定的模塊，或設計中的特定單元，這種約束方式可稱作塊級約束；實現機制稱作約束作用域機制；默認情況下，IP Catalog中導出的所有IP核都采用這種約束方式；該機制通過設置XDC文件的兩個屬性實現：

SCOPED_TO_REF：設置模塊名稱，約束僅應用于設定模塊中的所有實例；

SCOPED_TO_CELLS：給出應用約束的層次單元名稱列表；

導出IP核時，輸出的XDC文件會自動完成上述兩個屬性的設置。如果設計中需要為某個子模塊進行單獨約束，也可以通過手動設置上述兩個屬性實現；

約束效率

編寫時序約束時，首要目標是讓約束變得簡單，僅為相關的網表對象設置約束，即為約束提供盡可能少的作用對象，以便精確并安全地覆蓋到預期的時序路徑；沒有效率地約束會導致更長的運行時間、更大的內存占用率，最壞的情況是覆蓋到比預期更多的路徑從而與其它約束產生沖突，導致設計出現時序異常 ；

Vivado中Methodology檢查的XDCB-1會報告涉及到超過1000個對象的時序約束，以防止出現時序異常情況。此外，還可以打開某一階段設計后，使用如下命令查看相關報告：

report_exceptions -coverage：給出每個時序異常的邏輯路徑范圍，將該時序異常作用的對象數量，與起點到端點間以有效的方式覆蓋的對象數目作比較；

report_exceptions -ignored：給出被其它時序約束覆蓋掉的時序約束，如set_false_path會被set_clock_group覆蓋而不起作用。應考慮修改約束或刪掉不起作用的約束；

report_exceptions -ignored_objects：給出被忽略的起點與斷點列表，如起點和斷點之間不存在設定的路徑，就會導致被忽略；

下面給出幾種改善約束運行時間的方法：

1.優化管腳查詢方式

使用get_pins代替get_cells會對運行時間有明顯的影響。如果需要從設計的所有管腳中查找一個管腳列表，不要直接根據管腳名字查詢，最好是先用get_cells定位管腳所在的單元，再從該單元中查找管腳，示例如下：

get_pins –hier * -filter {NAME=~xx*/yy*} //不推薦的方式

get_pins –filter {REF_PIN_NAME=~yy*} –of [get_cells –hier xx*] //最佳方式

2.不要使用all_registers查詢

盡可能地將對all_registers的查詢代替為對cells、pins的查詢，因為使用all_registers會在大量對象中進行搜索，示例如下：

set_multicycle_path –from [all_inputs] –to [all_registers –clock clk1]

set_multicycle_path –from [all_inputs] –to [get_clocks clk1]

這兩條約束是等價的，但第二種方式的效率比第一種要高很多；

審核編輯 ：李倩