記得在大概6、7年前的時(shí)候，我當(dāng)時(shí)看到這家公司海量的emulation資源時(shí)那種驚掉下巴的樣子現(xiàn)在都還記得。現(xiàn)在國內(nèi)使用EMU也越來越多了，不過從測試用例的比重上看，EMU所占比例總體還是有較大空間提升的。這篇論文的格式更為自由一些，就跟聊天似的把他們?cè)谧隹缙脚_(tái)復(fù)用的動(dòng)機(jī)、架構(gòu)、方法都介紹了，不過更為細(xì)節(jié)的東西并沒有透露。但是從一個(gè)initiative的角度出發(fā)，這篇論文還是能夠回答我在學(xué)習(xí)PSS（Portable Stimulus Standard）時(shí)的一個(gè)疑問，那就是在PSS execution層面的顆粒度應(yīng)該做到多大才合適。我們接下來且順著這篇論文的思路一起捋一遍。

像Intel這樣的大公司，在產(chǎn)品線每年跟摩爾定律一樣按照產(chǎn)品路線推出芯片的時(shí)候，他們?cè)跍y試時(shí)的測試用例肯定不會(huì)跟初創(chuàng)公司似的，需要從零開始構(gòu)建。大公司呆過的人都知道那里的流程封裝得多么完善，那里蹲著多少資深的工程師，當(dāng)然那里的測試用例也都是每個(gè)項(xiàng)目一個(gè)個(gè)地繼承下來的。

談到繼承，就不得不接著探討類似像這樣產(chǎn)品線穩(wěn)定，產(chǎn)品按版本、參數(shù)迭代的情況下，會(huì)對(duì)驗(yàn)證（文中稱為validation，即分為pre-validation和post）的要求有哪些大格局的要求。

SoC和子系統(tǒng)（subsystems）也是IP的集合，在SoC或者子系統(tǒng)層面驗(yàn)證時(shí)，相比于IP驗(yàn)證時(shí)的功能深入，我們更關(guān)注于IP在系統(tǒng)中的角色、它與其它IP之間的互動(dòng)。而如果SoC類芯片一代一代滾動(dòng)起來，那么代與代之間的配置、參數(shù)差異，以及同一代產(chǎn)品的各個(gè)小版本之間的差異，都將會(huì)給測試的復(fù)用帶來挑戰(zhàn)。

此外，不同測試階段使用的工具、環(huán)境也會(huì)帶來挑戰(zhàn)。比如你在FPGA上面做原型驗(yàn)證它是可以帶著真實(shí)的外部板卡做測試的，但如果在EMU上面做，那么終端設(shè)備可能是真實(shí)板卡，也可以是虛擬板卡，還可以使用transactors去模擬IP和controller之間的數(shù)據(jù)交互。再比如，在制造環(huán)節(jié)篩選時(shí)，也由于post-silicon平臺(tái)的制約，可能會(huì)采取不同的設(shè)備和其它組件用作測試。這種跨平臺(tái)的差異，也給測試用例的復(fù)用帶來了挑戰(zhàn)。

這里其實(shí)沒有談到有關(guān)UVM的部分，有的時(shí)候UVM環(huán)境和用例往往意味著IP/子系統(tǒng)層面的測試，而到了SoC層面的測試，會(huì)更多關(guān)注于系統(tǒng)各個(gè)資源建模和調(diào)度場景。而且，為什么以前國內(nèi)FPGA公司做產(chǎn)品會(huì)更早地在FPGA上線去跑應(yīng)用呢？除了系統(tǒng)沒有SoC復(fù)雜之外，F(xiàn)PGA研發(fā)團(tuán)隊(duì)距離客戶近、FPGA產(chǎn)品更方便迭代也是一個(gè)重要原因。

在這篇論文里，沒有專門談到pre-silicon simulation的部分，這一點(diǎn)讀者們可能會(huì)好奇，但有的時(shí)候當(dāng)一家公司“財(cái)大氣粗”的時(shí)候，他們真的是有財(cái)力可以把多數(shù)測試用例放在硬件仿真資源EMU上面去跑的。所以，這篇論文的語境其實(shí)是，當(dāng)我們?cè)陂_發(fā)一個(gè)SoC系統(tǒng)且已經(jīng)到了SoC測試階段的時(shí)候，我們?yōu)榱藴y試更多的應(yīng)用場景，如果在裸機(jī)（bare metal）上、最小OS kernel上、或者更大OS層面去運(yùn)行的時(shí)候，如何去解決這些跨平臺(tái)（wide diversity of platforms）、跨系統(tǒng)（various operating systems Windows/Linux etc）的挑戰(zhàn)？

這里給的一個(gè)方案是提出IP validation software stack，即構(gòu)建出彈性的結(jié)構(gòu)以便讓IP測試時(shí)的測試意圖可以最終通過PSS生成測試代碼，而這些測試代碼可以利用這個(gè)IP validation software stack，根據(jù)所處的平臺(tái)、芯片系統(tǒng)的版本不同都能夠穩(wěn)定運(yùn)行，最終實(shí)現(xiàn)IP在集成層面的測試快速生成和運(yùn)行。

這篇論文的邏輯，是從底部往上走的，即先提出這個(gè)IP測試的軟件棧，解釋需要利用它的data generator來存儲(chǔ)和產(chǎn)生跨不同測試平臺(tái)、不同芯片版本的配置參數(shù)，而后可以利用這些參數(shù)，再與runtime driver+business logic結(jié)合，以便讓目標(biāo)IP得到恰當(dāng)?shù)呐渲?，最初匹配的行為?/p>

為此，保存和產(chǎn)生系統(tǒng)相應(yīng)參數(shù)的data generator如下

這些參數(shù)在獲取以后，可以利用IP驅(qū)動(dòng)（IPDMA）進(jìn)行配置，而在IPDMA內(nèi)可以“彈性”地根據(jù)IP功能來實(shí)現(xiàn)（即底層的OS/HAL+寄存器配置）。

“IPDMA”也并不需要指出該DMA的版本、通道、緩存等具體信息，它“暴露”給測試人員的，也無需指出IP版本或者具體寄存器等信息。而在“IPDMA”內(nèi)可以利用“dp”來獲得該IP的參數(shù)，再利用它們進(jìn)行功能配置。在配置時(shí)，所使用的“mem_write”等函數(shù)，也脫離實(shí)際的操作系統(tǒng)，實(shí)現(xiàn)更為底層的操作，即這些底層函數(shù)可以“剛性”地跨平臺(tái)（這一點(diǎn)不難做到）。

有了這樣的一個(gè)IP測試的軟件棧，便可以理解跨平臺(tái)、芯片系統(tǒng)版本差異的問題，繼而為各個(gè)IP和SoC系統(tǒng)測試意圖能夠在其之上進(jìn)一步完成創(chuàng)造了條件。

事實(shí)上，這個(gè)簡化后的IP測試軟件棧也能解決一些讀者目前的困境，尤其是公司開始批量出貨，既想要繼承以前的測試用例（但受限于系統(tǒng)差異無法做到直接復(fù)用），也想要節(jié)省人力（如果測試能夠繼承，那么節(jié)省人力也就自然可以達(dá)成）。

我在更早前已經(jīng)完整地梳理過一次PSS基礎(chǔ)語法，突出PSS的可移植特點(diǎn)也是體現(xiàn)在不同的測試平臺(tái)和測試語言層面，無論它解決的是測試平臺(tái)問題，還是測試層次問題，還是測試語言問題，PSS呈現(xiàn)出的都是從更高的視角去給每個(gè)IP進(jìn)行建模，繼而將這些IP模型構(gòu)建成為一個(gè)更大的系統(tǒng)，再在這個(gè)系統(tǒng)模型中去創(chuàng)建一些各個(gè)IP和資源之間的調(diào)度關(guān)系。也就是說，PSS做的是測試意圖（validation content）層面的工作，諸如PerSpec/inFact/Breker Trek做的是content2graph的工作即從意圖到測試場景生成的工作，而生成的測試場景，無論采用的是什么語言，都需要我們給到一個(gè)恰當(dāng)?shù)念w粒度。這樣才能把PSS在實(shí)際工作中運(yùn)用好。

PSS學(xué)前準(zhǔn)備篇（合輯）

PSS基礎(chǔ)篇（合輯）

PSS測試篇（合輯）

而這篇論文解決的正是“顆粒度”的這個(gè)問題，通過論文作者他們已經(jīng)驗(yàn)證過的IP validation software stack，不但他們給出了諸如“IPDMA”這樣的顆粒度適合的接口，也可以在該接口內(nèi)部“彈性”地解決跨平臺(tái)、適配芯片系統(tǒng)版本差異的問題。

至于PSS的具體應(yīng)用，他們沒有在論文中談到（也不是他們要在論文中介紹的流程）。他們也提到了目前在應(yīng)用的是Cadence PerSpec工具和SLN（System Level Notation）語言，而且有計(jì)劃將現(xiàn)有的模型過渡到PSS標(biāo)準(zhǔn)。隨著2021 PSS 2.0版本的推出以及PerSpec已經(jīng)對(duì)PSS的支持來看，他們推進(jìn)模型轉(zhuǎn)換的工作是遲早的。這也讓我想起了當(dāng)時(shí)從OVM/VMM過渡到UVM的一段時(shí)間。

論文中同樣有價(jià)值的是作者在不同的項(xiàng)目之間，通過復(fù)用IP測試意圖，繼而由PerSpec生成可以跨平臺(tái)的測試用例以后，不但節(jié)省了很多的人力，也同樣提高了工作效率。下面是采取復(fù)用測試意圖生成測試用例所發(fā)現(xiàn)的bug數(shù)量，以及這些bug數(shù)量在每個(gè)項(xiàng)目中所占到的比重。無論是數(shù)量還是占比，這種復(fù)用方法，如果想要撥開跨平臺(tái)、系統(tǒng)差異、測試語言這些紛亂的因素，那么測試意圖的復(fù)用將會(huì)讓不同平臺(tái)的測試人員之間達(dá)成一致（大家不再因?yàn)榧夹g(shù)因素而難以達(dá)成某種程度的聯(lián)合）。而且如果這種復(fù)用從一開始的架構(gòu)就能夠規(guī)劃好，那么也將會(huì)在芯片代與代之間、產(chǎn)品與產(chǎn)品之間放大它的效力。

繼而在增效的前提下，為接下來制造環(huán)節(jié)和人力環(huán)節(jié)的成本節(jié)省，也就理所應(yīng)當(dāng)了。從數(shù)字來看還是相當(dāng)可觀的，也許一些讀者目前還暫時(shí)沒有遇到這種處境（哎這也是產(chǎn)品線又長又廣的毛病，可謂是大廠們有些凡爾賽的苦惱），但如果想增效，就應(yīng)該把測試層面去拔高，不管是simulation/emulation/fpga，還是pre-silicon/post-silicon，都應(yīng)該站在更大的一個(gè)格局去考慮這些事情，從大廠出來的人看待這些問題更有視野，也更愿意在早期投入一部分精力去籌劃這些事情。

做久了工程，我常常覺得，你的團(tuán)隊(duì)未來的工作模式就來自于各條技術(shù)線的總監(jiān)在一開始的架構(gòu)規(guī)劃。

接下來再來談?wù)勎覀兤恼碌念}目“從跨平臺(tái)測試用例復(fù)用想到IP測試意圖交付”里的“IP測試意圖交付”。以前IP交付時(shí)不管是內(nèi)部IP還是第三方IP，并不會(huì)給我們交付RTL和功能文檔的同時(shí)交付功能測試點(diǎn)（因?yàn)檫@是人家內(nèi)部的文檔，也牽扯到IP的完整開發(fā)，更可能被反向做IP開發(fā)）。我們這個(gè)時(shí)候要集成IP做測試的時(shí)候，有兩部分可以借鑒。一部分是IP配置生成后的測試代碼（Verilog/UVM居多），一部分是IP文檔中有時(shí)會(huì)出現(xiàn)的programming case/scenario的例子。但更多是將IP作為一個(gè)獨(dú)立組件，就實(shí)現(xiàn)其某些功能，做的配置描述。有的時(shí)候，IP還會(huì)提供一些驅(qū)動(dòng)（這已經(jīng)很友好了），但至于拿到這些IP如何在系統(tǒng)環(huán)境中與其它IP/資源進(jìn)行交互，其實(shí)IP提供商是沒有這個(gè)義務(wù)的（他們不會(huì)包含在產(chǎn)品中，但你如果邀請(qǐng)他們提供service花這筆錢也是可以有的）。

在這種情況下，如果以后PSS普及、且PSS測試意圖到測試代碼的實(shí)現(xiàn)也更為規(guī)范的話，那么IP提供商是可以在交付IP的時(shí)候，同時(shí)交付這個(gè)IP的PSS模型的，以便我們以后既可以集成在上層系統(tǒng)模型中，也可以利用它的action在系統(tǒng)層面構(gòu)建一些activity。只不過在文中也談到，這樣的要求有些不合理（unreasonable requirement）。

為什么需要IP的PSS模型，以及針對(duì)它們構(gòu)建的集成測試PSS場景呢？因?yàn)槿绻辛诉@樣高層次的描述，我們?cè)谀玫揭粋€(gè)IP以后做集成測試的時(shí)候，也就有了指向性更為明確的方向。不然就容易造成目前國內(nèi)很多SoC公司在集成IP時(shí)有些尷尬的情況，花了幾十個(gè)million買的各類IP，在集成測試的時(shí)候都有點(diǎn)盲人趕路，戰(zhàn)戰(zhàn)兢兢的（這個(gè)事實(shí)往往在初創(chuàng)公司都心照不宣了吧）。

要解決這個(gè)問題，就需要考慮實(shí)現(xiàn)“IP測試意圖交付”。目前大廠里不同平臺(tái)的人員針對(duì)IP集成測試，或者是看測試計(jì)劃、測試點(diǎn)，或者是看各個(gè)參考用例，可這是建立在驗(yàn)證人員有經(jīng)驗(yàn)的情況下的。一旦脫離了這個(gè)條件，要在大的方向上完成“及格測試”，都會(huì)有些困難。于是乎，我們目前提出了在UVM/C層面的IP測試復(fù)用建議，該建議要求針對(duì)每個(gè)IP在SoC層面測試時(shí)，利用一致化的測試指令（例如V3課程提供的Liezhen平臺(tái)），構(gòu)建每一個(gè)測試用例，而這些測試用例在項(xiàng)目發(fā)生變化時(shí)，可以較為方便地移植到（畢竟標(biāo)準(zhǔn)化測試平臺(tái)的底層指令是一樣的，無論是simulation還是emulation，無論是UVM還是C）。

這種方案可以在客戶那里將前期項(xiàng)目中的測試更早地標(biāo)準(zhǔn)化下來，也便于在接下來的項(xiàng)目中復(fù)用，更實(shí)際地說，也較為符合我們國內(nèi)公司目前普遍發(fā)展的階段。

只不過，我們?nèi)绻鼮殚L遠(yuǎn)地看，想要實(shí)現(xiàn)更多跨平臺(tái)的復(fù)用，就不能只在測試用例復(fù)用、測試指令標(biāo)準(zhǔn)化、測試平臺(tái)自動(dòng)化上面下功夫，下一個(gè)要考慮的還是PSS、IP建模和測試意圖復(fù)用。這一階段我們總歸是要走到的，目前國內(nèi)已經(jīng)有小比例的公司在試行PSS和相應(yīng)工具了。也希望這篇論文的解讀，能夠在接下來芯片一代代產(chǎn)品測試復(fù)用時(shí)帶來啟發(fā)，也希望讀者們（如果）在的初創(chuàng)公司能走到芯片量產(chǎn)，擁有這種一代一代芯片測試的幸福煩惱。

審核編輯 ：李倩