用RTL測試平臺驗證事務級IP模型

在系統級芯片設計中，設計驗證是一項十分重要的工作。傳統的驗證方法雖然比較簡單，但對設計工程師要求很高，而且驗證時間過長。本文介紹開放式設計和驗證語言SystemC，通過該語言可實現RTL測試平臺的復用，降低驗證成本，縮短驗證時間。

由于缺乏可靠的結構評估方法和軟、硬件協同驗證方法，系統結構設計工程師在設計系統級芯片(SoC)時，工作受到了一定的阻礙。值得慶幸的是，SystemC這種標準的用C++開發的資源開放式設計和驗證語言，為研究不同的系統結構，進行算法評估，軟、硬件任務劃分和軟件開發提供了有效的方法。

SystemC之所以能實現這些功能，原因就在于它簡化了事務級模型(transaction level model, TLM) 的開發。與寄存器傳輸級(RTL)模型比較而言，TLM屬于系統硬件組件在更高級別上的抽象。RTL模型中包含了比TLM模型更多的細節信息(如單獨的時 鐘周期等)，而TLM則在結構級的組件上交換數據或執行事件。簡言之，TLM所針對的應用是開發和驗證那些依賴于硬件的系統軟件部分。

TLM優于RTL模型的地方包括：

1. TLM比RTL更容易開發，需要消耗的人工時間也較少，并且仿真速度也比RTL模型快1萬到10萬倍；

2. TLM仿真所需耗費的時間只在秒級和分鐘級，而RTL則需耗費幾小時甚至幾天的時間。因此，在一個TLM級的IP模塊上可以真正運行軟件，而RTL IP則速度過慢，即使在一個指令級仿真器中也無法執行代碼。同時，SoC的設計方法學要求將過去設計的知識產權(IP)在更高的抽象級別上表現出來，從這 個角度來看，TLM也是很有用的。

如果工程師們能夠利用現有的RTL測試平臺來驗證TLM，那么還能進一步縮短TLM的驗證 時間。事實上，SoC設計驗證時間占據了整個產品開發過程的60％到70％，而且也是一次性工程成本中的重要組成部分。所謂一次性工程成本，包括開發測試 平臺所需的人工時間加上所有其他驗證工具所需的時間。

此外，如果驗證一個基于TLM的IP模塊時所采用的測試平臺也曾用來驗 證過該模塊的RTL模型，那么設計工程師們也就更容易對該模塊產生信心。這種信心又會促進TLM在設計流程中的應用，從而幫助縮短早期SoC設計和其后的 RTL設計之間的差距。今后，在重新利用RTL測試平臺來驗證TLM模塊這個領域內，研究重點將放在如何使該過程全面自動執行，以及如何將自動檢錯功能包 含進來。

有幾種工具可用來縮短驗證HDL模型所需的時間，其中包括Verisity Design公司的Specman Elite、Design Systems公司的開放式源碼程序TestBuilder以及Synopsys公司的VERA。然而就像開放式SystemC驗證庫最初所經歷的一樣， 針對SystemC設計的驗證工具也才剛剛起步，還需要一段時間才能成熟，這也使RTL測試平臺的重用問題更加引人矚目。

傳統的驗證方法

在不同的HDL專用工具間可能會存在差異，但除此以外，傳統的設計驗證方法無非都是將設計與一個激勵生成器和檢測器連接起來達到驗證的目的。其中，激勵生成 器用于啟動線程，向設計中寫入信號，而檢測器則用于驗證系統的響應。此外，在激勵生成器實現文件的頂部所聲明的事件結構用于綜合不同的線程(見圖1)。

這種驗證方法的好處在于：開發與驗證所用的是同一種語言，因此學習過程較為簡單；小型的專用測試程序較易編寫；并且無需額外的驗證工具，這也降低了成本。而 且，測試平臺開發成功之后，盡管比較簡單，仍然可以用作真實系統軟件的例子，讓嵌入式軟件設計工程師在起步時從中獲益。這種驗證方法的缺點在于，要編寫這 種測試平臺使其能夠作為最終軟件的基礎，需要設計工程師全面了解整個系統的工作原理。

想要為較重要的IP模塊開發出詳盡的測 試平臺必須付出大量的努力、時間和金錢，而且，即便如此，也很難知道開發出的測試平臺是否能夠全面地測試一個模塊。采用硬件驗證工具(如Specman、 TestBuilder和 VERA)可以使部分驗證過程自動執行，但并不意味著設計工程師可以少作努力，設計成本也依然高昂。

還有一種驗證方法，即編寫一種叫做集成測試平臺的軟件，以實現在整個系統中檢測IP。這種方法要求所有的IP模型均為可用，但它有一個好處，那就是IP可以在全系統的上下文環境下進行驗證，從而保證了模塊能夠確實按照設計的要求工作。

這些技術在開發類似TLM的IP模型時都是必須的。但如果采用驗證RTL時所使用的測試平臺來驗證TLM模塊，那么還能進一步節省驗證時間。這種測試平臺的“復用”通常發生在設計流程的RTL到布線階段。

一般而言，某一抽象級別上的測試平臺可以用來驗證較低抽象級別的IP模型(這就是所謂的自上向下兼容性)，反之則不行。然而事實上，在重用RTL測試平臺來驗證TLM級IP時所采用的正是與之相反的自下向上兼容的測試平臺。

在驗證IP之前，設計工程師必須清楚這個IP是如何使用的，并應知道一個高質量的測試應包含些什么內容。也就是說，高質量的測試應該充分全面。從這個角度上 看，TLM模塊必須滿足這樣的要求：運行于該模塊上的軟件應該也能運行在RTL級的模型上以及真正的系統中。只有這樣，設計工程師才能肯定TLM模型和 RTL模型是匹配的。要確保這一點，有一種方法，即在TLM IP上運行RTL測試平臺。

在采用RTL測試平臺來驗證TLM

IP時有兩個主要問題需要解決，一是TLM模型和RTL模型采用的語言不同，二是這兩種模型的抽象級別不同。至少有兩種技術可以解決這兩個問題。利用同樣的技術還可以實現用TLM測試平臺驗證RTL模型，但這樣做意義不大。

重用RTL測試平臺來驗證TLM模塊

可實現利用RTL測試平臺驗證一個TLM模塊的第一種技術就是將RTL模型用作一個“黃金”參考(即非常好的參考)，見圖2。這時，如果RTL模型和TLM模型的功能相當，那么對這兩種模型采用同樣的激勵就能在事務級上獲得完全相同的響應。

采用這種方法時，首先要將被仿真的RTL模型對某一早先開發好的測試平臺的響應在模型接口處取出，以記錄下事件序列。接著，將這些序列轉換成事務和事件，并 將其與TLM接受同樣的輸入時獲得的輸出進行比較。例如，對總線信號而言，設計工程師可以開發一種基于有限狀態機的工具，將總線控制信號轉換成符合總線協 議的TLM讀寫事務。中斷等類似信號也可以轉換為事務級的事件。

設計工程師可以采用一種腳本語言，從這些事務和事件中開發出一個SystemC生成器或測試平臺，以激活SystemC API(應用程序接口)信號。然后就可以將SystemC TLM的輸出與RTL模型所驅動的輸出序列相比較。

下面我們以一個時序器模型為例，該模型連接到ARM公司的AMBA片上總線。第一步是在時序器的RTL模型上運行HDL(硬件描述語言)測試平臺，然后用一 個分析工具來構成時序器接口的總線信號和中斷。分析工具可由TestBuilder構成，該工具能夠提取出HDL形式的信號，并將其轉化為C++格式。一 旦信號變成了C++格式，其值也被有限狀態機代碼修改為AMBA總線事務并被記錄下來。發生了變化的中斷信號值也被記錄下來。其中，特別是在一次讀寫事務 的過程中發生的中斷，在這次事務之后都會被記錄下來。

以下樣本文件給出了被存儲下來的一系列事務和事件，也即一系列讀寫操作 和中斷操作(見列表1)。該文件通過腳本語言被轉化為一個SystemC測試平臺(見列表2)。例如，對于讀寫事務而言，腳本分別向RTL測試平臺和 TLM測試平臺的同樣地址讀、寫數據，然后將TLM測試平臺得到的結果與HDL的值進行比較。如果這些結果和所有的中斷均能吻合，那么該TLM模型就通過 了測試。

TLM中存在的問題

然而，即使TLM是正確的，由一個中斷引起的值的變 化也可能與TLM接口上的值的變化不一致。這時就必須進行人工檢查。以時序器為例，設計工程師可能發現在HDL模型中，一次中斷發生在10次讀操作之后， 而在TLM模型中，該中斷則要么過早出現，要么過晚出現。問題就在于TLM缺乏RTL模型所具備的高度精確的時序。很顯然，任何檢查軟件都會把這種情況當 作出錯，然后進行人工分析，結果卻發現TLM模塊事實上工作正確。

再舉一例，如果在一次TLM事務中的數據讀操作與RTL級的操作不匹配，原因仍然很可能是TLM缺乏精確時序，但這并不意味著TLM模型有毛病。只要TLM的中斷時序不精確，而HDL模型在工作時只要不發生中斷就保持連續讀操作，那么時序不匹配就總是一個問題。

在輸入為非關聯情況下，讀、寫序列不匹配的情況也可能發生。例如，假設在RTL模型中，幾個寫操作向寄存器寫值，其中的第一個操作在10個周期后會產生一個 獨特的輸出X，并假設在X被記錄下來之前的這10個周期中，又發生了向其他寄存器讀和寫的操作。而在TLM模型中，輸出X可以立即被記錄，這樣，表面上看 來，TLM模型又出錯了。

以上的每種情況出現時，都需要人工來研究和解決問題，這就使驗證所需付出的代價和成本增大。在 ARM時序器一例中，用RTL測試平臺驗證大約需要5天人工時間。表1列出了用RTL測試平臺驗證其他采用了TLM的ARM功能塊(ARM將其稱作 PrimeCells)時所需的工作量。

有時，RTL測試平臺也許并不適用于驗證TLM模塊。時序測試平臺就是其中的一例， 該平臺的測試重點是時序條件，而非功能性。但這類測試平臺卻能用來校正時序的TLM。此外，那些測試通信協議(包括總線協議和握手協議)的測試平臺也不適 用于測試TLM模型。因為協議測試這類操作對于TLM而言級別太低，TLM無法對讀、寫操作的協議建模。另外，那些結果中會產生“don't care”狀態的測試平臺也不適用于測試TLM。

總之，這種重用RTL測試平臺的方法保證了TLM模塊在給定一個輸入時，能 夠得到與RTL模型相同的輸出。如果在驗證RTL模型時所用的輸入已經非常全面，那么只要一個SystemC TLM能夠產生與RTL模型同樣的輸出，那么我們就可以認為二者具備同樣的功能。而且，雖然并非所有RTL測試平臺均適用于TLM，但大多數都可以在 TLM上重用，因此開發成本也降到了最低。

關于該方法的缺點，此前已有論述，那就是TLM模型和RTL模型之間可能出現的時序失配，出現這種情況時需要一定的人工工作量。此外，腳本及其他用于將 RTL信號轉化為事務的軟件，在用于具備非標準接口的IP模型時，都應作出相應改動。值得慶幸的是，事實上 SoC設計中的大多數接口都是標準的總線類型。

另一種可供選擇的方法

重用RTL 測試平臺來驗證TLM模塊的另一種技術，就是采用一種允許混合語言仿真的工具，對SystemC模型和HDL模型進行協同仿真。該方法最主要的優勢就在 于，它無需首先在RTL模型上運行激勵，然后再用腳本將結果轉化為SystemC測試平臺。然而，采用協同仿真來實現向更高抽象級別轉化的做法也并非毫無 價值。

協同仿真采用了一種叫做包裝(wrapper)的SystemC模塊，該模塊可以將總線信號轉換為TLM讀寫事務。而 中斷等其他系統信號則可以通過SystemC信號與TLM模塊直接相連。但這時會產生一個問題，因為大多數RTL測試平臺都考慮了時序因素，因而它們就希 望TLM模塊能夠在一個給定的時間內對輸入信號作出響應，否則就宣告測試失敗。所以我們要么必須修改RTL測試平臺，使其忽略時序因素，要么必須修改 TLM和RTL接口，將二者調整為具備相同的時序因素。

RTL和TLM的協同仿真除了能夠驗證TLM模塊以外，還能勝任幾項 其他的任務。例如，SystemC TLM就能用作驗證RTL模型的測試平臺。但由于SystemC測試平臺缺乏RTL模型的時序精度，所以它只能設計來檢查事件的功能是否完成，而不能用來 檢查事件的時序。

另外，RTL和TLM協同仿真還能用于測試整個SoC平臺的嵌入式軟件，即使并非所有的TLM模塊都已就 緒。設計工程師可以采用這種方法來編寫嵌入式軟件中需要硬件時序信息的那部分。但由于仿真RTL需要很長時間，所以此項技術存在局限性。但隨著代碼長度向 短小精煉發展，該技術的應用價值也越來越高。