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

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

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

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

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

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

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

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

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

為此，保存和產生系統相應參數的data generator如下

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

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

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

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

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

PSS學前準備篇（合輯）

PSS基礎篇（合輯）

PSS測試篇（合輯）

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

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

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

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

做久了工程，我常常覺得，你的團隊未來的工作模式就來自于各條技術線的總監在一開始的架構規劃。

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

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

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

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

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

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

審核編輯 ：李倩