從跨平臺測試用例復(fù)用想到IP測試意圖交付

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PSS測試篇（合輯）

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

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

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

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

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

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

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

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

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

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

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

審核編輯 ：李倩