八通道多協議串行通信控制器的功能驗證
驗證平臺總線功能模型中一個cpu寫周期的本文引用地址:http://www.104case.com/article/163855.htm
在對某個設備的寄存器進行讀操作時,譬如,向地址為ADDR的狀態寄存器寫入DATA數據,在testcase里調用該任務可以寫成:
2.2 功能覆蓋率
功能驗證的另一個關鍵問題是驗證工作到什么程度,如何保證驗證的充分性。對于通信控制器芯片,更關心的是功能覆蓋率。功能覆蓋率是衡量設計的原始要求實現程度的指標。
通信控制器功能實現主要體現在寄存器的配置組合上。前面提到,所采取的驗證策略是在單通道下分別在Intel總線和:Motorola總線接口按照數據傳送協議為劃分標準,將驗證分為異步、同步和HDLC三大類,然后再按照數據傳送類型,在中斷方式和DMA方式下驗證各個功能。最后再測試全通道的數據收發。通信控制器的每一個功能均有相應的testcase,配置寄存器的每一位都保證有翻轉。按照驗證計劃,驗證該通信控制器開發的testcase共計225個,通信控制器的全部功能均被覆蓋。
圖3~6示例了幾個testcase的仿真波形圖。圖3的testcase用來驗證通信控制器Intel總線接口異步協議DMA傳送模式下的數據傳送,DWT(DMArequest transmit)是DMA傳送請求信號,wrl和wr2是內部信號,當FIFO從數據總線上每成功讀取8bit數據時,wrl或者wr2信號跳變一次,結果顯示該testcase驗證通過。圖4是Motorola總線接口異步協議中斷傳送模式下數據傳送的一個testcase,圖5是Intel總線接口HDLC協議中斷傳送模式下數據傳送的一個testease。與圖3的分析相類似,波形顯示這兩個testcase驗證通過。圖6是驗證28個全局并口發送數據的testease,波形顯示四個并口先后發送數據55、66、77和F,該testease驗證通過。
2.3 錯誤狀態的驗證
對錯誤狀態的驗證是一個很重要的環節。在testease中,加入錯誤狀態激勵,觀察輸出結果是否符合預期。一些錯誤狀態比較容易實現,如某個配置項賦定義以外的值,只需在配置文件相應行上填入錯誤狀態配置值即可。再如很短的時間內發生了同一通道的兩次配置(即配置覆蓋),這只需在配置文件中的同一配置時刻參數段加入相同通道的又一次配置即可。另外一些錯誤狀態可以根據通信協議自行設定,如發送端和接收端配置的數據幀頭同步字符不一致,接收時鐘和發送時鐘不同步等。
圖7是一個錯誤狀態驗證的testcase波形圖。該testease是驗證通信控制器在Intel總線接口,同步協議的中斷方式傳送模式下數據傳送。發送端的同步幀設置為80,接收端的同步幀設置為8l。按照同步協議,同步幀不一樣,接收端的數據不能寫入FIFO。如所預期,wrl和wr2未發生跳變,表明發送數據沒有被接收。
2.4 后仿真與樣片測試
在實際電路中,信號的跳變不是瞬間完成的,而是具有一定的時延。功能驗證主要是驗證電路的邏輯功能,信號的跳變是瞬間完成的,因此只能在功能上證明設計的正確性,而無法證明在實際電路中邏輯功能依然正確。后仿真是對版圖提取了寄生參數以后考慮了互聯延遲進行的仿真。驗證在引入實際時延之后系統功能是否正確。
構建后仿真環境的思想與構建前仿真的思想基本相同。在功能驗證過程使用結構化和逐層抽象的方法來設計驗證環境,因此在后仿真的過程中可以復用前仿真的環境,測試用例也可以直接復用到后仿真的過程中。圖8是后仿真的一個波形。
采用上面介紹的驗證方案,作者成功地對八通道多協議串行通信控制器芯片進行了功能驗證,該芯片已成功流片并進行了樣片測試。將功能驗證時各testcase芯片每個管腳的輸入以及相應的輸出轉化為測試碼輸入測試機,驗證對于相同的輸入,芯片的實際輸出與功能驗證時的輸出是否相符。測試碼按照測試機的要求有一定的格式給出了一行測試碼。芯片目前也通過了樣片測試并已經實際應用。
3 結語
大規模集成電路的驗證是一項非常復雜的任務,使用總線功能模型構建可復用的驗證平臺能夠提高集成電路的驗證效率,縮短產品開發周期。本文采用總線功能模型實現了一款八通道多協議串行通信控制器芯片的功能驗證,相信這種方法對相關領域的設計驗證具有一定的參考價值。
評論