為了滿足對功率、性能和面積的要求，系統級芯片(soc)和處理器設計團隊面臨著挑戰(zhàn)。隨著芯片復雜度的增加，設計團隊必須驗證成千行的代碼以獲得設計信心。為了取得成功，設計團隊必須在緊迫的產品上市時間內達到系統目標和驗證標準。

    設計信心的增加是與獨特測試序列的數量和系統級測試完整性呈函數關系。隨著rtl修改的減少，功能驗證投入增加，從而產生一種“已測試”模塊。此時，仿真測試工具要花幾天或幾周時間完成，并且對設計改變非常敏感。功能驗證中的確認要用數以億計的仿真向量才能實現，難怪設計工程師臨近設計末期都拒絕做出改變。

    但是，如果最初的布局和布線結果顯示設計不滿足系統時序或功率目標怎么辦？經過評估，設計工程師可能得出結論：通過對數據路徑的檢查，或許需要控制邏輯！這可能是一個簡單的改變或一次重要的重寫�？謶种幵谟谥匦买炞C經修改的設計需要多少工作，并且所做的改變讓所有過去的功能驗證投資付之東流水。

    在這些境況下，大多數工程師主張做盡可能最少的侵入性改變。然而，這可能引起問題：在全局環(huán)境下簡單修正在局部實現上變得復雜，或者使風險最小的修正可能不完全滿足系統標準，且需要多次反復改變。對rtl的任何改變，無論有多小，都可能引入細微的負面影響。

    連續(xù)改變(sequential change)

    在大多數情況下，設計工程師通過把微架構轉換到rtl代碼來滿足時序、功率和面積目標，微架構轉換是連續(xù)的修改。當rtl模型經歷優(yōu)化時，設計工程師對關鍵設計功能如緩存大小、管線(pipeline)的數量和功率管理執(zhí)行“what-if”分析。

    在soc和處理器設計中，功率、時序和面積特性難以評估和折衷�？晒┻x擇的微架構具有大量不同的數據路徑，而控制邏輯的實現需要付出大量的工作進行開發(fā)和驗證。

    仿真可以被用于驗證微架構優(yōu)化。然而，仿真測試工具要運行數周，而連續(xù)的改變可能讓現有的測試基準(testbench)失效。測試基準的效用因為設計延遲、吞吐量或i/o信號的差異性而降低。當發(fā)生這種情況時，測試基準需要手動檢查和調整。

    在許多情形下，測試基準比設計還要復雜，使測試基準的改變易受其自身缺陷的影響。根據情況，測試基準故障可能從模塊級變化到子系統，或者甚至系統級測試。設計團隊通過采用事務或握手接口寫測試基準使連續(xù)改變的影響限制在局部。

    圖1：averaged設計。

    連續(xù)等效檢查為設計工程師提供了另一種功能驗證選項。通過證明具有連續(xù)差異的設計之間等效，所有早先的功能驗證投入可以在未來rtl的實現中得到利用。連續(xù)等效檢查確保微架構變換的功能正確性，給設計工程師以信心來進行設計后期的rtl改變。該技術也提供了對副作用的快速檢測方法，并確保rtl優(yōu)化與原始功能意圖保持一致。

    連續(xù)改變的實例

    一個邏輯設計、模塊或整個芯片可以看作由連續(xù)狀態(tài)(或存儲器)和組合邏輯構成的機器(machine)。組合邏輯負責計算下一個機器狀態(tài)，該狀態(tài)是任一時間點的輸入和當前機器狀態(tài)的函數。根據該邏輯是由moore機器還是由mealy機器構成，機器輸出是該時間點的當前狀態(tài)和/或輸入的函數。

    圖1中描繪的設計有四個輸入值，它輸出四個值的平均值及輸入值3與平均值的絕對差。通過rtl代碼、電路圖和狀態(tài)時序圖完全描述了該設計。圖1中average4設計表示有一個狀態(tài)級，即輸出上的寄存器。

    改變該設計以連續(xù)地讀取輸入數值就會修改狀態(tài)和時序。這個連續(xù)變換是一個簡單連續(xù)修正的例子。圖2所示為average4設計的連續(xù)輸入實現，請注意到用于存儲輸入所加的寄存器、有限狀態(tài)機(fsm)，以及相應的輸出延遲。

    在我們的例子中，圖2中average4設計在功能上等效于圖1中的average4設計。假設采用相同的輸入序列，如果從一致的狀態(tài)開始，經過一段時間兩個設計都產生相同的輸出，那么這一對設計被判定為等效。

    在該例子中，簡單的檢查顯示在圖1周期n中的采樣輸出與在圖2周期(n*4)+1中的輸出匹配。這個例子證明，功能上等效的設計可能實質上存在組合邏輯及存儲和訪問狀態(tài)方式上的差異。

    連續(xù)變換以改善功率

    隨著芯片的日益復雜，需要在性能、面積和功率三者之間進行