在給FPGA做邏輯綜合和布局布線時，需要在工具中設定時序的約束。通常，在FPGA設計工具中都FPGA中包含有4種路徑：從輸入端口到寄存器，從寄存器到寄存器，從寄存器到輸出，從輸入到輸出的純組合邏輯。通常，需要對這幾種路徑分別進行約束，以便使設計工具能夠得到最優化的結果。下面對這幾種路徑分別進行討論。

(1)從輸入端口到寄存器：

這種路徑的約束是為了讓FPGA設計工具能夠盡可能的優化從輸入端口到第一級寄存器之間的路徑延遲，使其能夠保證系統時鐘可靠的采到從外部芯片到FPGA的信號。約束名稱：input delay. 約束條件的影響主要有4個因素：外部芯片的Tco，電路板上信號延遲Tpd，FPGA的Tsu, 時鐘延遲Tclk. Tco的參數通常需要查外部芯片的數據手冊。計算公式：input delay = Tco+Tpd+Tsu-Tclk. FPGA的Tsu也需要查FPGA芯片的手冊。FPGA速度等級不同，這個參數也不同。Tpd和Tclk需要根據電路板實際的參數來計算。通常，每10cm的線長可以按照1ns來計算. 例如：系統時鐘100MHz,電路板上最大延遲2ns, 時鐘最大延遲 1.7ns, Tco 3ns, FPGA的Tsu為0.2ns. 那么輸入延遲的值：max Input delay = 2+3+0.2-1.7=3.5ns. 這個參數的含義是指讓FPGA的設計工具把FPGA的輸入端口到第一級寄存器之間的路徑延遲（包括門延遲和線延遲）控制在 10ns-3.5ns=6.5ns 以內。

(2)寄存器到寄存器：

這種路徑的約束是為了讓FPGA設計工具能夠優化FPGA內寄存器到寄存器之間的路徑，使其延遲時間必須小于時鐘周期，這樣才能確保信號被可靠的傳遞。由于這種路徑只存在于FPGA內部，通常通過設定時鐘頻率的方式就可以對其進行約束。對于更深入的優化方法，還可以采用對寄存器的輸入和寄存器的輸出加入適當的約束，來使邏輯綜合器和布線器能夠對某條路徑進行特別的優化。還可以通過設定最大扇出數來迫使工具對其進行邏輯復制，減少扇出數量，提高性能。

(3)寄存器到輸出：

這種路徑的約束是為了讓FPGA設計工具能夠優化FPGA內部從最后一級寄存器到輸出端口的路徑，確保其輸出的信號能夠被下一級芯片正確的采到。 約束的名稱:output delay,約束條件的影響主要有3個因素：外部芯片的Tsu，電路板上信號延遲Tpd，時鐘延遲Tclk.Tsu的參數通常需要查外部芯片的數據手冊。計算公式：output delay = Tsu+Tpd-Tclk.例如：系統時鐘100MHz,電路板上最大延遲2ns, 時鐘最大延遲 1.7ns, Tsu 1ns, 輸出延遲的值：max output delay = 1+2-1.7=1.3ns . 這個參數的含義是指讓FPGA的設計工具把最后一級寄存器到輸出端口之間的路徑延遲（包括門延遲和線延遲）控制在 10ns-1.3ns=8.7ns 以內。

(4)從輸入端口到輸出端口：

這種路徑是指組合邏輯的延遲，指信號從輸入到輸出沒有經過任何寄存器。給這種路徑加約束條件，需要虛擬一個時鐘，然后通過約束來指定哪些路徑是要受該虛擬時鐘的約束。在Synplifypro和Precision中都有相應的約束來處理這種路徑。
關于輸入輸出延遲的一些參數，如果要把這些參數和xilinx的軟件結合起來，也不是一件容易的事情。以前似乎大家也不太看重約束條件的設定，大多時候都是無論如何先上板，然后通過signaltap和Chipscope來調。當FPGA規模大了之后，布線一次都需要很長時間，這種方法的弊端就越來越嚴重。實際上可以借鑒ASIC的設計方法：加比較完善的約束條件，然后通過RTL仿真，時序分析，后仿真來解決問題，盡量避免在FPGA電路板上來調試。altera最先意識到這一點，它采用了Synopsys的SDC格式。SDC的格式也得到了邏輯綜合器的支持。而且設定方法比較容易掌握。這個帖子會詳細討論一下這種格式的約束設定方法。

時鐘的設定方法：時鐘要分成兩種，一種是從端口上直接輸入的時鐘，另一種是在FPGA內部產生的時鐘。內部產生的時鐘又要分成兩種，從鎖相環出來的（包括altera的PLL和Xilinx的DLL)和從邏輯單元出來的，例如一般的計數器分頻就是這種情況。從鎖相環出來的時鐘可以通過端口直接加，因為一般的綜合工具和布線工具都能夠自動的把端口的時鐘約束傳遞到鎖相環，并且根據鎖相環的倍頻關系自動施加到下一級。而從邏輯單元出來的就需要單獨對其進行約束。

在SDC格式中，創建時鐘的命令 create_clock, 后面要帶3個參數：name ,period, waveform. name的含義是指創建這個時鐘約束的名字，而不是時鐘本身的名字。要把這個約束和時鐘信號關聯起來，還需要在后面加些東西。period的單位缺省是ns. waveform是用來指定占空比。除了這三個參數以外，常常還要加 get_ports的命令，來指定時鐘的輸入端口。下面的例子是一個較為完整的設定時鐘的例子：
create_clock -name clk1 -period 10.000 –waveform { 2.000 8.000 } [get_ports sysclk]
這個例子表示，有一個clk1的約束，在這個約束中設定了時鐘的周期為10ns, 占空比為2ns低電平，8ns高電平。 這個叫做clk1的約束是針對sysclk這個端口的。
如果是利用內部鎖相環分頻出來很多其他時鐘的約束,可以不再另外施加其他約束，邏輯綜合器和布線器都能根據鎖相環的參數自動計算。如果是利用內部的邏輯單元分頻出來的信號，則必須利用get_registers指定分頻的寄存器名。例如上例：
create_clock -name clk1 -period 10.000 –waveform { 2.000 8.000 } [get_registers cnt_clk].
對于邏輯單元分頻的時鐘信號，也可以采用命令create_generated_clock會更加精確。舉例如下：
create_generated_clk -name clk2 -source [getports sysclk] -div 4 [get_registers cnt_clk]
這個約束命令描述了一個clk2的約束，約束的對象是由sysclk分頻4次得到的時鐘，這個時鐘是由cnt_clk這個寄存器產生的。

在高速的系統中，對時鐘的描述可能會要求的更多，更加細致。例如，會要求對時鐘的抖動和時鐘的延遲進行描述。在SDC的文件格式中，可以通過兩個命令來描述：set_clock_uncertainty 和 set_clock_latency 來設定。
時鐘的延遲相對來講比較簡單。延遲一般分為外部延遲和內部時鐘線網的延遲。通常在約束時只對外部延遲做約束，在set_clock_latency的命令后帶 -source的參數就可以了。 例如：
set_clock_latency -source 2 [get_clocks {clk_in}]
時鐘的抖動要稍微復雜一些。因為這個值不但會影響到對Tsu的分析，也會影響到對Thold的分析。因此，采用set_clock_uncertainty的參數要多一些。如果要理解這個命令對系統時序分析的影響，就需要對altera的延時計算的概念需要做更多的說明。

對于set_clock_uncertainty的情況，就稍微復雜一些。因為set_clock_uncertainty的值既影響建立時間的計算，也影響保持時間的計算，因此，需要在設定時分別指明：
set_clock_undertainty –setup 0.500 –from clkA –to clkA
set_clock_uncertainty –hold 0.300 –from clkA –to clkA

前面的內容里面提供了計算輸入輸出延遲的計算方法。輸出延遲的命令是set_output_delay. 有幾個參數要加：參考時鐘，最大最小值，和端口的名稱。如下面的例子中描述。
set_output_delay -clock CLK -max 1.200 [get_ports OUT]
set_output_delay -clock CLK -min 0.800 [get_ports OUT]
輸入延遲的命令很類似：
set_input_delay -clock CLK -max 2.000 [get_ports IN]
set_input_delay -clock CLK -min 1.600 [get_ports IN]

對一些特殊的設計要求，例如不關心的數據傳遞路徑和多拍的路徑，還需要增加false path 和 Multicycle的設定。這兩個約束比較簡單，容易設定，但是非常關鍵。如果設定的不好，系統性能會大打折扣。false path是指在時序分析中不考慮其延遲計算的路徑。例如有些跨越時鐘域的電路等。設定的方法：
set_false_path -from [get_clocks clkA] -to [get_clocks clkB]
set_false_path -from regA -to regB
第一條命令是設定了從時鐘域clkA到時鐘域clkB的所有路徑都為false path。第二條命令設定了從 regA到regB的路徑為false path。這兩種路徑在做時序分析時都會被忽略。multicycle的設定和false path的設定方法差不多。

為了讓邏輯綜合器和布局布線器能夠根據時序的約束條件找到真正需要優化的路徑，我們還需要對時序報告進行分析，結合邏輯綜合器的時序報告，布線器的時序報告，通過分析，可以看出是否芯片的潛能已經被完全挖掘出來