在開篇前先推薦兩篇文檔，一篇是altera的官方文檔 Appling Multicycle Execptions in the TimeQuest Timing Analyzer ，另一篇是riple兄很早之前推薦過的Multicycles Exception Between Two Synchronous Clock，這兩篇都是關於多周期約束很好的上手文檔，雖然可以快速上手解決當務之急，但事后不免還會有些疑惑。TimeQuest中的多周期約束語法的設置選項有：基於setup(建立時間)的個數，基於hold(保持時間)的個數，start模式和end模式，如下所示。
set_multicycle_path -setup -start from [get_clocks {clk_s}] to [get_clocks {clk_r}] 2
set_multicycle_path -hold -end from [get_clocks {clk_s}] to [get_clocks {clk_r}] 2
但在使用過程中，為什么有時只設置基於建立時間的多周期個數就可以了？而為什么有時建立時間和保持時間的多周期個數都要設置？保持時間設置和建立時間設置存在什么依賴關系？為什么會有start和end兩種模式，分別在什么情況下使用？我們是TimeQuest的用戶，用戶使用產品時只會去關心自己的需求，而用戶成千上萬，需求也千奇百怪，產品設計者為了滿足所有用戶，必須提高產品的通用性，最簡單的方法就是增加選項模式，當一個需求簡單的用戶使用這個通用產品時，面對多重的選擇和模式，往往會無從下手，因為根本就不知道這些選項設置的作用，自然就會產生上述的那些為什么。要解答這些為什么，我們可以試着換位思考，從TimeQuest設計者的角度出發，如何設計多周期約束的語法規則？
明確設計目的
先來看看一個最常見的發送接收波形如圖一所示，A時刻發送的數據B時刻鎖存，launch(發送)邊沿和latch(鎖存)邊沿間隔為一個時鍾周期。
圖一
這種情況下，建立時間和保持時間裕量為
setup slack = (current latch edge - current launch edge ) + Tskew - (Tdelay + Tco + Tsu)
= T + Tskew - (Tdelay + Tco + Tsu)
hold slack = Tdelay + Tco - (Th + previous latch edge - current launch edge)
= Tdelay + Tco - Th
其中Tskew是時鍾偏斜，Tdelay為傳輸延遲，Tco為源寄存器的輸出延遲，Tsu和Th為寄存器需要的建立保持時間。
如果接收波形整體延遲一個時鍾周期，如圖二所示，latch邊沿改變了，A時刻發送的數據C時刻鎖存，B時刻發送的數據D時刻鎖存。
圖二
此時，我們期望的建立時間和保持時間裕量為
setup slack = (current latch edge - current launch edge ) + Tskew - (Tdelay + Tco + Tsu)
= 2*T + Tskew - (Tdelay + Tco + Tsu)
hold slack = Tdelay + Tco - (Th + previout latch edge - current launch edge)
= Tdelay+Tco - (T+Th)
和前一種情況比較，建立時間裕量寬裕了一個周期，保持時間裕量縮緊了一個周期，但TimeQuest並不知道latch邊沿變了，如果不進行多周期約束，仍按照前一種情況的裕量去約束，結果就會使得建立時間多了沒必要的裕量，而保持時間的裕量可能不足。所謂的多周期是相對單周期而言的，launch和latch默認間隔為單周期，當launch和latch間隔為多個周期時，就需要用到多周期約束了，一個完整的時序分析路徑是由Tskew、Tco、Tdelay、Tsu、Th以及launch時刻和latch時刻等共同決定的，后兩項會隨着用戶不同的需求而改變，TimeQuest無法自動獲得，所以多周期約束語法規則設計的目的就是准確的告訴TimeQuest波形何時launch何時latch，進行適當的建立保持約束。
明確TimeQuest的需求
我們已經知道了TimeQuest無法自己獲取launch時刻和latch時刻，必須由用戶提供，那么TimeQuest具體需要哪些信息才能完全了解發送接收波形呢？
舉一個典型的多周期波形，如圖三所示，A時刻發送的數據B時刻鎖存，B時刻發送的數據C時刻鎖存，A為current launch，B即為current latch又是next launch，C是next latch。
圖三
圖三的發送接收關系，我們可以表示為下面幾個式子：
current latch - current launch = 2個時鍾周期
current latch - next launch = 0個時鍾周期
previous latch - current launch = 0個時鍾周期
由於波形的周期性，后兩個表達式是完全等效的，圖二的發送接收關系同樣可以表示為：
current latch - current launch = 2個時鍾周期
current latch - next launch = 1個時鍾周期
previous latch - current launch = 1個時鍾周期
將這幾個表達式推廣到更多不同的例子，會發現只要知道了current launch、current latch、next launch和previous latch就能確定任何形式的發送接收波形，因此TimeQuest只需獲得這四個量，也就清楚波形的真實情況了。
明確用戶的需求
假設用戶的波形如圖二所示，相比常見的圖一單周期波形，建立時間寬裕了一個周期，而保持時間緊縮了一個周期，作為用戶，其實並不關心current launch、current latch、next launch和previous latch這些量，只會關注如何把變化了的建立保持關系告知TimeQuest，讓其在該放松的地方放寬約束，該緊縮的地方加強約束。
整合TimeQuest和用戶的需求
多周期約束的作用是讓TimeQuest明晰發送接收波形的真實狀態，放寬或縮緊建立和保持時間約束，其中TimeQuest期望從用戶那得到current launch、current latch、next launch和previous latch這些量，而用戶希望告訴TimeQuest真實的建立保持關系。要將用戶的訴求准確的轉化為TimeQuest的需求,設計者需在兩者中做出權衡，所以在多周期語法規則的設定上，不能完全偏袒某一方，雙方都要有些取舍。
在語法的選詞上，設計者傾向於用戶，使用了通俗易懂的setup和hold，表示建立時間和保持時間對應的寬松周期個數，比如下面的語句表示建立時間寬松2個周期，保持時間寬松1個周期。
set_multicycle_path -setup -end from [get_clocks {clk_s}] to [get_clocks {clk_r}] 2
set_multicycle_path -hold -end from [get_clocks {clk_s}] to [get_clocks {clk_r}] 1
寬松的周期個數是要相對默認路徑而言的，為了准確的將setup和hold寬松個數准確的轉化為current launch、current latch、next launch和previous latch這些量，設計者制定了傾向於TimeQuest的語法規則，用於默認情況下的current launch，current latch，next launch和next latch的定位。
分析默認的建立時間路徑規則。TimeQuest先以一個launch邊沿為基准定為current launch，再向后尋找距此邊沿最近的一個latch邊沿定為current latch，並將兩者的setup個數定為1個周期。
圖四紅色線條為發送和接收波形無相移時默認的建立時間路徑。
圖四
圖五紅色線條為發送和接收波形存在相移時默認的建立時間路徑，雖然A和B間距不滿一個周期，但TimeQuest為了方便處理，仍將此時的setup定為1個周期。
圖五
由於默認的建立時間路徑setup已被設為1一個周期了，如要寬松1個周期，須在默認的基礎上再疊加1個周期，置setup = 2，current latch才會往后移動一個周期，如上圖藍色線所示，結合默認分析規則和setup的個數，TimeQuest就可以定位current launch和current latch。
分析默認的保持時間路徑規則。保持時間的檢查路徑會有兩條，一條是current launch到previous latch，另一條是next launch到current latch，當current launch和current latch確定后，TimeQuest會基於單周期分析，默認current launch的后一個時鍾為next launch，current latch的前一個時鍾為previous latch，並將兩條保持時間路徑的默認hold個數都設為0，如圖六所示。
圖六
如保持時間寬松1個周期，如圖七所示，previous latch會向前移動一個周期，由於波形的周期性，next launch也會向后移動一個周期。
圖七
結合setup和hold個數以及單周期分析准則，TimeQuest可以知曉previous latch和next launch。由上分析可得，保持時間默認路徑是相對current launch和current latch而定的，和建立時間路徑存在着間隔單周期的依賴關系，會隨着建立時間路徑變化而改變。回到開篇的一個疑問：為什么有時只要基於建立時間設置多周期個數就可以了，因為setup設定后，保持路徑也會相應改變，如果此時剛好滿足用戶需求，就不用再設置hold了。
至此，依據設計者制定的規則，已經可以將用戶提供的setup和hold周期個數轉換為TimeQuest想要的launch和latch信息了，雖然規則不算最直觀，但考慮到要滿足所有用戶的需求，通用性已然成為設計的首要目標(規則越簡單，通用性越強，在分析setup，hold時默認基於單周期的分析法則真的不能再簡單了)，而用戶體驗在FPGA這個壟斷性的行業，苦逼的工程師們真的不要奢望太多。
消除不確定性
上述所舉例子的發送接收波形的頻率都是相同的，如果頻率不同，現有的語法規則就可能出現不確定問題了，如圖八所示。
圖八
仍按照默認的setup路徑分析方法，先找一個launch邊沿為基准，再去確定之后最近的latch邊沿，但會發現存在兩個基准，launch邊沿A和B對應的最近的latch邊沿都是C，launch A到latch C以及launch B到latch C的setup值都為1個周期，此時，TimeQuest無法確定用戶波形到底是哪一種。
為了消除歧義，換另一種分析方法，先找一個latch邊沿為基准，再確定之前最近的launch邊沿，這樣current launch和current latch的關系就一一對應了，如圖九所示。
圖九
兩種方法的區別在於基准的選擇。根據基准的不同，設計者創造了兩種模式start和end，start模式參考的基准是latch邊沿，end模式參考的是launch邊沿，對於同頻波形，不存在不確定性，無所謂使用哪種模式，當發送頻率比接收頻率快一倍以上時需用start模式，同理，當接收頻率比發送波形快一倍以上時使用end模式。
綜上，經過一個產品設計的大致思考流程(明確產品目標---> 整合用戶需求 -----> 准確表達需求)后，我對TimeQuest多周期約束有了更深的認識，不僅知其然，而且知其所以然。其中基於單周期的分析規則對我也有些啟發，規則如此簡單，但的確能滿足要求，當時在分析默認的保持時間路徑時，我自己也嘗試着想了些規則，但都是從方便用戶的角度出發，忽視了TimeQuest的需求，不僅復雜，通用性還不好，可見對需求挖掘的深淺直接影響着產品的復雜度。
從用戶角度出發，追求用戶體驗，這些道理經常被耳提面令，但工欲善其事，必先利其器，在開發過程遇到的一些開發工具的問題，我們可以嘗試下換位思考，從設計者的角度出發，往往除了能解決開發工具的疑惑，還能收獲一些其他設計者好的思路並應用到自己的設計中。
最后再無力的吐槽一句：一邊使用着用戶體驗極差的開發工具，一邊卻想着開發用戶體驗極佳的產品，真的有點為難工程師們了。(TimeQuest，我不是在說你，你已經很不錯了)