?

　　1 引 言

　　1. 1 背景

　　TURBO51的工程背景是TURBO51嵌入式微處理器結構設計上采取經時間考驗過的32位機主流系統結構， 在嚴格保證對8051 指令集兼容的前提下， 通過重新定義其處理器核的系統結構來挖掘處理器結構上的并行性實現。在傳統8051軟件開發環境下實現本要由更高位寬的32位處理器來完成的工作并完全重用所有現有軟件資源。在 8051指令級多種尋址方式混合且指令不定長的現實下實現了高性能的體系結構， 亂序發射， 分支預測， 精確例外處理， 基于猜測的先行預取， 片上一級指令高速緩存。處理器系統結構的復雜給驗證提出了很高的要求。而且， 由于TURBO51 是作為SoC 的嵌入式處理器核， 是整個大規模SOC 的控制核心和用戶接口， 如果嵌入式處理器設計中驗證不完善或性能達不到設計要求， 都會導致整個SoC 項目的開發致命失敗， 因此對嵌入式處理器的驗證在SoC 設計中是最重要的部分之一。

　　一切對高性能體系結構的追求都必須首先建立在以設計的正確性為前題才是有意義的。TURBO51的驗證面臨三個主要挑戰:

　　( 1)正確性， 所采用的高性能體系結構也是復雜和高風險的， 只有設計正確才會帶給SoC 性能上的提升。

　　( 2)兼容性: 相對于傳統8051， 在程序的執行過程中， 中斷和異常常會打斷程序的執行， 動態流水線的處理器由于指令的動態亂序執行， 但又必須對外部程序來說是和完全順序執行只存在速度的差別而非結果的差別， 所以它必須能精確地與順序執行條件下的例外結果保持一致。

　　( 3)指令和操作數空間巨大， 尋址方式復雜:

　　8051指令集共有111條指令， 有多種尋址方式和不定的指令長度。另外， 8051指令集還將輸入輸出設備寄存器與體系結構寄存器作為同種寄存器訪問。

　　這些都成為了結構設計和驗證中的難點問題。

　　( 4)驗證充分性的衡量: 在驗證過程中根據發現錯誤的性質、原因和數量分布， 評估正確性程度和調整下面的驗證計劃， 使驗證更深入， 實現設計錯誤的快速收斂。

　　1. 2 微處理器驗證現狀

　　目前世界各處理器公司用于功能驗證的方式主要是模擬驗證， 形式驗證， 硬件仿真加速。但總的看來， 由于指令集龐大， 比如， 它的完全無錯的測試向量的數量是指令條數階乘及每個操作數， 地址數階乘。在有限的時間很難實現。除非指令和操作數的所有兩兩組合都已測試過， 否則， 即便經過了這些驗證， 也只能證明在測試已覆蓋地方正確而不能證明設計在任何情況下都正確。

　　形式驗證是指通過數學方法證明設計的完備性， 即這種方法下的樣本空間是測試對象所有可能的狀態。A rithSMV， * PHDD。由于狀態樣本空間巨大， 它只用設計屬性檢查工具， 目前僅用于局部邏緝驗證。

　　模擬驗證: 包括RTL仿真和門級仿真。這一階段驗證的效果很大程度上由測試激勵和判定模擬結果的方法決定。在微處理器驗證中， 采用匯編語言編寫測試激勵， 運行操作系統， 應用程序和隨機生成測試向量。

　　硬件加速仿真: 為克服模擬仿真驗證速度慢的缺點， 采用FPGA 的物理原型驗證可以在流片前運行操作系統和應用程序， 進一步在系統級驗證正確性。

　　2 TURBO51的驗證方法

　　TURBO51在設計中用到了形式驗證、模擬仿真和硬件加速仿真。采用自底向上的子模塊級驗證再自頂向下的宏模塊及系統級驗證的方法。在整個設計過程中， 驗證與設計是一個整體， TURBO51在進行文檔時序設計時就同時開始針對正在進行的設計編寫驗證計劃， 設計和驗證的工作在設計文檔和驗證計劃中進行精確到每個時鐘周期的行為描述和變量定義開始， 是整個設計和驗證最重要的部分。由于TURBO51的設計要保證對傳統8051指令集的后向兼容， TURBO51采用兩臺可進行單步調試的8051硬件仿真器， 兩片傳統8051， 兩片采用了簡單流水結構的改進版8051 作為正確標尺。測試激勵在此先逐一運行， 并將其運行結果作為界定執行正確和兼容正確的標準。每個模塊在每個時鐘周期的每個寄存器讀寫和各個設計階段的驗證方法， 驗證結果，問題分布， 驗證策略在此規定， 并手工編寫測試程序進行仿真。在驗證文檔中記錄如何判定設計正確的與嚴重設計漏洞及原因， 并在設計文檔中記錄哪些臨界態已考慮過了， 為以后懷疑某種情況下有沒有可能是此出錯提供重要依據。在TURBO51的設計中覆蓋率指標在文檔階段已經引入， 每個設計了的邏輯一定要用測試來證明有必要這樣設計和功能正確。功能設計中每個條件判斷總能在測試文檔中找到測這個條件的方法及判對標準。很多時候在寫測試方法時發現了很多設計中沒有考慮過的情況。功能設計文檔和以覆蓋率為指導的驗證文檔相互作用， 使TURBO51在開始RTL之前就己經完成了時序設計， 寄存器定義及全部塊級測試的完全覆蓋， 比如在寄存器重命名中多種尋地方式下對同一物理地址寫入的重命名， 亂序發射， 精確例外。一般說來，越是文檔級描述的錯誤越容易修改， 越是硬件級的錯誤越難于發現， 修改量很大且容易引入其他錯誤。

　　這個階段可以較容易用排列組合等進行形式驗證進行完全的情況覆蓋， 排除了絕大部分嚴重錯誤， 而且用于仿真的手工編寫的測試程序也用于此后的驗證中。RTL不過是文檔的一個V erilog 描述的翻譯過程， 因此RTL并不是TURBO51設計最重要的地方，只是要按功能設計文檔和代碼檢查的要求可很快完成， 但期間要用綜合結果指導對流水線負載平衡并在細節上進一步調整， 但每一處與原功能設計文檔描述不同的RTL修改首先是修改功能及驗證文檔，再次審核通過后才能改動RTL 代碼。仿真和RTL編寫是一體的， 在Turbo51 驗證中分為模塊、宏模塊、系統級3個階段。只有在一個階段的設計和驗證及文檔完全達到計劃要求， 即代碼檢查和代碼覆蓋率后才能再開始下一階段工作， 這樣使得錯誤得以快速收斂。這期間把錯誤分為高風險區錯誤和低風險區錯誤。出現不正常時首先從影響程序運行走向的高風險區開始排查， 排除高風險區的錯誤后再去找低風險區錯誤。模塊級RTL 模擬仿真完成后就是宏模塊級， 指令流水線， LOAD /STORE， Cache等， 再下來是系統級RTL 仿真。在Turbo51 的設計驗證中， 只有在TURBO51 整個的RTL代碼規范檢驗代碼覆蓋率達到RTL模擬仿真對覆蓋率的要求并通過設計描述文檔與驗證文檔相結合的審議通過后才可以再進行FPGA 驗證。所以TURBO51設計驗證的底線是在FPGA 硬件原形驗證前至少排除全部會引起死機或兼容性的這類嚴重錯誤。TURBO51的設計驗證不是依賴下一階段測試發現本應在上個階段發現并解決的錯誤， 而是只用下階段確認上階段目標的完成。FPGA 驗證的目的是用于測試長時間在真實環境下運行應用程序， 因為畢竟很多對外部信號的響應不易在RTL 仿真中模擬， 而不是用來發現調試應在仿真中排除的問題。

　　3 形式驗證

　　形式驗證的好處是它能遍歷全部狀態空間， 可以實現驗證的完備。它在設計行為描述規格書中就開始使用， 用于高風險區的存貯訪問， 高速緩存， 分支預測， 動態執行， 例外處理中最高風險組合的完備性證明。比如在TURBO51 的片內一級指令高速緩存的替換策略設計時， 必須要處理每個可能的狀態，吞則可能會出現狀態機死鎖。在這里首先就是對是否有且僅有的幾種狀態進行數學證明， 然后再開始編寫功能行為描述和驗證計劃。這種方式可以使出錯影響大但狀態空間不大的邏輯達到完全正確， 而且后來的事實也證明， 通過形式的設計在此后的所有測試激勵下沒有出現異常。

　　形式驗證在TURBO51 驗證中的另一個地方是在進行RTL代碼風格檢查的時候用形式驗證工具對修改前后的RTL進行功能比較， 另外類似的做法也用于物理網表與前端網表的等價性比較。

　　4 RTL模擬仿真和覆蓋率及代碼風格檢查

　　4. 1 RTL仿真

　　在功能時序文檔和制定RTL 模擬仿真計劃時，RTL編寫和模擬仿真在每個子模塊， 宏模塊， 系統級設計功能行為描述和驗證計劃完成后才開始， 每個子模塊RTL編碼完成后放入用行為級描述的模型進行仿真， 再用EDA 工具提供的代碼檢查工具作RTL代碼檢查， 再仿真直到達到代碼覆蓋率， 然后層層向上做宏模塊和系統級的RTL 代碼檢查和基于代碼覆蓋率的仿真。驗證的主要排錯和測試在這個階段進行， 包括檢查是否與8051標準完全兼容的驗證， 高風險區的驗證和運行操作系統及應用程序。

　　這里面使用了兩個標準， 即由EDA工具給出的測試激勵對已設計邏輯的代碼覆蓋率和自己定義的臨界功能覆蓋率。

　　在模擬仿真中， 對臨界指令組合采用手工匯編語言編寫激勵。在兼容性測試中， 包括指令集測試，位尋址空間遍歷， 上電測值測試， 寄存器文件讀寫遍歷， LS變量RAM 遍歷， 代碼空間分頁切換， 中斷控制， 8051標準外設， 定計， IO， 擴展外設驗證， SOC 總線讀寫， PWM 脈寬調制， 在線程序燒入， 基礎應用:

　　軟件I2C讀寫， 從外部讀取64KB 數據和系統測試，基于操作系統的遙控按鍵解碼和對片上其它器件的參數讀取。在此期間使用閃存的仿真模型， 對于指令集測試， 在現有商用軟件開發環境下創建測試激勵， 對全部111條指令， 按 標準8051手冊上對每條指令的執行結果值， 按分支目標， 分支方向， 對標識位的影響這幾個方面進行測試。先在基準平臺上進行單步運行， 記下每條指令的每種狀態值， 再將這些值作為正確依據， 執行完一項比較一項結果， 如相同就繼續向前， 同時一條IO 輸出一個方波， 如不同則進入本條指令結果， 標記， 分支的死循環， 通過查這個死循環地址便可快速定位是錯在哪條指令的什么地方， 同時另一IO輸出另一種方波。此程序先在基準平臺運行通過， 不進死循環， 再把它轉成數據文件導入仿真模型。寄存器文件讀寫也是依據8051手冊， 區分不同尋址方式對應的寄存器文件。在測試結果中， 最重要的一個觀測點是指令提交地址寄存器， 它記錄了真正的處理器運行走向， 只要它未出現異常， 這個測試項就認為無嚴重錯誤。RTL模擬在TURBO51中分為測試激勵生成， 結果檢測和覆蓋率分析三個部分。TURBO51采用了手工編寫臨界條件和基礎測試程序， 通過后再運行實際應用程序和操作系統。此階段完成的標準是對代碼和功能覆蓋率的檢查。在模塊級RTL的編寫過程中一邊對代碼風格和仿真測試覆蓋率進行檢查， 同時進行綜合以測試關鍵路徑對設計時序的滿足。作為輔助驗證， 自動指令生成指令庫， 指令生成控制器生成的測試激勵同時也在一個行為級8051指令集模擬器仿真模型中一起運行， 逐條進行結果比較， 當發現結果不一致時對指令進行記錄， 當發現分支不一致時仿真停止或仿真量到達一定規模時也停止仿真， 供查看代碼覆蓋率用。

　　4. 2 覆蓋率和代碼風格檢查

　　基于模擬仿真的驗證的困難是無論采用的測試激勵是來自真實應用還是指令自動生成， 都無法證明整個處理器不出錯。因此TURBO51仿真驗證的完成標準是在錯誤收斂了的情況下增加更多的測試向量， 使EDA 工具提供的設計邏輯覆蓋率達到塊級100%和表達式級93% ， 功能覆蓋率達到100% 。

　　功能覆蓋率的測試是設計規格書中定義的全部行為和驗證計劃的全部臨界點。在進行覆蓋率檢查的過程中， 可以得出目前的總覆蓋率和對一個模塊中某個狀態未被測試向量覆蓋的邏緝和輸入值， 它指明了漏洞存在， 指導手工編寫直接針對未覆蓋邏緝的測試。另外代碼覆蓋在TURBO51的設計中也被用于排除冗余或重復的邏輯， 節省不必要的關鍵路徑開銷和邏輯資源。代碼檢查: 代碼檢查使用EDA 工具所提供的功能。使代碼在綜合中不會產生異常， 使模擬仿真的結果與FPGA 不一致。在這里用形式驗證工具對修改后和修改前的代碼進行等價性比較。表1是各大模塊的RTL 仿真代碼覆蓋率， 表2是主要模塊在不同測試激勵下的代碼塊覆蓋率和表達式覆蓋率。均由Cadence Incisive 給出。

　　表1 主要模塊代碼測式覆概率。

?

　　表2 主要模塊在不同的測試激勵下的覆蓋率

?

　　5 物理原型驗證

　　物理原型驗證是AS IC 設計中通常采用的另一種重要的驗證手段。它是將RTL 描述通過針對FPGA目標器件的綜合及優化， 布局布線及優化并同時進行了靜態時序分析后形成ASIC 設計的另一種物理實現形式。它能比RTL 模擬仿真更接近真實的AS IC， 能在系統板上在功能上完全取代ASIC 進行工作， 但最高速度一般比ASIC 慢一半以上。在這些都完成并通過了設計描述文檔和驗證文檔的審核后進行FPGA 硬件加速仿真， 完全在系統應用環境下檢驗兼容性及正確性并做出初步性能*測。相對于仿真而言， 它能在提高系統運行速度上提高幾個數量級。

　　TURBO51的FPGA 驗證的前提是設計已經過了關鍵點的形式驗證， 完成了塊覆蓋率為100% 的RTL仿真及代碼檢查且錯誤已收斂完畢， 故對FPGA驗證的首要目的是通過運行和真實應用環境完全相同的完整目標應用系統驗證兩步的錯誤估計是否正確并配合其他SOC 模塊作SOC 協同驗證。因為對有的仿真做起來不方便的系統驗證在FPGA 平臺上很方便驗證。在TURBO51的FPGA 驗證中， 充分利用了FPGA 上的剩余資源， 用于實時定位與監測TURBO51的FPGA 實現版每個時鐘的狀態及其運行狀態， 這其實已使原本認為FPGA 上難于定位錯誤的缺陷大為改觀， 在真實環境下運行系統提供了非常接近RTL仿真的調試能力的觀測窗口。這里依然首先選用了指令提交地址和指令取指地址，累加器， B 寄存器， 程序狀態字PSW， 重定序緩沖狀態， 例外處理標識， 寫回總線， 提交總線位為主要觀察點， 顯示每個時鐘的狀態， 將它們協同SOC 其它模塊的輸出， 示波器觀測輸出波形結果一起形成FPGA 驗證結果。TURBO51在FPGA 驗證時工作在60MH z， 除運行全部手工編寫的用于模擬仿真的測試程序外， 還成功連續兩百小時運行全部現有量產的基于RTOS商用系統及其極限條件， 沒有發現嚴重錯誤。通過對寄存器值的實時監測發現十處以內的外設非致命錯， 比如GPIO 與外設輸入輸出復用。

　　當然， 每改一次RTL或監視寄存器都需要重新進行FPGA 燒寫文件的生成， TURBO51耗時近兩小時， 故它仍然不可能取代仿真。完成FPGA 驗證后做準備流片的工廠提供的工藝標準單元庫綜合及靜態時序分析， 交出網表做后端布局布線， 完成后再用帶門延時的后端門級網表進行門級仿真， 最后編寫樣片基臺測試程序。

　　6 驗證結果分析

　　由于最初在制定實現的方法和制定驗證計劃時是同步進行的， 致使整個設計階段的錯誤累積。在TURBO51的設計和驗證中， 首先用形式驗證將最高風險的存貯訪問， 高速緩存， 分支預測， 動態執行， 例外處理中的最高風險組合進行完備證明， 使錯誤得以排除。在此后的驗證中， 凡經形式驗證正確的部分再未出現過異常， 如圖1所示。

?

　　圖1 錯誤時間累計統計。

　　這樣使得全部的高風險錯誤在RTL仿真的中期已經全部排除并且大多數都由手工編寫的測試激勵完成。由于8051指令集指令死角空間相對較小，手工編寫可行。其中大部分RTL 仿真發現的錯是IO設備錯誤與處理器指令執行部分無關。如圖2所示， 錯誤99. 7% 百分比在FPGA 驗證前已收斂，故可認定前面工作扎實有效。假如一個設計如果在FPGA 驗證階段錯誤還未能收斂完， 還能發現大量新增錯誤尤其是嚴重錯誤的話， 這說明仿真及行為模型描述與驗證計劃都存在嚴重問題， 應退回去重走一遍， 否則流片風險較大。

?

　　圖2 不同驗證階段發現的錯誤分布統計。

　　7 總結和未來工作

　　TURBO51嵌入式微處理器使用了上述多種驗證方法使得越嚴重的錯誤得到了越早的收斂， 加上高的RTL代碼覆蓋率及長時間在FPGA 上成功運行了全部目標應用程序及所有仿真測試程序， 表明設計正確且兼容性完備， 使TURBO51嵌入式微處理器順利采用富士通微電子(日本) 90nmCMOS 工藝一次流片成功。但另一方面， 可配置約束的自動隨機指令序列已在更復雜的處理器驗證中越來越廣泛地采用， TURBO51的驗證中在這一方面目前還處于初級階段， 這將是以后的主要改進方向。