巨鵬錦,張曉冬,李 輝
(上海高性能集成電路設計中心,上海 201204)
隨著集成電路技術的飛速發展,高性能處理器設計的復雜度和規模不斷增大,同時激烈的行業競爭也促使高性能處理器廠家努力縮短產品研發周期,加快產品更新速度。近些年來,在國家大力發展自主可控信息產業的戰略下,國產高性能處理器研發取得長足的發展,產業化應用不斷深入。在國產高性能處理器設計技術不斷縮小與國外差距的同時,作為研發平臺支撐的國產處理器驗證技術必須適應處理器研發需要,不斷提升處理器驗證的核心技術能力。
當今高性能處理器的驗證通常綜合采用模擬驗證[1,2]、硬件仿真加速驗證[3,4]、FPGA原型驗證[5]、形式驗證[4,6]等方法。從各種驗證方法發現的設計錯誤統計來看,模擬驗證仍然是主要驗證手段,發現錯誤的比例占總數的九成左右,而處理器模擬驗證的最大難點在于如何能夠快速編寫和生成大量高質量的測試激勵。目前業界主要采用偽隨機激勵生成器來生成高質量的驗證程序。Stress Test[7]由基于馬爾可夫模型的生成器和活動監測器組成,生成器和監測器構成閉環生成模型,生成器利用用戶提供的模板和監測器反饋的信息生成驗證程序;Genesys-Pro[8 - 10]通過編寫測試模板、單指令建模、處理器結構建模,使用約束求解CSP(Constraint Satisfaction Problem)來生成測試激勵;文獻[11]提出一種基于分層思想的受限隨機激勵產生方法,通過測試層、場景層、功能層和指令層的多層約束,實現隨機激勵生成。以上激勵生成器的設計方法主要是針對如何高效生成偽隨機測試激勵、加快覆蓋率收斂速度方面的研究。但是,面對當今處理器不斷發展的架構設計,如多核、多線程、眾核等等,處理器偽隨機激勵生成器設計不僅需要考慮如何高效生成高覆蓋率的測試激勵,而且需要考慮當處理器架構變化時,如何能夠利用已有的測試激勵集合重構新架構處理器的測試激勵集合,從而最大限度重用已有的測試庫,以高起點開始新架構處理器的驗證工作,只有這樣才能滿足越來越短的處理器產品研發周期要求。
本文提出一種基于模型和庫的偽隨機激勵生成器實現方法,該方法能夠較好地解決處理器設計變化對已有測試激勵集合的影響,可以避免因設計變化而導致激勵生成器生成的測試激勵失效問題。本文設計實現的激勵生成器不但能夠適應處理器關鍵微結構的變化,還可以適應處理器指令集和地址空間的變化,而且在多核Cache一致性測試方面還可以適應多核處理器核心數量的改變。
建立一個高效的處理器偽隨機激勵生成器,需要充分考慮處理器功能驗證中的需求,包括:(1)指令流測試,用戶能夠選擇指令集合進行測試激勵生成;(2)異??刂?,用戶可以控制測試激勵中每種異常發生的頻度;(3)資源共享,用戶可以控制指令序列對CPU資源的共享情況,如寄存器、訪存地址等等;(4)循環,用戶可以定義各種類型的循環結構,用于特定情況的驗證;(5)數據類型,用戶調用這些數據類型可以方便隨機各種數據邊界情況,如整數最大、最小值數據、全零、浮點無窮大、非數等等;(6)偽隨機約束控制,偽隨機約束用于控制激勵生成器產生某些情況的概率,用戶既可以對激勵中的特定條目施加“局部約束”,也可以對激勵中某一類結構施加“全局約束”。
另外,還需要考慮模擬仿真環境對隨機激勵生成器的開發需求:(1)靈活方便地對內存空間進行劃分。內存空間的分配和使用是模擬仿真環境的一個重要方面,項目不同使用方式也可能不同,同一個項目也會發生變化,以此要求隨機激勵生成器應能夠根據仿真環境靈活方便地對內存空間進行劃分。(2)應滿足處理器的復雜初始化需求。這包括頁表的創建、寄存器的初始化、核心內部控制寄存器的初始化,甚至芯片內部的I/O寄存器初始化等等。(3)生成的激勵目標文件最好為二進制格式,應該包含激勵中要運行的配置、指令和各種數據信息。(4)能夠方便查看生成的激勵的反匯編結果。
除了首先要滿足以上這些通用需求外,本文在開發隨機激勵生成器的時候要還重點考慮生成器以及在其上開發的測試庫的通用性和繼承性,力求使其能夠適用于多種不同架構處理器的開發,使得已開發測試庫能直接或經過重構后用于多款不同處理器的研發,從而能夠充分繼承之前的驗證成果,縮短處理器驗證周期,提高驗證效率。
本文激勵生成器KIG(Knowledgeable Instruction Generator)是一款基于約束求解的處理器偽隨機激勵生成器,采用Specman E語言設計實現。Specman E提供了強大的約束分析引擎和偽隨機發生器,稱為“IntelliGen”,能夠分析復雜約束條件,產生各種偽隨機數據類型和數據結構。SystemVerilog語言也是各家EDA公司都支持的成熟語言,與Specman E屬于同一類語言,也可以用于建立偽隨機激勵生成器。
為了適應處理器設計變化的需求,本文激勵生成器采用了基于模型和測試庫的、自底向上的層次化設計方法。如圖1所示,共分6個層次,自底向上分別為基礎結構層、單元模型層、單元樹層、測試知識庫、測試序列庫和測試情景。

Figure 1 Bottom-up design method of processor test generator development圖1 自底向上的處理器激勵生成器設計方法
激勵生成器的層次化設計遵循以下原則:(1)基礎結構層和單元模型層是激勵生成器的底層定義,由開發人員維護,不允許用戶修改;(2)“單元樹”層是激勵生成器的中間層,是生成器與用戶的交界面,也由開發人員維護,但為驗證測試人員提供了對單元樹的組織結構進行變更的接口;(3)測試知識庫主要由經驗豐富的驗證工程師開發和維護;(4)測試序列庫是完全開放的,所有驗證工程師都可以根據需求定義自己的庫,通常會按照驗證側重點分類,但這個分類是指導性的,因為處理器驗證的復雜性往往使得很多測試序列是綜合類型的;(5)測試情景中定義了全局約束和各個處理器核心與序列庫的調用關系。
為了保證測試程序的可重用性,測試情景只調用測試序列,不在測試情景中編寫具體的用戶程序。全局約束是指對激勵生成器內全局結構的約束,可以施加于測試情景之下的各個層次。如對基礎結構層的處理器結構信息模型和仿真環境模型的全局約束,通常會為每款處理器定義一個單獨的配置文件。在多核Cache一致性的測試情景中,可通過定義全局的共享規則約束來控制不同核心對Cache的共享情況,在本文的3.6節會具體展開說明。測試情景與測試序列庫的不同之處在于,測試情景區分單核測試和多核測試,而測試序列庫則不區分單多核測試。圖2是KIG的圖形界面,用戶可以使用該界面配置激勵生成約束,并自動生成測試情景。

Figure 2 GUI of KIG processor pseudo-random test generator圖2 KIG偽隨機激勵生成器界面
這種層次化設計方法使得當處理器設計或者仿真環境變化時,我們只需要修改基礎結構層、單元模型層或者是單元樹層的定義,就可以保證上層的測試知識庫、測試序列庫保持不變。而由于測試情景與設計的密切相關性,比如參與測試的處理器核心數發生變化,測試情景也必須隨之變化,但由于測試情景僅僅包含核心對序列庫調用關系和全局約束,并不包含用戶編寫的測試代碼,容易修改和繼承,甚至于在用戶指導下進行批量轉換。同理,基于所有已開發的測試序列庫,還可以定義各類全局約束組合,批量重構新的測試情景,大批量產生偽隨機測試激勵,使已有測試序列庫發揮更大作用。
處理器單核心結構模型中描述了部分處理器內核的結構和微結構信息,例如Cache組成結構、結構寄存器、地址代換緩沖TLB(Translation Lookaside Buffer)、內部控制和狀態寄存器信息等等。本文在處理器單核結構模型的建模中主要采用了以下三種建模方法:
(1)結構信息參數化建模法。如Cache的組成結構建模就只需要建立各級Cache的信息檔案,包括容量、相聯度、Cache塊大小等。有了這些信息,后續編寫測試激勵時可以調用這些變量控制激勵的生成,當處理器設計改變時,只需要根據新的處理器結構對這些參數重新配置即可。本文在對處理器結構建模時,Cache結構、TLB結構、物理寄存器資源數量等都采用了這種建模方法。
(2)資源池建模法,典型的如寄存器資源。在處理器驗證中,指令序列的寄存器相關性測試是處理器流水線驗證中的一種必測情形;另一種情形是某些寄存器在一段時間內用于保存特定數據,比如訪存地址,而在序列隨機混合時不希望這個寄存器內容被其它隨機生成的指令沖掉。以上兩種情形需要激勵生成器提供一種機制對寄存器資源的使用進行控制。本文采用資源池建模法,在激勵生成器中設置全局的free和lock的寄存器資源列表,free列表中存放著待分配的空閑寄存器,lock列表中存放著已分配的寄存器,free列表中的寄存器允許隨機讀寫,而lock列表中的寄存器不允許被隨機讀寫。如果不希望指令序列的某些寄存器被其它指令序列更改,可以申請寄存器分配,分配成功后,該寄存器會被放入lock列表,并且從free列表中刪除,其他隨機產生的指令應該避免使用lock列表中的寄存器作為目標寄存器。這種建模方法不但解決了硬件資源的使用沖突問題,而且還便于控制指令序列在使用硬件資源時的相關性,如下偽代碼所示:
allocated_reg_list=int_reg.reg_alloc(參數:寄存器個數);
do add inst keeping {
.src0 inint_reg.free_list();
.src1 inint_reg.lock_list();
.desinallocated_reg_list; /*目標寄存器指定為分配的寄存器*/
};
do sub inst keeping {
.src0 inallocated_reg_list; /*源寄存器使用add指令的目標寄存器*/
.src1 inint_reg.free_list();
.desinint_reg.free_list(); /*這個約束保證了lock寄存器不會被沖掉*/
};
add指令目標寄存器使用分配得到的寄存器資源,sub指令源寄存器也使用分配得到的寄存器資源,則sub與add指令之間建立了一種先寫后讀的相關性關系,sub指令作為一種隨機指令將目標寄存器約束為free列表,同時也避免沖掉其它序列已經分配使用的寄存器。
(3)行為模型建模法。對處理器某些結構的建模必須實現該結構的行為功能才能控制特定激勵序列的生成,比如地址代換緩沖TLB的建模,生成TLB測試激勵時,TLB的模型必須支持用戶對TLB頁表條目的約束控制,如頁面權限設置、頁面粒度等,但用戶不能控制物理頁面的分配,這部分功能必須由激勵生成器實現。
處理器仿真環境的一般構成如圖3所示,主要由被測設計DUT(Design Under Test)、內存模型(Memory Model)、指令集模擬器ISS(Instruction Set Simulator)、設計監測(Monitor)及結果檢查模塊(Checker)組成。仿真環境主要有三大功能:支持DUT的引導和運行、支持測試激勵的加載和內存空間管理,以及支持運行結果的檢查比較。

Figure 3 Simulation environment of processor verification圖3 處理器仿真驗證環境構成圖
由于處理器設計不同,仿真環境也可能不同,尤其是指令集模擬器的內存空間管理發生變化時,必然會影響原有測試程序的重用,另外程序的運行初始化也會因設計功能改變而變化,處理器的架構改變,比如從單核到多核或者眾核,測試激勵的組成形式也必然發生變化,這些都會影響到激勵生成器的可重用性。因此,在激勵生成器設計時應該綜合考慮以上需求,將這些數據信息建模到仿真環境模型中,使得仿真環境與激勵生成器之間的接口協議規范化和參數化,從而實現偽隨機激勵生成器跨芯片設計環境的可重用。
為適應處理器設計和仿真環境的變化,對仿真環境的建模主要針對測試激勵加載、內存空間管理和程序運行初始化功能。
(1)測試激勵加載建模。偽隨機激勵生成器生成的測試激勵既可以選擇生成匯編源代碼,也可以選擇直接生成目標碼。為了方便隨機生成指令字段中的各個域,簡化仿真環境,偽隨機激勵生成器通常會直接生成目標碼。為了適應不同處理器架構下測試激勵的生成和加載模式,同時從偽隨機測試的需求分析,偽隨機激勵生成器生成的目標碼格式可以自由定義,不需要與編譯器生成的目標碼格式一致。這樣做的好處是,當處理器架構或指令集改變時,偽隨機驗證不需要依賴于編譯器、匯編器等軟件開發的進度,偽隨機激勵生成器與指令集模擬器接口一致,自成一體。自定義目標碼的格式只需要包含一些基礎段即可,如頁表段、指令正文段、偽隨機數據段、用戶數據段等等,如圖4所示。

Figure 4 File head of a customized pseudo-random test object圖4 自定義激勵目標碼文件頭信息
(2)內存空間管理建模。在無操作系統的仿真環境下,內存空間的管理主要通過指令集模擬器實現,通過定義不同類型的內存空間來實現一個滿足驗證要求的裸機運行環境。內存空間的類型包括:①測試程序數據段,其內存空間劃分與偽隨機目標碼的功能段劃分相對應。②頁表數據。頁表是一類特殊的數據,在有操作系統管理的環境下,頁表數據是動態產生的,而在偽隨機測試環境下,頁表數據則是由激勵生成器在激勵生成過程中生成的。③特權程序。特權程序是處理器在特定情況下執行的固件代碼,這部分數據一般不會修改,但也可以根據測試需要做修改。④特殊功能的地址空間,比如鎖測試程序中定義的鎖和臨界資源的內存地址。偽隨機激勵生成器應該使用參數定義上述內存空間,當指令集模擬器內存空間管理發生變化時,根據新的內存空間定義、修改激勵生成器的對應參數,即可使原有測試庫符合新的仿真環境內存空間定義。
(3)程序運行初始化功能建模。由于處理器設計的需要,通常在啟動運行階段,處理器會執行一段特定程序完成對設計的必要初始化。通常在偽隨機驗證中,為了測試處理器的各種運行模式和參數配置,也需要對這段程序進行約束和隨機。因此,激勵生成器應該定義初始化程序段以滿足處理器設計變化時對初始化程序的變更需求。
單核心和仿真環境的結構建模是可配置多核處理器建模的基礎。本文在實現中采用了UVM(Universal Verification Methodology)方法學[12],將與單核心相關的設計結構和環境信息獨立封裝,可根據多核處理器核心數量配置單核模型實例化的個數,并通過采用Virtual Sequence[12]技術將N個核心的Sequence Driver集中控制,如圖5所示。

Figure 5 Scalability of multi-core processor model composed of single-core models圖5 可配置多核處理器模型結構圖
多核處理器執行程序的指令空間可以分為共享空間和私有空間,所謂共享空間即各個核心共享內存的一份指令數據,私有空間即各個核心的指令數據是地址分開的。這兩種方式在實際軟件應用中都是存在的,從驗證功能的完備性考慮,激勵生成器理論上應該支持這兩種實現方式。但是,激勵生成器的設計應該從功能驗證的需求出發,在滿足驗證需求的前提下盡量簡化測試激勵模型,以提高激勵生成效率。就這點而言,驗證需求的本質是如何滿足不同的核執行指令序列的相關性要求。這里的相關性要求包括兩個方面:一是指令空間上的地址相關性,二是指令序列中訪存操作的地址相關性。訪存操作的地址相關性驗證,即多核處理器Cache一致性實現的功能驗證,其重要性不言而喻,必須提供高效的測試機制。而指令空間上的地址相關性,當程序段多核共享時,不同核心指令Cache中有共享指令數據的只讀副本,由于指令空間通常是只讀的,因此這種指令相關性功能比較簡單。驗證環境中的固件程序通常采用這種實現方式,即可滿足這部分的功能驗證。特殊情況下也存在某一核心生產指令,其它核心消費指令的使用模式,這是一種特殊的編程模式,本質上也是訪存操作地址的相關性,可以轉換成數據地址空間上的相關性來實現。
基于上述分析,多核版本的激勵生成器采用了私有空間方式實現每個核心的指令空間,主要考慮到指令空間地址相關性并非處理器功能驗證的重點難點,且有其他測試手段補充驗證,而私有空間實現方式可以為每個核心提供差異化的測試序列,更具有靈活性。由于每個核心的測試序列不同,測試激勵的大小各不相同,為了解決這個問題,在實現多核版本時,采用不同核心串行生成測試激勵的方法,每個核心所需要占用的內存空間通過動態計算得到,每個核心的測試激勵單獨控制。在多核測試時,指令序列中訪存操作的地址相關性更為重要,因為涉及到不同核心之間內存共享如何實現。本文通過建立訪存地址模型和定義全局的共享規則,約束底層指令序列中訪存地址的生成來實現,詳見3.6節。
指令集是激勵生成器的用戶接口,指令集的定義方式直接關系到偽隨機激勵的編寫效率,本文提出了一種“指令樹”建模方法,實踐中取得了良好效果。
指令樹建模方法,顧名思義,就是將指令集看作是一棵樹,如圖7所示。“樹葉”為指令單元,如圖中的“SUBW”和“SUBL”。指令單元主要定義了指令的格式和各種屬性信息,“樹枝”為指令組,由一組特定分類的指令單元組成,如圖中的“減法指令”;“樹枝”可以分為支干和主干,低級指令組“支干”可以組成更高一級的指令組“主干”;最頂級的就是“樹根”,樹根包含了所有指令定義?!皹涓伞惫濣c代表的就是指令單元的各類屬性,指令單元的屬性定義越多,則“指令樹”的層次劃分越多,偽隨機控制就越精細。

Figure 6 Organization of instruction set tree圖6 指令樹組織結構圖
指令樹建模法有以下優點:(1)能有效避免指令集調整對原有測試序列的影響,實現原有測試知識庫、測試序列不做修改地繼承;(2)“樹形結構”有效地組織了隨機元素,使得在激勵編寫中能夠靈活地指定隨機方向——“樹枝”“樹干”,并且控制不同方向上的權重;(3)“樹形結構”能夠在Excel表中清楚地表達指令集的隨機元素,使得激勵編寫人員能夠快速地掌握激勵編寫技術,提高了激勵開發效率,并且文檔具有很強的繼承性。
隨著半導體工藝的發展,高性能處理器集成的核心數量越來越多,運算性能不斷提升,而存儲器帶寬的提升相對較慢,為了解決“存儲器墻”問題,高性能處理器通常采用多層次存儲器、多條訪存流水線、硬件預取等設計[13],再加上復雜的片上Cache一致性協議,這些都對處理器訪存驗證提出了很高的要求。本文提出一種面向多核處理器驗證的多維訪存地址建模方法,可降低多核訪存激勵編寫的難度,同時便于控制測試激勵的隨機度,提高多核處理器的驗證效率。
一般的訪存激勵中僅僅把訪存地址看作一個一維的數據,而如何選擇一個合適的訪存地址以達到測試目的,則需要激勵編程人員不僅對處理器的訪存流水線設計非常的清楚,而且還需要對仿真環境的內存模型空間限制很清楚,一旦編寫多核Cache一致性測試激勵,還必須仔細考慮多個核心對內存地址的共享方式。傳統的訪存激勵編寫模式費時費力,對編程人員要求很高,而一旦處理器設計變化,原有的測試激勵很可能失效。
通過對處理器的訪存測試情景進行分析,可以看出,訪存地址的重要性在于處理器中各種訪存資源的使用均與訪存地址相關,例如:(1)對Cache資源的使用?,F代處理器的Cache設計一般采用虛索引虛標識VIVT(Virtual-Indexed,Virtual-Tagged)、虛索引物理標識地址VIPT(Virtual-Indexed,Physical-Tagged),或者物理索引物理標識PIPT(Physical-Indexed,Physical-Tagged)[14,15],無論采用哪種方式,內存副本在Cache中的狀態轉換都與地址序列有關,如Cache的命中、淘汰、預取、裝填、不同核心共享讀寫等等。(2)對地址代換緩沖TLB資源的使用。TLB的裝填、命中、淘汰、刷新等操作均是通過頁面索引不同、頁面粒度不同的虛地址序列實現的。(3)對I/O寄存器的資源使用。(4)多核共享存儲資源。狹義的共享是指不同的核心訪問的存儲器地址有交疊,而在處理器的硬件設計中,Cache數據是以Cache塊為單位管理的,也就是說,只要不同核心訪問的地址在同一Cache塊內,即使地址沒有交疊也是共享,這里稱為“偽共享”,實際在驗證當中為了避免參考模型與設計行為不一致,一般采用“偽共享”的測試方法。
通過上述分析,可以根據訪存地址與訪存資源使用的對應關系建立多種類型的多維訪存地址模型。圖7是多核共享訪存地址模型的定義示例,“塊內索引”是指一個Cache塊內的地址索引,“行索引”對應Cache行的索引地址,“共享規則”域實際上是從TAG標志地址分離出來的幾位,用于定義多核共享Cache塊的各種情況。

Figure 7 Bit field definition of multidimensional memory address
圖7 多維訪存地址位域定義
例如編寫一個四核處理器的存儲共享程序,如下所示代碼中定義了兩個共享規則全局約束
R
0和
R
1。
R
0規則定義:TAG標志隨機8個,行索引隨機1個,這些Cache塊由核心0、1、2共享,如果Cache是4路組相聯結構,指定行索引1個,不同的TAG有8個,那么在測試中既可以產生多核共享,又可以產生本核心的Cache擠占淘汰。
//在全局測試情景中定義共享規則名稱:
extendshare_rule_t[R0,R1];
/*R0規則定義:TAG標志隨機8個,行索引隨機1個,核心0、1、2共享;*/
add_global_share_rules(R0,TagNum=8,IndexInum=1,core_list=(0, 1, 2));
/*R1規則定義:TAG標志隨機4個,行索引隨機2個,核心0、1、2、3共享*/
add_global_share_rules(R1,TagNum=4,IndexInum=2,core_list=(0, 1, 2,3));
/*在序列庫中的使用方式如下,序列庫中的序列無需知道在哪個核運行、有哪些共享規則*/
gen MEM addr_var keeping {
.ruleinenv.global_share_rules[my_core_name]; /*隨機從本核相關的共享規則中生成共享地址*/
};
這種實現方式將關鍵訪存流水線結構信息,通過對訪存地址的多維建模施加到測試激勵中,不但大大降低了測試激勵的編寫難度,而且便于測試序列庫跨處理器結構重用。
設置測試庫的目的是為了對測試程序進行分層和分類管理,方便測試程序的查找、共享和維護,測試庫分為兩個層次:測試知識庫和測試序列庫。
測試知識庫的概念就是由對處理器結構和功能非常了解的資深驗證工程師開發出針對處理器各個測試方面的測試序列和約束條件,并內置于激勵生成器,測試知識庫的約束會默認施加給測試情景序列,驗證人員也可以根據需要,在自己的測試情景序列中重載某些測試約束,例如加大某類指令的權重,或是控制邊界數據的比例;測試知識庫的序列一般是短小精悍,具有完全的可重用性,能覆蓋處理器測試中的特定測試情況。測試知識庫還具有開放性的特點,能夠在處理器驗證過程中,不斷地添加、完善,逐漸累積,從而有效緩解了處理器測試空間巨大與測試激勵編寫效率之間的矛盾。
測試序列庫的層次在測試知識庫之上,由一般測試人員編寫和維護,可以調用測試知識庫的程序,也可以使用地址樹、指令樹以及處理器模型和環境模型的接口編寫測試程序,測試序列庫的開發由處理器驗證需求驅動,在處理器功能驗證過程中不斷積累完善。為了便于使用管理,測試序列庫通常會按照驗證側重點分類,如訪存類、運算類、轉移預測類、異常故障類等等。
本文實現的偽隨機激勵生成器KIG目前已成功應用于5款不同型號處理器的研發,這些處理器的芯片架構不同,指令集也有差異。為了說明應用效果,我們選取了兩款應用了KIG激勵生成器的處理器驗證和一款采用一般方法實現的激勵生成器的處理器驗證進行對比分析。這三款處理器分別是:(1)16核處理器A,一款較早開發的多核處理器,處理器核心指令集和芯片架構有較大變動,核心微結構變化較小,采用了一般的指令級建模偽隨機激勵生成器完成驗證;(2)4核處理器B,處理器核心微結構和指令集均有較大變化,核心由原來的2譯碼3發射變為4譯碼7發射,性能和復雜度均有較大提高,采用了本文開發的KIG激勵生成器驗證;(3)16核處理器C,處理器核心微結構和指令集相對B均有部分變化,芯片架構變動較大,也采用本文開發的KIG激勵生成器驗證。
對這三款處理器驗證效果進行對比分析的主要指標為覆蓋率驗證周期和錯誤收斂趨勢。這里的“覆蓋率驗證周期”是指在處理器全片代碼合攏,驗證環境創建完成,達到基本功能正確性后,開始啟動代碼和功能覆蓋率驗證到雙覆蓋率達100%的驗證階段。
從圖8中可以看到,16核處理器A由于指令集和芯片架構有較大變化,而之前用的激勵生成器雖然采用了基于庫的分層設計方法,但是由于不是同時采用基于模型和庫的方法建模實現,導致了之前積累測試激勵大部分都無法使用,修改的工作量巨大,因此覆蓋率驗證花了近6個月才完成。4核處理器B雖然核心微結構和指令集變化非常大,KIG激勵生成器也是第一次投入使用,但是基于模型和庫的設計方法提高了測試激勵編寫效率,尤其是基于模型的實現方法降低了對驗證人員工作經驗的要求,許多新入職驗證人員也可以開發出高質量測試激勵,從而使得覆蓋率收斂速度大幅提高,達到100%覆蓋率用了不到4個月時間,相比之前周期縮短了30%以上。16核處理器C同樣采用了KIG激勵生成器,雖然微結構、指令集和芯片架構都有調整,但是由于KIG激勵生成器可以迅速重用和重構之前的1 500多個測試序列,處理器C在保證基本正確性后用了僅一個月覆蓋率就已經接近80%,充分體現了KIG測試庫跨芯片重用帶來的驗證效率提升。

Figure 8 Coverage growth trend of the three processors圖8 三款處理器的覆蓋率收斂趨勢圖
圖9是這三款處理器的錯誤收率趨勢圖。從圖中可以看到:采用KIG驗證的4核處理器B錯誤收斂速度明顯快于基于普通激勵生成器的16核處理器A,16核處理器C繼承了4核處理器B的KIG測試庫,在開始2個月的驗證中錯誤收斂速度更快;從錯誤發現總數看,處理器核心指令集和微結構的大變化對處理器正確性驗證會帶來更大的挑戰,而KIG激勵生成器在這方面的驗證效率非常高;從錯誤收斂周期看,采用KIG激勵生成器的激勵發現錯誤效率高,測試激勵庫的可繼承性強,這兩方面都能夠有效縮短錯誤收斂周期;另外,16核處理器C中后期的錯誤收斂趨勢變得比較平緩,從具體錯誤類型分析,主要是針對造錯流程和芯片設備外接口的驗證錯誤收斂相對較慢,后期KIG激勵生成器還可以針對這方面的驗證開展進一步工作。

Figure 9 Sum of bugs growth trend in the three processors’ verification圖9 三款處理器驗證中的錯誤收斂趨勢
綜上對比分析,本文激勵生成器的設計方法能夠高效地根據處理器芯片架構、微結構和指令集對激勵生成器進行配置,快速部署應用,尤其是測試集合能夠重用和重構,大大減少了測試激勵的開發量,在芯片開發初期就能夠快速發現將近一半的錯誤,從而為FPGA原型驗證和硬件仿真器驗證的提早展開創造了有利條件,不僅提高了處理器芯片的驗證效率,而且縮短了軟硬件協同驗證和軟件的研發周期。
本文通過對處理器設計和驗證的需求進行深入分析,提出了基于模型和庫的六層激勵生成器結構,并詳細闡述了激勵生成器設計中有關模型和庫的實現方法,其中指令樹建模方法和多維訪存地址建模方法是解決處理器研發中測試集合失效問題的關鍵技術?;诖朔椒ǎ疚脑O計實現了基于模型和庫的國產處理器偽隨機激勵生成器KIG,現已經成功應用于多款不同架構的處理器驗證,完全實現了測試集合的繼承和持續豐富,達到良好的驗證效果。
[1] Bryant R E.A methodology for hardware verification based on logic simulation[J].Journal of the ACM (JACM),1991,38(2):299-328.
[2] Taylor S,Quinn M,Brown D,et al.Functional verification of a multiple-issue,out-of-order,superscalar alpha processor—the DEC Alpha 21264 microprocessor[C]∥Proc of the 35th Design Automation Conference(DAC’98),1998: 638-643.
[3] Zhang Hang, Shen Hai-hua.Function verification of Godson2 processor[J].Journal of Computer Research and Development,2006,43(6):974-979.(in Chinese)
[4] Schubert K-D,Roesner W,Ludden J M,et al.Functional verication of the IBM POWER7 microprocessor and POWER7 multiprocessor systems[J].IBM Journal of Research .& Development,2011,55(3): 10-17.
[5] Zhu Ying, Chen Cheng,Li Yan-zhe,et al.Creation of FPGA verification platform for a high performance multiple-core microprocessor[J].Journal of Computer Research and Development,2014,51(6): 1295-1303.(in Chinese)
[6] Ludden J M,Roesner W,Heiling G M,et al.Functional verification of the POWER4 microprocessor and POWER4 multiprocessor systems[J].IBM Journal of Research .& Development,2002,46(1):53-76.
[7] Wagner I, Bertacco V, Austin T. StressTest: An automatic approach to test generation via activity monitors [C]∥Proc of the 42nd Design Automation Conference,2005:783-788.
[8] Fournier L,Arbetman Y,Levinger M.Functional verification methodology for microprocessors using the genesys test program generator: Application to the x86 microprocessors family[C]∥Proc of Design Automation and Test in Europe (DATE 99),1999:434-441.
[9] Aharon A,Dave G,Levinger M,et al.Test program generationfor functional verification of power PC processors in IBM[C]∥Proc of ACM/IEEE 32nd Design Automation Conference,1995:279-285.
[10] Lichtenstein Y,Malka Y,Aharon A.Model-based test generation for processor design verification[C]∥Proc of Innovative Applications of Artificial Intelligence (IAAI),1994:83-94.
[11] Zhang Xin, Huang Kai, Meng Jian-yi, et al.Multi-layer random stimulus strategy for microprocessor verification[J].Application Research of Computers,2010,27(4): 1284-1288.(in Chinese)
[12] Accellera. Universal verification methodology 1.1 user’s guide[M].California:Cadence Design Systems Inc,Mentor Graphics Corp.,Synopsys Inc.,2011.
[13] Hu Xiang-dong, Yang Jian-xin,Zhu Ying.Shenwei-1600: A high-performance multi-core microprocessor[J].Scientia Sinica Informationis,2015,45(4):513-522.(in Chinese)
[14] Zhang Chen-xi, Wang Zhi-ying, Zhang Chun-yuan, et al.Computer architecture[M].3rd Edition. Beijing: High Education Press,2006.(in Chinese)
[15] David P,John H.Computer architecture: A quantitative approach[M].4th Edition.San Francisco: Morgan Kaufmann Publishers,2006.
附中文參考文獻:
[3] 張珩,沈海華.龍芯2號微處理器的功能驗證[J].計算機研究與發展,2006,43(6):974-979.
[5] 朱英,陳誠,李彥哲,等.一款高性能多核處理器FPGA驗證
平臺的創建[J].計算機研究與發展,2014,51(6):1295-1303.
[11] 張欣,黃凱,孟建熠,等.一種面向微處理器驗證的分層隨機激勵方法[J].計算機應用研究,2010,27(4):1284-1288.
[13] 胡向東,楊劍新,朱英.高性能多核處理器申威1600[J].中國科學:信息科學,2015,45(4):513-522.
[14] 張晨曦,王志英,張春元,等.計算機系統結構[M].第三版.北京:高等教育出版社,2006.