問題1：一個時鐘的上升和下降，用create_clock約束和用set_clock_latency約束有啥區(qū)別？

圖1是兩個時鐘，clkA和clkB，系統(tǒng)要求兩時鐘同頻不同相。clkA比clkB的相位晚20ns。

假設(shè)它們的周期都是100ns。用傳統(tǒng)的create_clock表示兩個時鐘，如下：

如果用clock latency來說明相同的相位關(guān)系，代碼如下：

上述兩種表達(dá)有啥區(qū)別？

第一種表達(dá)，DC工具認(rèn)為：如果clkB在0ns處的上升沿作為launch，則clkA在20ns處的上升沿就可以作為capture。工具不對兩個時鐘做時鐘樹平衡（PR視角），或者認(rèn)為它們在理想情況下本來就是不對齊的（DC視角）。

第二種表達(dá)，DC工具認(rèn)為：盡管clkA比clkB晚20ns，在線路內(nèi)部，clkB會被額外插入20ns，使得clkA和clkB沿對齊。所以，如果clkB在第0ns處的上升沿作為launch，則clkA在20ns處的上升沿不能作為capture，因?yàn)楣ぞ哒J(rèn)為它們是同一個沿。工具會對兩個時鐘做時鐘樹平衡（PR視角），或者單純認(rèn)為兩者就是對齊的（DC視角）。

拓展知識：

如果RTL的時鐘上人為插入了一個delay，請問在DC綜合和STA分析時，這個delay會被考慮進(jìn)去嗎？

答：不會。因?yàn)樵贒C中，時鐘被作為理想線，不進(jìn)行時序分析，當(dāng)然也不計(jì)算這個delay。所以要想讓工具把該delay考慮進(jìn)去，在create_clock時就要特意給它加個delay。但是，有一點(diǎn)。如果是工具自己分析的delay，它會考慮很多因素，比如輸入的trans，輸出的load，但你人為加delay，沒有工具考慮得那么周全，所以并不準(zhǔn)確，只能是湊合這么用，等到PR后再分析。

上述知識，不論是相位差，還是時鐘樹delay，都說明的同樣的問題，即DC階段不搞時鐘樹平衡，也不分析時鐘網(wǎng)絡(luò)延遲，所以你在時鐘上插buffer，STA結(jié)果不顯示效果。但是，DC會認(rèn)為create_clock上對齊的時鐘就是平衡的，即便后面有set_clock_latency，它也認(rèn)為是平衡的。它認(rèn)為，后續(xù)PR階段一定會把它們搞平衡，它先按時鐘平衡來分析。如果create_clock的兩個時鐘不對齊，那就是天然不平衡，DC不會認(rèn)為它們平衡，PR時也不會將它們搞平衡，它會把有延遲的兩個時鐘沿當(dāng)作一個是launch，另一個是capture。

--------------------------------------------------------------------------------------------------------

問題2：一個輸入信號，既當(dāng)普通信號，又當(dāng)時鐘，那它當(dāng)普通信號線時，約束set_input_delay用什么驅(qū)動時鐘？

如果在sdc中將信號A聲明為時鐘，又把它當(dāng)普通信號，那么在片外，即set_input_delay聲明時，可將A本身作為A的驅(qū)動時鐘。

這與我們的習(xí)慣不符，因?yàn)槲覀兞?xí)慣一個信號A的驅(qū)動時鐘是另一個時鐘，所以我們經(jīng)常會聲明一個頻率更快的虛擬時鐘來驅(qū)動A。但是，聲明虛擬時鐘存在一個問題，它分析A的時候，A上升和A下降它都分析，因?yàn)閷τ跀?shù)據(jù)來說，上升和下降都有可能，無法確定。但實(shí)際上，對于一些情況，我們能確定A在某個時刻就是上升的，不需要討論下降的情況，同樣，我們確定某一時刻它就是下降的，不需要討論它上升的情況。

如果用A本身來驅(qū)動A，就是你規(guī)定A時鐘上升它就只分析上升，規(guī)定A時鐘下降它就只分析下降。沒有多余的分析。

而且，這樣做甚至不需要加-clock_fall選項(xiàng)，也能分析A下降的情況。它是自動跟蹤的，A時鐘上升，A信號就上升，A時鐘下降，A信號就下降，不用多幾句-clock_fall是否方便。

代碼如下。代碼中max和min都設(shè)為0，意思是讓A完全跟著設(shè)定的A走，中間沒有延遲。當(dāng)然不會有延遲，因?yàn)锳就是A本身。

--------------------------------------------------------------------------------------------------------

問題3：set_input_delay和set_output_delay里，選項(xiàng)-clock_fall，說的是時鐘下降沿采樣。是指設(shè)計(jì)內(nèi)部的DFF為下降沿采樣，還是指設(shè)計(jì)外部的DFF為下降沿采樣？

答：外部，即假想的在設(shè)計(jì)外面存在DFF情況下，它用什么沿來采。設(shè)計(jì)內(nèi)部的情況不需要你告訴工具，工具自己清楚得很。

--------------------------------------------------------------------------------------------------------

問題4：經(jīng)常在set_input_delay和set_output_delay里見到-max選項(xiàng)，規(guī)定延遲的最大值，那是不是說，延遲的最小值不用規(guī)定了，默認(rèn)是0？

答：不是。如果沒有-min約束，工具不會自動認(rèn)為-min為0，而是認(rèn)為沒有規(guī)定，不報(bào)錯誤。當(dāng)你讓它報(bào)告min的時序時，它說路徑?jīng)]約束。所以max和min都得寫上，不知道寫啥，那-min就寫0，一定要寫上。

--------------------------------------------------------------------------------------------------------

問題5：能否舉個例子，證明set_clock_latency和set_clock_latency -source之間的不同？

答：可以。不加-source，說明是設(shè)計(jì)內(nèi)部的時鐘延遲，在PR之后，這個規(guī)定就沒意義了，要去掉。而加-source時，說明延遲來自設(shè)計(jì)之外，PR工具也不知道延遲是多少，PR時以及PR后，這個-source的數(shù)值在STA當(dāng)中也是有用的。PR工具會根據(jù)-source的值，來決定在時鐘端口上加多少延遲，以便讓時鐘樹能夠平衡。

這里舉個例子，當(dāng)用-source聲明時鐘延遲為19.969ns后，這個時鐘的路徑是先延遲19.969ns，然后經(jīng)過pad，pad又給它延遲了19.956ns。這與我設(shè)置source延遲的初衷不符，我設(shè)這個就是為了虛擬一個pad延遲，但是沒虛擬成功，反倒經(jīng)過了2次延遲。所以，source聲明的值，工具會認(rèn)為完全在設(shè)計(jì)之外，跟設(shè)計(jì)內(nèi)部的延遲無關(guān)。分析時，先把source延遲做完，然后再做內(nèi)部的延遲。

下面，我們將-source選項(xiàng)去掉，結(jié)果如圖4所示。只在pad上進(jìn)行了一次延遲，時間為19.969ns，那么我聲明的clock_latency怎么沒體現(xiàn)呢？本來就不應(yīng)該體現(xiàn)，因?yàn)檫@里我的時鐘是當(dāng)數(shù)據(jù)用的，clock_latency只管時鐘本身，不管數(shù)據(jù)。

總結(jié)：信號A既當(dāng)時鐘，又當(dāng)數(shù)據(jù)，且A來自一個pad。設(shè)置A的clock_latency為x，用來模擬pad的延遲，不加source。pad本身并不是確切的x，我們定為y。則，當(dāng)A作為數(shù)據(jù)分析時，經(jīng)過的pad路徑延遲是y。當(dāng)A作為時鐘分析時，經(jīng)過的pad路徑延遲為x。而如果設(shè)置A的clock_latency為x時加了-source選項(xiàng)，則，當(dāng)A作為數(shù)據(jù)分析時，經(jīng)過的pad路徑延遲為（x+y），這是錯誤的，當(dāng)A作為時鐘分析時，經(jīng)過的pad路徑延遲為x。

--------------------------------------------------------------------------------------------------------

問題6：如何告訴工具一個復(fù)雜的時鐘波形？

答：我們平時看到的都是些簡單地重復(fù)時鐘，一旦時鐘形狀復(fù)雜古怪，就不知道怎么約束了。

其實(shí)，在create_clock里用-waveform選項(xiàng)一直寫下去，就能構(gòu)建一個復(fù)雜時鐘。比如下例，規(guī)定上升沿和下降沿交錯成對出現(xiàn)，以上升沿為始，下降沿為終，即可構(gòu)造出一個復(fù)雜的時鐘。

--------------------------------------------------------------------------------------------------------

問題7：sdc約束是否能按照最終網(wǎng)表中對象的實(shí)際名稱進(jìn)行約束？

答：不行。工具吃sdc的時候，還沒綜合呢，所以它認(rèn)目標(biāo)，比如pins, nets, DFF的名稱，都跟最后網(wǎng)表中呈現(xiàn)的名稱不一定一致。sdc約束時寫的是一個介于RTL和最終網(wǎng)表之間的名稱。

比如，某個信號，在RTL里叫abc，聲明為：reg [3:0] abc。

它的第0位在網(wǎng)表里叫：abc_reg_0_

你在sdc里寫adc_reg_0_，工具就不認(rèn)，你必須寫成abc_reg[0]，工具才認(rèn)。我們說，abc_reg[0]這個名字，是介乎于abc和abc_reg_0_之間的一個名字。

另外，pin腳的名稱在sdc上也不要固定。比如，abc_reg_0_是一個DFF，它綜合后是從QN端輸出信號的。

那么，在sdc中，我們約束一條路徑的起點(diǎn)，用abc_reg[0]/QN行嗎？工具能認(rèn)嗎？

答：工具不認(rèn)。因?yàn)楣ぞ叱詓dc時還不知道它會用哪種DFF，是Q輸出還是QN輸出。所以，我們一般就寫成：abc_reg[0]/*，通配符，讓工具自己找路徑。

--------------------------------------------------------------------------------------------------------

問題8：一些約束，在sdc上寫就能起效，在綜合后寫就無效，還是按照sdc的約束來分析的。

比如，set_multicycle_path，如果是綜合后，你在命令行上補(bǔ)寫，然后再report_timing，結(jié)果不變。很多約束只能在sdc上寫，后來補(bǔ)是沒用的。