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

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

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

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

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

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

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

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

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

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

傳統(tǒng)的驗(yàn)證方法

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

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

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

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

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

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

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

在采用RTL測試平臺來驗(yàn)證TLM

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

重用RTL測試平臺來驗(yàn)證TLM模塊

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

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

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

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

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

TLM中存在的問題

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

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

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

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

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

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

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

另一種可供選擇的方法

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

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

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

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