時(shí)序約束中一種特殊的情景分析

1問題

在做模塊級(jí)約束的時(shí)候，外部的真實(shí)IO delay是還不知道的。為了讓模塊綜合結(jié)果盡可能滿足外部苛刻的條件，經(jīng)驗(yàn)值是將IO delay設(shè)置為相關(guān)聯(lián)的驅(qū)動(dòng)時(shí)鐘周期的60%，給模塊內(nèi)部的路徑留下40%的時(shí)鐘周期，這適用于

1.INPUT->REG路徑

2.REG->OUTPUT路徑

而對(duì)于INPUT->OUTPUT的路徑（feedthrough），如果按照這樣的設(shè)置，因?yàn)?a target="_blank">端口輸入和輸出延時(shí)已經(jīng)占了60%+60%=120%的時(shí)鐘周期，超過一個(gè)周期，這是不可能實(shí)現(xiàn)的約束，一般會(huì)把IO delay調(diào)節(jié)成IO 相關(guān)聯(lián)的驅(qū)動(dòng)時(shí)鐘周期的40%，給模塊內(nèi)部的路徑留下20%的時(shí)鐘周期

但是對(duì)于下面這樣一種電路，情況有些特殊，這也是實(shí)際設(shè)計(jì)中經(jīng)常出現(xiàn)的電路：

注意到這個(gè)電路的不同之處在于，INPUT不僅連接了INPUT->REG的路徑，同時(shí)另一分支連接到OUTPUT。而OUTPUT也同時(shí)被COMBO-A和REG->OUTPUT的邏輯所驅(qū)動(dòng)。對(duì)于這樣的結(jié)構(gòu)，

1.對(duì)于INPUT->REG，和REG->OUTPUT，總是希望IO delay是60%的時(shí)鐘周期的

2.INPUT->OUTPUT的feedthrough約束為20%的時(shí)鐘周期。

要怎樣才能同時(shí)滿足這兩個(gè)需求呢？

2結(jié)論與解決方案

1. 在做模塊級(jí)綜合的時(shí)候，對(duì)于IO路徑一般會(huì)使用60%的端口時(shí)鐘進(jìn)行約束，如果這樣的路徑涉及到feedthrough path，也就是INPUT->REG的路徑同時(shí)有分支到INPUT->OUTPUT的路徑，并且該OUTPUT同時(shí)被這段feedthroughlogic以及REG驅(qū)動(dòng)，全部按照端口60%驅(qū)動(dòng)時(shí)鐘的IO約束會(huì)造成無法優(yōu)化的路徑，也就是infeasible path

2. 對(duì)于infeasible path，dc不會(huì)做任何優(yōu)化，如果不解決這樣的問題，綜合結(jié)果不是最優(yōu)解

3. set_max_delay=input delay（60%CLK_V)+comb delay+output delay(60%CLK_V)可以解決這個(gè)問題，但當(dāng)端口情況復(fù)雜的時(shí)候約束數(shù)量會(huì)很多，并且約束本身不便于理解

4.在同一個(gè)端口既定義了專門使用于INPUT->REG和REG->OUTPUT的CLK_V，同時(shí)定義了專門使用于INPUT->OUTPUT的CLK_V_FEED，并設(shè)置相應(yīng)的CLOCK GROUP或者false_path可以最好地滿足這個(gè)需求。

3測試與實(shí)驗(yàn)

以下面RTL為例：

這樣一個(gè)電路經(jīng)過翻譯之后（綜合優(yōu)化之前）大概是以下的電路，INPUT->OUTPUT的路徑組合邏輯部分是兩個(gè)乘法器，而INPUT->REG的組合邏輯部分是兩個(gè)加法器（這里不過多關(guān)注具體的功能）：

假設(shè)：

1.周期設(shè)為2ns，500MHz的頻率

2.整個(gè)設(shè)計(jì)只有一個(gè)時(shí)鐘

3.每條路徑都是單周期路徑

4.IO的相關(guān)寄存器都存在于block之外，需要設(shè)置Virtual clock

5. INPUT端口（除去CLOCK）驅(qū)動(dòng)為一個(gè)X1的buffer，OUTPUT端口的負(fù)載均為3個(gè)X1的buffer

如果我們按照傳統(tǒng)的約束方法，將IOdelay設(shè)置為60%的時(shí)鐘周期：

經(jīng)過DC綜合之后，可以看到電路被優(yōu)化成了以下結(jié)構(gòu)，藍(lán)圈部分是input port->reg的路徑，以寄存器為終點(diǎn)。紅圈部分是我們要重點(diǎn)關(guān)注的input port->output port的路徑，也就是feedthrough path：

我們使用report_timing看一下結(jié)果。

可以看到input port->reg（藍(lán)）的路徑主要是兩個(gè)加法器，重點(diǎn)關(guān)注input delay的設(shè)置，成功地被設(shè)置成60%的時(shí)鐘周期（2*0.6=1.2），這是符合預(yù)期的。并且這條路徑滿足時(shí)序要求:

然后我們?cè)倏聪耰nput port->output port的路徑（紅）。這塊主要是兩級(jí)乘法器的邏輯。因?yàn)檫@塊邏輯包含了不止一條的路徑，report_timing默認(rèn)情況下選擇最差的一條（in_3[0]->out_comb[1]）：

可以看到這條路徑被映射成了AND2X1->AND3X1->INVX1->AND3X1->XOR2X1，單就這一段組合邏輯的延時(shí)（算上端口上的延時(shí)）是0.59。因?yàn)閕nput delay和output delay已經(jīng)超過了一個(gè)時(shí)鐘周期（6+6=12>10），所以無論這段邏輯如何優(yōu)化，都會(huì)是違例路徑。

另外我們注意到在使用report_timing的時(shí)候，DC顯示了如下warning：

這里infeasible的意思為“不可實(shí)行的”，查看該warning的詳細(xì)信息：

這段描述的重點(diǎn)在紅線部分。Infeasible path指的是那些無論如何都不可能滿足約束的路徑，也就是我們這個(gè)例子中Input port->output port的這條路徑。如果不加以處理，綜合器對(duì)這種路徑是不會(huì)做任何優(yōu)化的，會(huì)影響到最后的QoR。

按照manpage中的WHAT NEXT的方法，使用report_timing -attribute可以看到這段路徑是infeasible的：

既然問題是由于約束過緊導(dǎo)致，那么只要相應(yīng)的放寬對(duì)這條路徑的約束就可以了。之所以這個(gè)例子比較復(fù)雜，是因?yàn)槲覀內(nèi)绻蛔鎏厥庠O(shè)置的話，無法兼顧到同時(shí)滿足

1.對(duì)于INPUT->REG，和REG->OUTPUT，總是希望IO delay是60%的時(shí)鐘周期的

2.INPUT->OUTPUT的feedthrough約束為20%的時(shí)鐘周期。

為了解決這個(gè)問題，我們必須對(duì)此類路徑做特殊設(shè)置。

方法1：

在約束中有一類特殊的約束叫exception，就是為了特殊情況而存在的。

可以使用set_max_delay的方法來對(duì)這樣的路徑進(jìn)行單獨(dú)約束，因?yàn)閟et_max_delay是一種exception，它可以覆蓋原有的約束。舉個(gè)例子，如果這條feedthrough path你所期望的延時(shí)是DELAY_COMB，并且端口的IO delay還是想保持原先的60%的時(shí)鐘周期，那么可以通過設(shè)置max_delay=DELAY_COMB+0.6*P_VCLK*2。

這里可以看到這段INPUT->OUTPUT的max_delay被設(shè)置成了1.2倍的時(shí)鐘周期外加一段延時(shí)的時(shí)間，這在現(xiàn)實(shí)中是不可能存在的路徑。但這么設(shè)置并不意味著這條路徑從外部起始寄存器->INPUT->COMB->OUTPUT->外部終點(diǎn)寄存器真的有超過一個(gè)時(shí)鐘周期那么長（假設(shè)整個(gè)設(shè)計(jì)只存在一個(gè)時(shí)鐘）。這樣設(shè)置只是因?yàn)閟et_max_delay這個(gè)約束在進(jìn)行分析的時(shí)候會(huì)天然考慮到input delay和output delay，而在這個(gè)方法中，并沒有對(duì)端口的input delay和output delay進(jìn)行改動(dòng)，他們還是60%的時(shí)鐘周期。這個(gè)約束的關(guān)鍵在于給予了中間這段從INPUT->OUTPUT的路徑一段額外的DELAY_COMB的時(shí)間，而這個(gè)值是可以自己確定的。假設(shè)留給這段邏輯20%的時(shí)鐘周期，也就是0.2*2=0.4，在約束中加入以下設(shè)置：

綜合之后的report_timing -from in_3[0] -to out_comb[1] -attribute結(jié)果：

根據(jù)這個(gè)新的結(jié)果，我們可以看到

1.之前的約束違例問這條路徑不再是infeasible path

2.之前這條路徑是AND2X1->AND3X1->INVX1->AND3X1->XOR2X1，總的延時(shí)是0.59。DC沒有做任何的優(yōu)化。而在增加了max delay的約束之后，DC重新將這段路徑優(yōu)化成了NAND2X0->OR2X2->NBUFFX2->NAND2X0->XOR2X2，總的延時(shí)是0.5，以此來滿足20%的時(shí)鐘周期也就是0.4的約束。 雖然仍然有違例，但比起之前infeasible path沒有得到優(yōu)化，這段路徑的在優(yōu)化后延時(shí)減小了。

方法2

方法1使用set_max_delay來給這段INPUT->OUTPUT路徑設(shè)置20%的時(shí)鐘周期，對(duì)于一組的INPUT->OUTPUT，約束只需要加三行。

但實(shí)際上在綜合之前，是不知道哪些INPUT->OUTPUT會(huì)存在這樣的feedthrough的情況，因而為了保證結(jié)果，對(duì)于所有這樣的路徑都要進(jìn)行max delay的設(shè)置來防止infeasible path的出現(xiàn)。實(shí)際的設(shè)計(jì)中端口不全是由是一樣的外部時(shí)鐘驅(qū)動(dòng)，對(duì)于不同外部時(shí)鐘驅(qū)動(dòng)的端口，都要分別進(jìn)行max delay的約束。假設(shè)這樣的INPUT->OUTPUT組數(shù)特別多，方法1實(shí)際上是很繁瑣的。比如如果有3個(gè)輸入都是不同時(shí)鐘驅(qū)動(dòng)的，3個(gè)輸出也都是不同時(shí)鐘驅(qū)動(dòng)的，那么一共有3*3=9組max_delay需要設(shè)置。

并且使用max delay的設(shè)置，從直觀上并不利于理解。因?yàn)閙ax delay設(shè)置的值實(shí)際上超過了一個(gè)時(shí)鐘周期。

那么是否可以對(duì)feedthrough的IO端口額外做如下設(shè)置？

通過使用set_input_delay -add，在IO端口額外加上一個(gè)40%VCLK的時(shí)鐘。這樣對(duì)于上述場景（3個(gè)輸入都是不同時(shí)鐘驅(qū)動(dòng)的，3個(gè)輸出也都是不同時(shí)鐘驅(qū)動(dòng)），只需要6條設(shè)置input delay和output delay的命令，不需要對(duì)于每一組可能情況都去進(jìn)行設(shè)置。

并且這樣對(duì)于INPUT->REG的路徑，還是會(huì)使用60%VCLK的約束，滿足需求。但是對(duì)于feedthrough path，因?yàn)镮O同時(shí)存在40%VCLK和60%VCLK的約束，他們都是基于同一個(gè)時(shí)鐘VCLK，實(shí)際上還是會(huì)使用更緊的60%VCLK-60%VCLK的約束，而忽略了40%VCLK的約束，問題還是沒有得到解決。使用report_timing -from in_3[0] -to out_comb[1] -attribute觀察路徑：

為了將feedthrough的路徑和INPUT->REG/REG->OUTPUT的路徑區(qū)分開來，需要在端口專門設(shè)置虛擬時(shí)鐘CLK_V_FEED來進(jìn)行約束：

重新綜合，使用report_timing -from in_3[0] -to out_comb[1] -attribute觀察路徑：

可以看到這個(gè)infeasible的約束依然存在。

不同的地方在于，此時(shí)我們通過命令report_timing-from [get_clocks CLK_V_FEED] -to [get_clocks CLK_V_FEED] 觀察同樣的路徑，可以看到相新設(shè)置的CLK_V_FEED已經(jīng)設(shè)置到端口上了：

如果能有一個(gè)辦法來取消CLK_V到CLK_V的約束就好了。

在exception中，false path可以實(shí)現(xiàn)類似功能，在這里可以使用false path設(shè)置：

重新綜合，使用report_timing -from in_3[0] -to out_comb[1] -attribute觀察綜合后路徑：

可以看到這個(gè)時(shí)候這條路徑的結(jié)果已經(jīng)好于加false_path之前的結(jié)果。這是因?yàn)槿绻麤]有設(shè)置false_path，更緊的feedthrough約束60%CLK_V->60%CLK_V會(huì)占主導(dǎo)作用，DC發(fā)現(xiàn)有infeasible的約束時(shí)便不做任何優(yōu)化，即便合理的約束也同時(shí)存在。而false path可以解決這個(gè)問題。

但使用false path與之前set_max_delay類似，因?yàn)楸仨毷敲拷Mclock一一對(duì)應(yīng)，當(dāng)端口clock數(shù)量繁多的時(shí)候，會(huì)有設(shè)置繁瑣的問題。

與false path相類似功能的，有另外一個(gè)命令是set_clock_groups，實(shí)現(xiàn)起來比較簡單。被設(shè)置到同一個(gè)group的時(shí)鐘之間存在約束，而被設(shè)置到不同group的時(shí)鐘之間不存在約束。如果通過set_clock_groups將驅(qū)動(dòng)INPUT的CLK_V時(shí)鐘和OUTPUT驅(qū)動(dòng)的寄存器CLK_V時(shí)鐘分到不同的clock group，那么這個(gè)問題就能得到解決。

但由于這里驅(qū)動(dòng)INPUT的CLK_V和OUTPUT驅(qū)動(dòng)的寄存器的CLK_V是同一個(gè)時(shí)鐘，一個(gè)時(shí)鐘沒法被分到不同的group，必須將CLK_V分為CLK_V_I和CLK_V_O：

設(shè)置CLK_V_I和CLK_V_O到不同的clock group，可以取消CLK_V_I和CLK_V_O之間的約束，但在這一步之前，需要先確定好CLK_V_I/CLK_V_O和CLK以及CLK_V_FEED之間的關(guān)系。CLK_V_I/CLK_V_O與CLK之間的約束是需要的，這是INPUT->REG和REG->OUTPUT的關(guān)系，要把他們歸到一個(gè)group。而CLK_V_I/CLK_V_O與CLK_V_FEED之間的關(guān)系是不需要的，因?yàn)檫@里只需要40%CLK_V_FEED->40%CLK_V_FEED的feedthrough約束，而不需要類似60%CLK_V_I->40%CLK_V_FEED這樣的關(guān)系。

可以通過以下設(shè)置，其中第二個(gè)set_clock_group用于取消第一個(gè)set_clock_group里的CLK_V_I和CLK_V_O之間的關(guān)系：

這樣一來，CLK_V_I和CLK_V_O之間就不會(huì)存在約束。再次綜合，使用report_timing -from [get_clocks CLK_V_I] -to [get_clocks CLK_V_O]：

可以看到原先存在的60%CLK_V-60%CLK_V路徑因?yàn)閏lock group的原因已經(jīng)不存在了。

使用report_clock -groups來觀察當(dāng)前的clock group和false path情況，符合預(yù)期：

最后使用report_timing -from in_3[0] -to out_comb[1] -attribute觀察綜合后路徑：

1. 使用virtual clock的約束和之前使用set_max_delay的約束實(shí)現(xiàn)了同樣的目標(biāo)，給feedthrough path留下了2-0.8-0.8=0.4的時(shí)間，達(dá)到了目的。（注意到這和set_max_delay的綜合結(jié)果并不一致，但路徑都得到了優(yōu)化）。

2.相比于set_max_delay，使用virtual clock約束更便于理解，當(dāng)端口時(shí)鐘情況復(fù)雜的時(shí)候設(shè)置起來更加便利。

3.false path 和 set_clock_group都能實(shí)現(xiàn)需求，但當(dāng)外部clock數(shù)目很多的時(shí)候使用set_clock_group來定義clock之間的關(guān)系比set_false_path更為簡潔明朗

4. false path只針對(duì)STA，set_clock_group可以選擇logically exclusive, phisically exclusive。在后端做信號(hào)完整性分析的時(shí)候有區(qū)別。使用set_clock_group會(huì)更合理一些。

4補(bǔ)充

最后完整的sdc如下：

這里提供了兩種參考方法，但具體到實(shí)際項(xiàng)目中，不同的設(shè)計(jì)不同的情況不同的公司有不同的應(yīng)對(duì)，大家在實(shí)際設(shè)計(jì)中都是如何處理這種情況的呢？歡迎留言討論。如果文章中有任何錯(cuò)誤，也請(qǐng)留言指出，大家一起學(xué)習(xí)進(jìn)步~