【轉】時序優化實例 優化實例

優化實例

 【轉載文章用於學習 http://www.cnblogs.com/lianjiehere/p/3787654.html】

  這個實例咱們來看看如何對設計進行時序優化，假設設計的頂層框圖如圖1所示， 該設計在兩個系統之間實現了一個POS-PHY第三層鏈路。

 

 

 

圖1：POS-PHY頂層設計框圖

         如圖所示在POS-PHY第三層接收器模塊收到包以後，包檢測模塊分析一個包裏的數據，以確保數據是正確的，好比確保包的長度是1K字，ERR標誌沒有被置位。接着包將會送到FFT以及一系列FIFO，外部的FIFO是爲了增長系統存儲能力。最後，數據包由POS-PHY第三層發送器模塊發送到其它器件。

 

         該設計總共有三個時鐘域，一個是外部100MHz時鐘域，一個是200MHz內部時鐘域，最後一個是讀寫外部FIFO的133MHz時鐘域。

 

        下面咱們利用這個設計來具體實踐怎麼發現設計中的時序問題，以及如何來解決這些時序問題。假設設計已經完成，咱們下面按步驟一步一步來介紹。

 

         因爲事先咱們已經將工程創建好了，咱們直接對工程進行編譯，而後在編譯報告裏找到TimeQuest時序報告，如圖2所示，SCLK時鐘域存在時序違規。

 

圖2：工程編譯後查看時序報告

         爲了查看SCLK詳細時序違約狀況，能夠經過鼠標右擊圖2中第一行，從彈出的菜單裏選擇「Report Timing…」，如圖3所示。

圖3：經過報告時序命令查看時序分析細節

         選擇圖3所示的命令後，在彈出的命令對話框中輸入一下信息，而後點擊「Report Timing」，如圖4所示。

圖4：報告SCLK時序

         能夠看到報告顯示很是多的紅色時序違規，不少時候面對這類時序問題，設計者每每會手足無措，由於不知道從哪裏下手來解決這些問題。你們能夠按照一些提示來進行分析：

 

l  找到From和To下節點，分析其類型。能夠結合兩個節點來分析，經常能夠幫助咱們理解到底哪裏出了問題。好比，這兩個節點是位於兩個模塊之間的接口仍是位於一堆組合邏輯之中呢。有時候，我只需解決少許有時序問題路徑，就能夠同時解決一堆其它路徑的時序問題。

l  找到From和To節點中你認識的節點。經過這些節點，你能夠知道那些源代碼或邏輯結構出現了問題。這樣比較容易理解出問題的邏輯是什麼以及如何來解決時序問題。

l  前面提到，當你解決某個路徑的時序問題的時候，可能會不經意間解決了其它路徑上的時序問題。由於編譯器老是試圖對全部路徑進行優化，假如能經過修改代碼或約束來解決某個路徑的問題，那麼就有利於釋放編譯器將更多精力放在其它有時序問題的路徑上。

 

回到最初的時序報告，根據上述提示，無論有多少時序失敗的紅色路徑，我首先來分析前面幾行時序問題，最前面幾行是時序最差的路徑，如圖5所示。

圖5：時序最差幾條路徑

         咱們看到前面7條內容差很少，那麼咱們來分析第一條，鼠標右擊第一行任何地方，選擇「Report Worst-Case Path」來觀察和分析這條路徑。在Statistic頁面查看這條路徑的上數據到達路徑上的邏輯層級，固然也能夠在Data Path頁面下經過該路徑上CELL和IC的計數也能得知該路徑上的邏輯層級，如圖6所示，結果是17級。

圖6：查看數據到達路徑上邏輯層級

         鼠標右擊圖6中到達路徑任何單元，選擇「Locate Path」，而後在彈出的對話框裏選擇「Technology Map Viewer」，單擊OK。那麼我會看到如圖7所示的邏輯結構。

 

圖7：寄存器之間邏輯層級過多

         如圖7所示在寄存器last_data和parity_error之間總共有17級邏輯，很好地代表了這個時序應該是由過多邏輯層級形成。

 

         回到TimeQuest，咱們再次使用「Locate Path」命令，此次選擇使用Chip Planner來查看路徑。在Chip Planner底部的Locate History窗口裏雙擊定位的路徑，根據須要可使用放大鏡調整放大倍數，咱們能夠看到這條路徑佈局佈線結果如圖8所示。

 

圖8：佈局佈線結果

         圖8中連線的延時信息，須要從View菜單裏執行「Show Delays」來使能已經高亮的路徑。能夠看到該路徑上全部節點只分布在相鄰的兩個LAB中，並且LAB之間僅有少數幾根連線，這代表這是一個很好的佈局，再次證實該路徑時序問題是由邏輯層級過多形成。

 

         爲了解決這個路徑上的時序問題，能夠 插入流水寄存器的方法。若是代碼是你本人寫的，那麼這個方法是一個可行的辦法。由於你會知道，發生這種奇偶校驗錯誤時，並必定須要當即獲得處理，幾個時鐘週期的滯後對於設計來講仍是能夠容忍的。因此咱們能夠經過修改代碼來對該路徑進行優化。

 

         插入流水以前，奇偶校驗是這樣實現的：

assign parity0  = last_data[ 0] ^ last_data[ 1];

插入流水後，將parity賦值語句放在進程裏面並使用阻塞賦值，以下所示：

parity0  <= last_data[ 0] ^ last_data[ 1] ^ last_data[ 2];

經過以上修改並從新編譯設計，那麼奇偶校驗寄存器如今都知足了時序要求。如圖9所示，剩下時序問題負的slack小於1了。

圖9：剩下的有時序問題路徑

         從圖9能夠看出，時序問題仍然是SCLK時鐘域，能夠再次使用報告時序來對其進行分析。從報告窗口裏繼續使用「Report Worst-Case Path」命令來查看第一條出現時序問題的路徑sop_error的更多細節。

 

圖10：出現時序問題路徑細節

         如圖10所示，不少出錯路徑的To節點都是sop_error（即包錯誤標誌開始）信號，這些路徑都是從接收模塊的FIFO地址寄存器到此標誌信號。這就意味着，咱們能夠一次性解決全部這些問題。

 

         根據前面的經驗，我首先來查看這條路徑的邏輯層級，使用相同的方法，可是此次咱們發現路徑上邏輯層級不多，因此也許問題不是由於層級太多，可是爲了驗證咱們的猜想，可使用圖形觀察工具進行確認。使用「Locate Path」到「Technology Map Viewer」中進行觀察，如圖11所示。

 

圖11：觀察路徑邏輯層級

         從圖11能夠看到，不像以前那條路徑，這條路徑上只有一個RAM塊和3級邏輯，因此證實這個時序問題不是由於路徑上有過多的邏輯層級。可是能夠看到RAM的輸出路徑是組合邏輯，這意味着總體寄存器到寄存器延時就包括RAM塊以及三級組合邏輯單元的延時。這是不是形成時序違規的緣由呢？

 

         咱們返回到TimeQuest中觀察路徑詳細信息的slack報告界面，在Data Arrival Path片斷，咱們重點看第六行（時鐘路徑和數據路徑已經展開，行號應該是2，由於數據路徑展開在時鐘路徑以後）。如圖12所示。

圖12：詳細觀察數據到達路徑

         咱們須要圖12中，注意「Type」列爲CELL延時，這行顯示通過器件的cell給該路徑增長的延時。「Location」和「Element」顯示的是該CELL其實是一個M9K存儲塊，那麼通過這個存儲塊增長了多少延時呢，能夠在「Incr」列看到。所以，儘管這條路徑上只有少數幾級邏輯，可是此路徑上的時序問題仍是屬於邏輯層級過多形成的時序失敗，由於路徑通過的存儲塊帶來過多的延時。那麼咱們應該如何來解決這種問題呢？經過使用M9K塊輸出寄存器來手動插入流水彷佛是不可能的，由於該RAM是POS-PHY函數的一部分。經過多週期路徑約束應該能夠解決這個問題，可是多週期路徑約束會增長處理延時。

 

         這個問題，可使用物理綜合裏的寄存器重定時選項來進行優化。寄存器重定時將移動關鍵路徑上的寄存器位置來提高路徑時序性能。雖然這個優化選項將會增長編譯時間，可是它有可能會同時解決設計中其它的時序問題。

 

         使能寄存器重定時，能夠在Quartus II軟件的Assignments菜單下選擇Settings，在彈出的窗口找到物理綜合優化，使能寄存器重定時優化選項，同時將其「Effort level」設置爲「Extra」，點擊OK後從新編譯工程。

 

    編譯結束後，SCLK時鐘域全部時序問題都獲得瞭解決。