用RTL測試平臺驗證事務(wù)級IP模型

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

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

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

TLM優(yōu)于RTL模型的地方包括：

1. TLM比RTL更容易開(kāi)發(fā)，需要消耗的人工時(shí)間也較少，并且仿真速度也比RTL模型快1萬(wàn)到10萬(wàn)倍；

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

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

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

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

傳統的驗證方法

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

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

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

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

這些技術(shù)在開(kāi)發(fā)類(lèi)似TLM的IP模型時(shí)都是必須的。但如果采用驗證RTL時(shí)所使用的測試平臺來(lái)驗證TLM模塊，那么還能進(jìn)一步節省驗證時(shí)間。這種測試平臺的“復用”通常發(fā)生在設計流程的RTL到布線(xiàn)階段。

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

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

在采用RTL測試平臺來(lái)驗證TLM

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

重用RTL測試平臺來(lái)驗證TLM模塊

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

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

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

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

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

TLM中存在的問(wèn)題

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

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

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

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

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

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

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

另一種可供選擇的方法

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

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

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

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