在不同的資料上看到關于MUX 的時序約束的兩個示例，分享一下

例子1

一、MUX前沒有邏輯電路的時鐘結構

時鐘設計的一般原則是在靠近時鐘源頭的地方將各種所用頻率時鐘都產生，再引給內部邏輯使用，并且最好用一個模塊單獨處理，所以兩個輸入時鐘一般來自端口輸入或PLL輸出，在經過MUX前不驅動任何數字邏輯；

首先創建兩個源時鐘：

create_clock –name clk1 –period $clk_period $clk1_src_pin –add
create_clock –name clk2 –period $clk_period $clk2_src_pin –add

對于MUX后面的約束，分為同步異步兩種情況分開討論：

異步

如果MUX的兩個輸入時鐘是MUX后都可以不創建生成時鐘，工具基于兩個時鐘分別進行時序分析，只需用set_clock_groups設定一下兩個時鐘的異步關系：

set_clock_groups –asynchronous –name clk_async –group “clk_1” –goup “clk2”

同步

對于MUX的兩個輸入時鐘同步的情況，可以抽象成如下的結構：

由于時鐘只能穿過時序邏輯，對于時序邏輯的輸出，STA工具認為是數據，所以分頻reg的Q端必須要創建分頻時鐘；

由于該時鐘定義點是時序器件，此時不能加-comb選項：

create_generated_clock –name clk_div $clk_div_pin –divide_by N –master clk_src –source $clk_src_pin –add

對于MUX后面的約束，存在以下幾種約束方法：

1.MUX后面不創建生成時鐘

由于MUX任何時候只能讓一路通過，MUX后可不創建時鐘，此時將clk_scr和clk_div設置為logical_exclusive即可；

set_clock_groups –logical_exclusive –name clk_div_logi_async –group “clk_src” –goup “clk_div”

由于時鐘樹的Last common point在MUX后，PT（prime time）會自動進行CRPR補償，即使不設邏輯互斥，根據PT的分析結果看，也不會引入悲觀分析；

2.MUX后創建一個生成時鐘

由于clk_src的頻率更高，所以以clk_scr為master_clock

此時加與不加-comb的區別：

（a）加-comb選項

create_generated_clock –name clk_mux0_clk_scr $mux_y_pin –devide_by 1 –master clk_scr –source $clk_scr_pin –add –comb

此時工具在追clk_mux0_clk_scr的source時會強制走組合路徑，即通過MUX/I0，PT計算clock latency的時候MUX只分析MUX/I0；

（b）不加-comb選項

對于clk_mux0_clk_src這個生成時鐘，PT計算其時鐘樹延遲（clock latency）時，會分別計算MUX的兩個輸入路徑，選擇對時序結果更悲觀的，會引入過度的悲觀；

在進行setup檢查時，對capture clock latency計算會采用ckl_src → MUX/I0這條路徑；在進行hold檢查時，對capture clock latency 計算會采用ckl_src → DIV_N → MUX/I1的路徑；對于launch 時鐘latency的計算也會出現上述情況；

3.MUX后創建兩個生成時鐘

MUX后創建兩個生成時鐘，并且設physical_exclusive，這是更常見的做法

create_generated_clock –name clk_mux0_clk_scr $mux_y_pin –devide_by 1 –master clk_scr –source $clk_scr_pin –add –comb
create_generated_clock –name clk_mux1_clk_div $mux_y_pin –devide_by N –master clk_div –source $clk_div_pin –add

set_clock_groups –pysical_exclusive –name clk_mux_phy_async –group “clk_mux0_clk_scr” –goup “clk_mux1_clk_div”

二、MUX前有邏輯電路的時鐘結構

如下圖：時鐘源clk_src在MUX前已經驅動部分邏輯，又對此時鐘進行分頻和選擇，后面邏輯reg1、reg2的時鐘需要切換，而且reg0跟reg1、reg2之間有路徑交互；

1.上述第一種約束方法，即MUX后面不創建生成時鐘

會存在將reg0和reg1設成異步的問題，導致部分同步路徑沒有進行時序檢查；

當MUX/I1選通的時候，reg0的時鐘為clk_src，reg1的時鐘為clk_div，而這兩個clk是logical_exclusive的；

2.上述第二種約束方法，即MUX后面只創建一個生成時鐘

由于生成時鐘的master_clock設為I0傳來的clk_src，會將I1傳來的clk_div時鐘擋住，工具無法用clk_div時鐘進行分析和優化；

此時所有時鐘樹的Last common point在MUX前，工具無法進行 CRPR 補償；

此時加與不加-comb的區別：

（a）加-comb選項

對于從reg0到reg1這條timing path的capture clock latecy，工具只會去分析經過MUX/I0的情況；

當MUX切換到I1時，由于經過寄存器DIV_N分頻的路徑一般比MUX/I0的路徑延時要長，reg1的時鐘樹可能變長，這就可能導致setup不滿足時序要求；

（b）不加-comb選項

同樣對于reg0到reg1這條timing path，工具按照悲觀原則去分析；

3.上述第三種約束方法，即MUX后面創建兩個個生成時鐘

雖然麻煩，但是最準確；

4.方法四

除了上述三種方法外，還有一種方法；如下圖所示，在MUX/I0這一路插入一個buffer，在buffer后面創建一個生成時鐘，然后和clk_div設置logical exclusive即可，MUX后面不需要再創建時鐘；

create_generated_clock –name clk_buffer $buffer_pin –devide_by 1 –master clk_src –source $clk_src_pin –add

set_clock_groups –logical_exclusive –name clk_buffer_div_logi_async –group “clk_buffer” –goup “clk_div

5.更復雜的情況

如果是比上述更復雜的情況，例如下圖，DIV_N還有一路單獨驅動reg3；對于這種結構，上述方法（4）就不適用了，因為當MUX選擇I0的時候，存在reg2和reg3為異步的問題；

總結

正確的約束，能讓工具看到正確的路徑；

但是當clk_src到MUX的兩個輸入延時幾乎一致的時候，工具無論選擇走哪路，差別都很小，也就幾乎不會影響時序檢查的結果了；所以電路真正實現還是要靠將兩路做等長；

因此，盡量將時鐘產生邏輯放在一個模塊里面，且盡量放在功能邏輯之前；

例子2

如下圖這個例子：

約束1

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 UMUX/Y -source FFdiv2/CK –master CLK –add
create_generated_clock -name CLKdiv4 -divide_by 4 UMUX/Y -source FFdiv4/CK -master CLK –add

set_clock_groups -physically_exclusive -group {CLK} -group {CLKdiv2} –group {CLKdiv4}

這樣約束會有幾個問題：

（a）timing report中缺少master clock的group

這是因為每個create_generated_clock約束都會覆蓋該點存在的任何其他時鐘，除非它們也在該點創建了生成時鐘并使用 -add 選項；

（b）Clock Source Latency Path問題

例如一條從FF1到FF2的setup timing path：launch path經過UMUX/C，capture path經過UMUX/A，如示例一中所述，悲觀分析了；

這是因為create_generated_clock的-source選項指定的pin/port處，工具會查找上面存在的所有Clock以及它的相位關系，然后來確定哪個是master clock以及它的相位和generatedclock是否滿足定義的相位關系（同相或反相），但它不會控制source latency path；

盡管我們為CLKdiv2_mux指定了“ -source FFdiv2/CK”，但它不會強制source latency path通過該引腳。相反，PT觀察到在引腳FFdiv2/CK處存在與generated clock同相位的時鐘CLK。然后，工具將搜索所有可能的同相路徑，使其返回時鐘源CLK，時鐘源是名為CLK的輸入端口；

由于這些是setup路徑，因此返回輸入端口CLK的最慢同相路徑是通過FFdiv4的路徑，最快的同相路徑是通過未分頻的路徑；

約束2

引導生成時鐘的source latency路徑的最佳方法是直接在分頻reg的Q創建生成時鐘；

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK

set_clock_groups -physically_exclusive -group {CLK} -group {CLKdiv2} –group {CLKdiv4}

約束3（crosstalk問題）

在上面的約束中，CLKdiv2和CLKdiv4不會同時出現，因此PT也不會分析他們之間的SI(物理互斥不會計算SI)；然而在這兩個時鐘在MUX前是可以同時出現的；

修改約束如下：

create_clock -period 10 CLK

create_generated_clock -name CLKdiv2 -divide_by 2 FFdiv2/Q -source FFdiv2/CK
create_generated_clock -name CLKdiv4 -divide_by 4 FFdiv4/Q -source FFdiv4/CK

create_generated_clock -name CLK_mux -combinational UMUX/A -source UMUX/A
create_generated_clock -name CLKdiv2_mux -combinational UMUX/B -source UMUX/B
create_generated_clock -name CLKdiv4_mux -combinational UMUX/C -source UMUX/C

set_clock_groups -physically_exclusive 
-group {CLK_mux} 
-group {CLKdiv2_mux} 
-group {CLKdiv4_mux}