流水線設計通常可以在一定程度上提升系統的時鐘頻率，因此常常作為時序性能優化的一種常用技巧。如果某個原本單個時鐘周期完成的邏輯功能塊可以進一步細分為若干個更小的步驟進行處理，而且整個數據處理過程是單向的，即沒有反饋運算或者迭代運算，前一個步驟的輸出是下一個步驟的輸入，那么就可以考慮采用流水線設計的方法來提高工作的時鐘頻率。

如圖3.23所示，典型的流水線設計是將原本一個時鐘周期完成的較大的組合邏輯（上圖）通過合理的分割后由多個時鐘周期分別完成n個較小的組合邏輯（下圖）。原本1個時鐘周期完成的邏輯功能拆分為n個時鐘周期以流水線方式實現，雖然該設計的時鐘頻率會有所提升，但是需要額外付出n-1個時鐘周期的初始延時。

圖3.23 流水線設計的寄存器模型

如圖3.24所示，假設一個流水線設計需要四個步驟完成一個數據處理過程，那么從有數據輸入（in1）的第1個時鐘周期（1clk）開始，直到第4個時鐘周期（4clk）才處理第1個輸入數據；如果輸出時再用寄存器打一拍，通常是第5個時鐘周期才會輸出第1個數據的處理結果；但在以后的每個時鐘周期內都會有處理完成的數據持續輸出。也就是說，流水線設計在提高工作的時鐘頻率的情況下，只在開始處理時需要一定的延時時間（和流水線級數正相關），以后就會不間斷的輸出數據，從而提高處理速度。如果該設計不采用流水線設計，那么該實例處理一個數據就需要4個時鐘周期，而流水線設計則能夠提高最多4倍的處理速度（取決于設計的整體性能水平，通常情況下是提升不了4倍的）。

圖3.24 流水線設計實現

這里我們來看一個除法器IP核進行流水線優化的例子。如圖3.25所示，在Xilinx提供的除法器IP核的配置頁面中，有一個時延選項（Latency Options），這個時延其實就是我們剛剛提到的數據從輸入到輸出，經過內部的流水線處理邏輯，所需要的初始延時時鐘周期數。可想而知，這個延時設置得越大，對應的流水線級數越高，可以達到的時序性能應該是會約好的；但這個延時值如果設置的較小，對應的流水線級數就越低，那么勢必會影響它的時序性能。以筆者的經驗，在一些算法實現中，經常會涉及除法器IP核的使用，雖然流水線級數設置得高一些能夠帶來更好的時序性能，但是往往也會涉及與該除法器計算結果相關的中間結果也需要用寄存器進行較多的延時緩存，有時這也是一筆不小的資源開銷，所以就比較矛盾，因此通常會選擇一個比較折中的時延參數，而不是單純的“越大越好”。

圖3.25 除法器IP的配置頁面

在工程note10_prj002中，使用了Latency=2的一個較小的時延和流水線級數。在編譯后，查看時序結果，如圖3.26，對于50MHz這樣較低頻率下的時鐘（20.0ns時鐘周期），竟然也有3條和除法器（uut_div_gen_1）相關的3條路徑出現了時序違規（Slack為負）。

圖3.26 2級流水線的時序結果

在工程note10_prj003中，當我們嘗試修改Latency=4，將除法器的流水線數增加1倍后再做編譯。如圖3.27，此時已經不存在時序違規路徑了，并且最小的時序余量也高達4.022ns，性能提升明顯。

圖3.27 4級流水線的時序結果

對于流水線設計是否能夠實際的提升設計工程的時鐘頻率，并不能僅從局部的優化去考慮，而需要從整體的設計去考量。在時序性能的優化中，通常是先找到時序的關鍵路徑，即時鐘頻率的瓶頸所在，從關鍵路徑下手進行必要的流水線優化，如此才有可能提升性能。