做FPGA開發(fā)的同學(xué)，十有八九都被時(shí)序約束折磨過(guò)。代碼寫得好好的，仿真也沒(méi)問(wèn)題，一跑綜合實(shí)現(xiàn)就報(bào)一堆setup/hold violation，改來(lái)改去就是收斂不了。按我的經(jīng)驗(yàn)，這時(shí)候與其繼續(xù)盲目調(diào)參數(shù)，不如靜下心來(lái)檢查一下自己的約束是不是從根子上就寫錯(cuò)了。

今天咱們就聊聊那些導(dǎo)致時(shí)序約束不收斂的常見(jiàn)問(wèn)題，手把手幫你排坑。

時(shí)鐘路徑分析示意

時(shí)鐘約束：你真的定義對(duì)了嗎

說(shuō)起來(lái)，時(shí)鐘約束應(yīng)該是最基礎(chǔ)的東西，但偏偏出問(wèn)題最多的也是這里。很多人習(xí)慣性地只約束主時(shí)鐘，忽略了衍生時(shí)鐘。什么叫衍生時(shí)鐘？比如你用MMCM/PLL輸出的時(shí)鐘、用BUFG/BUFR處理的時(shí)鐘，這些都是由主時(shí)鐘派生出來(lái)的。Vivado不會(huì)自動(dòng)幫你識(shí)別它們，必須顯式聲明。

有個(gè)坑特別容易踩：定義了MMCM輸出時(shí)鐘，但忘了把它的輸入輸出關(guān)系通過(guò)generated_clock關(guān)聯(lián)起來(lái)。這樣時(shí)序引擎就不知道這兩個(gè)時(shí)鐘之間的相位關(guān)系，分析的時(shí)候自然會(huì)出錯(cuò)。

還有個(gè)更隱蔽的問(wèn)題——時(shí)鐘的抖動(dòng)(Jitter)和不確定性(Uncertainty)。默認(rèn)值往往偏樂(lè)觀，你要是直接用，沒(méi)準(zhǔn)在更嚴(yán)苛的條件下就崩了。建議大家在約束文件里顯式設(shè)置合理的抖動(dòng)值，別完全依賴工具的默認(rèn)值。

FPGA IO時(shí)序分析

IO約束：別忘了外部世界的存在

很多新手只關(guān)注內(nèi)部時(shí)序，對(duì)IO約束不上心。問(wèn)題是，你的芯片不是孤立存在的，它要和外面的器件通信。外部器件的時(shí)序特性你得考慮進(jìn)去。

set_input_delay和set_output_delay這兩個(gè)約束，參數(shù)選擇特別講究。你得知道上游器件的時(shí)鐘周期、輸出數(shù)據(jù)Valid窗口，下游器件的Setup/Hold要求。很多時(shí)候報(bào)timing violation，不是內(nèi)部邏輯太慢，而是IO約束設(shè)得太寬松或者太嚴(yán)格。

有個(gè)小技巧分享給大家：不確定外部器件參數(shù)的時(shí)候，可以先按50%時(shí)鐘周期來(lái)估算，然后根據(jù)實(shí)際測(cè)試結(jié)果微調(diào)。比一上來(lái)就隨便寫個(gè)數(shù)字強(qiáng)多了。

時(shí)鐘域交叉(CDC)路徑分析

跨時(shí)鐘域：最容易出問(wèn)題的邊界地帶

跨時(shí)鐘域問(wèn)題堪稱FPGA設(shè)計(jì)的"癌癥"，處理不好輕則時(shí)序不收斂，重則功能異常。常見(jiàn)的問(wèn)題是對(duì)CDC路徑要么完全不約束，要么約束得一塌糊涂。

完全不約束的情況比較少見(jiàn)，畢竟綜合工具會(huì)報(bào)警告。但約束不當(dāng)就很普遍了。最典型的錯(cuò)誤是用set_false_path一刀切，把所有跨時(shí)鐘域路徑都設(shè)成false path。問(wèn)題是，不是所有CDC路徑都能安全地用false path，有些關(guān)鍵路徑必須保證正確的時(shí)序關(guān)系。

正確做法是分門別類處理：慢時(shí)鐘到快時(shí)鐘的采樣路徑可以用set_false_path或set_max_delay；快時(shí)鐘到慢時(shí)鐘的握手路徑往往需要set_false_path加額外的時(shí)序裕量；而異步復(fù)位這類路徑，set_false_path才是正解。

有意思的是，很多人知道CDC同步器的重要性，但在約束層面卻忽略了對(duì)同步器本身打拍級(jí)數(shù)的考慮。同步器鏈本身的路徑也是有時(shí)序要求的，別漏掉了。

時(shí)序約束綜合分析

時(shí)序例外：用錯(cuò)了比不用更糟糕

set_max_delay、set_multicycle_path這些時(shí)序例外約束，用好了能救命，用錯(cuò)了就是埋雷。我見(jiàn)過(guò)最離譜的案例是，有人為了"提高"時(shí)序收斂，把整個(gè)設(shè)計(jì)的所有路徑都設(shè)了很寬松的max_delay。結(jié)果呢？工具在優(yōu)化的時(shí)候完全失去了方向，性能反而更差了。

時(shí)序例外約束有幾條黃金法則：第一，約束范圍盡量精準(zhǔn)，用最具體的路徑表達(dá)式，別動(dòng)不動(dòng)就-through * -to *；第二，多周期路徑要確認(rèn)清楚是setup還是hold語(yǔ)境下的多周期；第三，用完記得清理，別讓過(guò)期的約束繼續(xù)生效。

還有個(gè)容易忽略的地方：set_case_analysis這個(gè)約束。它用來(lái)固定某些信號(hào)的值，但很多人設(shè)完之后忘了這個(gè)約束會(huì)影響整條路徑的時(shí)序分析，有時(shí)候時(shí)序不收斂的根源就在這里。

復(fù)位設(shè)計(jì)：被忽視的隱形成本

復(fù)位信號(hào)看起來(lái)不起眼，但它對(duì)時(shí)序的影響可能是致命的。全局異步復(fù)位會(huì)讓工具在布局布線的時(shí)候很為難，因?yàn)閺?fù)位信號(hào)要連到設(shè)計(jì)里的每一個(gè)寄存器，負(fù)載極大。

我建議能不用復(fù)位就不用復(fù)位，Xilinx 7系列以后的器件，上電初始值都是確定的，很多場(chǎng)景完全可以用初始化代替復(fù)位。如果非要用復(fù)位，優(yōu)先選擇高扇出的同步復(fù)位，并且通過(guò)set_property ASYNC_REG標(biāo)記CDC路徑上的寄存器。

關(guān)于復(fù)位的時(shí)序約束，有個(gè)細(xì)節(jié)很多人不知道：set_false_path -from [get_async_pins]這種寫法已經(jīng)過(guò)時(shí)了，正確做法是通過(guò)綜合屬性來(lái)控制。

總結(jié)：約束是個(gè)系統(tǒng)工程

按我的經(jīng)驗(yàn)，時(shí)序約束不收斂，80%的問(wèn)題出在約束本身，20%才需要調(diào)綜合實(shí)現(xiàn)策略。與其一味地加pipeline、加buffer，不如先把自己的約束文件過(guò)一遍。

幾個(gè)自查清單送給大家：時(shí)鐘定義是否完整？IO約束參數(shù)是否有依據(jù)？CDC路徑是否分類處理？時(shí)序例外是否精準(zhǔn)且不過(guò)期？復(fù)位策略是否合理？

時(shí)序約束這東西，入門容易精通難。但只要理解了工具的分析邏輯，約束寫對(duì)做好收斂，其實(shí)也沒(méi)那么玄乎。希望今天的分享對(duì)大家有幫助，有問(wèn)題歡迎留言交流。