判斷式深度與時脈

FPGA設計中常會用到if... else 或是 case 判斷式，當設計愈趨複雜時，判斷式的深度會不斷地增加，常發生好不容易完成了複雜的判斷式內容，通過行為層驗證後出現timing上的錯誤，這些錯誤肇因於過於龐大的組合邏輯，最直覺的解法便是在組合邏輯中插入FF，增加latency以換取timing上的改善。


下方程式以Spartan3為例，其硬體架構為4-input LUT，所以當判斷式在4bit(din)以下輸入只需透過一級的LUT即可完成，以此為基準，合成出的最大頻率約在450MHz(BASELINE)，當額外的sel訊號加入判斷式後，可以發現合成後結果須用到兩級LUT串接(LUT4 -> LUT3)，最大頻率也下降到330MHz左右(LATENCY_1_CLK)。

若我們希望最大頻率能提高，最直接的方式便是在兩級LUT中增加一級FF，縮短各級FF間組合邏輯的數量，代價就是dout會延遲1 clock後出來，還有額外的FF數量。

改善後的結果(LANTANCY_2_CLK)，最大時脈可以提升到415MHz，另外要注意除了dout需要插入FF(dout_buf)外，判斷用的sel也同樣需要插入FF以維持結果的正確性。

觀看修改過後的程式可以發現，我們成功地將判斷式的深度減少了一層，也提醒我們在撰寫判斷式時，若發現深度不斷增加，便要考慮使用前述方式拆解判斷式，不然好不容易寫出的程式碼卡在timing不過，會讓人血吐滿地的......

雖說判斷式深度會影響timing，但影響的程度與目標平台有很大的關連，上述是以採用LUT4架構的Spartan3為例，若同樣的程式碼移植到LUT5架構的Spartan6或是LUT6架構的Kintex7上，就可以承受更多input的判斷式。

由此可知，其實主要影響timing的因素不在程式碼上的深度有多少，而在於每個判斷式中條件的位元寬度與平台架構LUT大小差異。

同樣的狀況常發生在加法器上(Carry chain)，雖然現在的slice設計都有加入Carry chain的線路，但在特殊情況下使用adder tree做大數加法也是很常見的做法。