今天別的先不聊，就單從代碼習(xí)慣出發(fā)聊聊SystemVerilog編碼層面提速的若干策略。

本篇的主體策略來自Cliff Cummings和其團(tuán)隊(duì)多年以來得出的一些研究結(jié)論，所展示的策略主要偏重于定性分析，而非定量分析，偏重結(jié)論而非詳細(xì)的理論論述。如果大家感興趣，可以自己設(shè)計(jì)仿真實(shí)驗(yàn)進(jìn)一步定量分析，或深入查閱文獻(xiàn)資料深究原理。

值得一提的是，本文雖偏重定性分析和結(jié)論擺出，但是這些結(jié)論還是具有很不錯(cuò)的價(jià)值，例如對(duì)SystemVerilog仿真速度的編碼層面優(yōu)化方法提供了一些思路和認(rèn)知，對(duì)SystemVerilog代碼風(fēng)格建立提供了一個(gè)新的觀察視角，當(dāng)你在代碼提速優(yōu)化“山窮水盡”之時(shí)，也許因?yàn)槟硹l“柳暗花明”。

好了，廢話不說了，請(qǐng)出干貨：

1.頻繁的函數(shù)/任務(wù)調(diào)用會(huì)增加開銷

比如：用foreach遍歷方式計(jì)數(shù)（foreach有內(nèi)置函數(shù)），不如單獨(dú)的計(jì)數(shù)器！如下代碼：

這樣寫比較慢：

這樣寫比較快：

對(duì)于簡(jiǎn)單調(diào)用，編譯器可以將函數(shù)/任務(wù)內(nèi)聯(lián)以避免堆棧幀操作，但復(fù)雜調(diào)用因?yàn)榫幾g器性能考慮原因通常不會(huì)內(nèi)聯(lián)，每個(gè)函數(shù)/任務(wù)都將數(shù)據(jù)引用或完整的數(shù)據(jù)副本推送到調(diào)用堆棧，并處理任何指定的返回。如此就會(huì)增加仿真時(shí)間了。如果這個(gè)函數(shù)/任務(wù)本身又被循環(huán)掉用，時(shí)間就會(huì)浪費(fèi)更多！

上面的反例代碼，通過foreach遍歷來統(tǒng)計(jì)mad_q中的元素?cái)?shù)，每次都需要掉用一次內(nèi)部的內(nèi)置函數(shù)，將會(huì)慢于一個(gè)獨(dú)立的計(jì)數(shù)器！

2.計(jì)算表達(dá)式、引用請(qǐng)“逃出”循環(huán)

例2.1：循環(huán)條件中不要帶計(jì)算，每次循環(huán)都會(huì)計(jì)算一次

這樣寫比較慢：

這樣寫比較快：

例2.2：和循環(huán)因子無關(guān)的計(jì)算應(yīng)在循環(huán)外計(jì)算好

這樣寫比較慢：

這樣寫比較快：

例2.3：引用不要和循環(huán)沾邊

這樣寫比較慢：

這樣寫比較快：

這個(gè)例子比較慢的代碼把例如comms.proto.pkt….的引用帶入了循環(huán)里。

在硬件世界中，可以預(yù)先計(jì)算分層引用，因?yàn)檫@些引用在運(yùn)行時(shí)是靜態(tài)的。在systemverilog testbench中，引用通常是同時(shí)遍歷類實(shí)例層次結(jié)構(gòu)和動(dòng)態(tài)類型，所有這些都可以在仿真運(yùn)行期間更改。因此，模擬器必須遍歷所有引用才能獲得數(shù)據(jù)，這顯然會(huì)降低速度。

3.對(duì)于條件的相關(guān)編碼長點(diǎn)兒心吧

例3.1：簡(jiǎn)單的條件短路

第一行if中通過“或”聯(lián)系起來的條件，當(dāng)其中term1為1時(shí)，則后續(xù)不用判斷則可以得出if條件整體成立。

同理第二行if中通過“與”聯(lián)系起來的條件，當(dāng)其中term1為0時(shí)，則后續(xù)不用判斷則可以得出if條件整體不成立。

所以這樣寫這個(gè)條件會(huì)比較快，例如：

if（最高頻率的條件 || 次高頻率的條件 || 最低頻率的條件），把最高頻率的寫在最前面。

例3.2：能條件成立后才進(jìn)行計(jì)算的，就不要著急放到前面算。

比如下面這個(gè)例子，data的計(jì)算是調(diào)用了randomize()這個(gè)函數(shù)，但是用這個(gè)值是在一個(gè)If(live==TRUE)條件成立之后才用的！假如條件沒成立，那就是沒用上，沒用上前面是不白算了？自然就浪費(fèi)資源了?。ㄎ覀兦懊嬷v循環(huán)的時(shí)候說該算的提前算好，看到條件這里的時(shí)候我們可能要多想想了，原來不是啥都趕前面算就好啊，哈哈）

例3.3：UVM平臺(tái)中妙用uvm_report_enabled()函數(shù)作為條件來優(yōu)化。

如下例，如果打印詳細(xì)級(jí)別設(shè)置為UVM_DEBUG或高于UVM_DEBUG，則觸發(fā)消息打印。

例3.4：再來一個(gè)UVM平臺(tái)中玩好條件的案例，monitor或者driver進(jìn)行port傳遞時(shí)，以port的size()為條件，減少不必要的打數(shù)據(jù)包的次數(shù)。

4.連接處logic的語義顯式聲明wire，可以折疊為同一對(duì)象，加快仿真速度（RTL or TB）

這樣寫比較慢：

這樣寫比較快：

SystemVerilog中的logic類型，它可以有wire線存儲(chǔ)或var變量存儲(chǔ)，如果沒有顯式聲明，則存儲(chǔ)類型由仿真器根據(jù)上下文確定。

別小看這個(gè)類型，對(duì)仿真差別很大哦，如果是wire型，仿真器可以折疊為同一對(duì)象以獲得更高的仿真速度，但是變量卻不能！

因?yàn)閘ogic類型的語義除了在input、inout之外的所有情況下全都默認(rèn)為變量存儲(chǔ)！所以你的代碼有時(shí)候可能仿真正確，但不知道為啥比想象中的慢！

如上例子中A2.y、A2.X1.y和A2.X1.T1.y是不同的，粗體wire聲明允許將它們折疊為單個(gè)對(duì)象。（當(dāng)然上例子中input本身默認(rèn)為wire類型不需要顯式聲明，但是全部顯式聲明更加清楚，這個(gè)代碼風(fēng)格更好）

5. 在“向量”上直接操作比操作bit更快

這樣寫比較慢：

這樣寫比較快：

如上例32bit的a_t、c_t，可以看作32個(gè)1bit的變量組成的“向量”。對(duì)于這個(gè)“向量”直接操作會(huì)快于對(duì)其32個(gè)1bit循環(huán)操作。

順便一提，上面的反例中，除了位操作，而且效率低下的示例使用了一個(gè)generate語句，它創(chuàng)建了一個(gè)靜態(tài)層次結(jié)構(gòu)。這樣的跨層次結(jié)構(gòu)的問題，仿真器會(huì)進(jìn)行優(yōu)化，但是對(duì)于復(fù)雜的問題，往往不能做到很好的優(yōu)化，會(huì)變成隱藏的性能問題。

6.盡量用ref，少傳遞復(fù)雜數(shù)據(jù)結(jié)構(gòu)

ref會(huì)直接對(duì)目標(biāo)方法的內(nèi)存進(jìn)行操作，這樣便節(jié)省了資源，尤其是對(duì)于很多復(fù)雜數(shù)據(jù)結(jié)構(gòu)例如具有數(shù)百個(gè)字段的結(jié)構(gòu)體、或具有數(shù)百個(gè)元素的隊(duì)列、動(dòng)態(tài)數(shù)組、聯(lián)合數(shù)組等。其實(shí)，很多時(shí)候函數(shù)只需要擁有讀取大型數(shù)據(jù)對(duì)象的訪問權(quán)限即可，根本不會(huì)寫入它。

7.動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)，不要濫用、想清楚再用

“動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)”如隊(duì)列、動(dòng)態(tài)數(shù)組、聯(lián)合數(shù)組是常見性能問題的來源，不要濫用。SystemVerilog和大多數(shù)具有這些類型的語言通常都是如此。

所以，盡可能使用靜態(tài)數(shù)組而不是動(dòng)態(tài)數(shù)組。即使數(shù)組長度有少量變化，最好指定靜態(tài)數(shù)組稍大一些，而不是承擔(dān)動(dòng)態(tài)數(shù)組的開銷（內(nèi)存占用空間和垃圾收集時(shí)間）。比如可能有2--10個(gè)int型的元素，直接定義和使用“int A[10];”，或者更大點(diǎn)“int A[12];”來存儲(chǔ)元素，而不是直接定義使用動(dòng)態(tài)數(shù)組“int A[ ];”來動(dòng)態(tài)分配空間。

除此之外，動(dòng)態(tài)數(shù)組和隊(duì)列有各自適合的場(chǎng)景，他們都可以完成對(duì)方的功能，但是不要隨意混用，否則都會(huì)有不好的性能。動(dòng)態(tài)數(shù)組最適合查找，隨機(jī)插入/刪除操作，隊(duì)列最適合自動(dòng)調(diào)整大小的前后操作，仿真器具有不同的內(nèi)部表示來優(yōu)化他們各自的操作，所以盡量讓他們?nèi)ズ线m自己的“崗位”。

8.能用單個(gè)對(duì)象，不要多new

比較慢的寫法：

比較快的寫法：

低效的內(nèi)存可能導(dǎo)致嚴(yán)重的cache miss，堆管理開銷和垃圾收集開銷，這些都可能難以通過分析發(fā)現(xiàn)，所以養(yǎng)成好的代碼習(xí)慣，例如盡量少new不必要的對(duì)象、不是必需情況下盡量少深拷貝動(dòng)態(tài)對(duì)象。

9.可以考慮靜態(tài)類代替動(dòng)態(tài)類

接著上一條，如果同一組類反復(fù)被分配內(nèi)存和釋放內(nèi)存，仿真器通過內(nèi)存管理反復(fù)循環(huán)，降低了仿真時(shí)間，而如果是靜態(tài)定義的類，仿真的整體內(nèi)存占用保持一致，從而執(zhí)行速度會(huì)變快！

10.簡(jiǎn)單異構(gòu)數(shù)據(jù)結(jié)構(gòu)能用結(jié)構(gòu)體就不要用類

很多人常常有種想法認(rèn)為class是基于面向?qū)ο笠氲母案呒?jí)”的封裝方式，結(jié)構(gòu)體好像更“l(fā)ow”一點(diǎn)，其實(shí)不然！單獨(dú)的類將需要堆管理并可能涉及垃圾收集，簡(jiǎn)單的struct（結(jié)構(gòu)體）不會(huì)，所以更快。簡(jiǎn)單異構(gòu)數(shù)據(jù)結(jié)構(gòu)能用結(jié)構(gòu)體就不要用類了吧。

11.接口中的“重”功能放在接口中而不是類中

這樣寫比較慢：

這樣寫比較快：

將接口“重”的功能放入接口而不是類中也更具仿真效率。

首先，因?yàn)楣δ芘c接口本身相關(guān)聯(lián)，可重用性更好。

其次，在接口上操作的類包含與接口相關(guān)聯(lián)的基本操作使接口的任何未來用戶都可以復(fù)制此基本代碼，但是通過virtual接口無法有效地引用它們。

12.減少動(dòng)態(tài)task或者function的喚醒

SystemVerilog仿真器是由事件驅(qū)動(dòng)的，它們?cè)诮o定時(shí)間點(diǎn)運(yùn)行的事件越多，運(yùn)行速度越慢。SystemVerilog中最常見的進(jìn)程應(yīng)該就是帶有敏感信號(hào)（如clk）的always塊來，正因如此常見，這個(gè)靜態(tài)進(jìn)程在所有仿真器中都進(jìn)行了高度優(yōu)化，但是，動(dòng)態(tài)task或者function（如DPI（或任何外部）功能，虛擬類任務(wù)/功能和虛擬接口任務(wù)/功能）的副作用可能會(huì)導(dǎo)致仿真器禁用優(yōu)化！這種情況，“坐著不如躺著”少喚醒最安全。就像前面例3.2條件的處理那樣，盡量減少他們的執(zhí)行，如下

值得一提的是，除了這樣還有一種玩法可以減少執(zhí)行次數(shù)：用iff，如下例子

13.對(duì)于UVM平臺(tái)中帶約束的隨機(jī)，盡量分解或簡(jiǎn)化

這樣寫比較慢：

這樣寫會(huì)快很多：

在上圖反例中，循環(huán)中對(duì)其相鄰對(duì)每個(gè)數(shù)組元素設(shè)置約束，假設(shè)100個(gè)元素，就相當(dāng)于必須同時(shí)求解100個(gè)約束。下面的代碼使用post_randomize，經(jīng)統(tǒng)計(jì)，可以將運(yùn)行時(shí)性能提高1000倍！

14.斷言的序列和屬性盡量避免使用局部變量

這樣寫比較慢：

這樣寫比較快：

雖然可能需要局部變量來操縱序列和屬性內(nèi)部的數(shù)據(jù)，但它們?cè)诜抡孢^程中增加了開銷。在可能的情況下，應(yīng)避免使用局部變量。

15.覆蓋率收集時(shí)，盡可能減少采樣事件

這樣寫比較慢：

這樣寫比較快：

上面第二段代碼之所以比第一段快，是因?yàn)楹喜⑹褂昧讼嗤录牟蓸舆^程，更少的coverage采樣事件可以減少仿真時(shí)間。

所以除此之外，盡量使用特定事件觸發(fā)器而不是諸如系統(tǒng)時(shí)鐘之類的通用事件來采樣覆蓋率、覆蓋組共享共同表達(dá)式等手段也可以減少仿真時(shí)間。

16. 可以使用宏加快循環(huán)計(jì)算

對(duì)于如下循環(huán)代碼，reverse()函數(shù)會(huì)在大量的數(shù)據(jù)點(diǎn)被掉用，每次調(diào)用reverse( ) 都需要?jiǎng)?chuàng)建可能影響緩存命中的堆棧幀，仿真速度會(huì)非常慢。使用REVERSE宏，就會(huì)使仿真更快。當(dāng)然宏過度使用會(huì)增加調(diào)試難度和內(nèi)存消耗。

結(jié)語

正如前文所說：“專輯發(fā)文順序與提速收益無關(guān)”，本篇的提效手段，對(duì)于代碼規(guī)模不大的驗(yàn)證業(yè)務(wù)，說實(shí)話并不是收益最大的提速方式，甚至有的收益難以感知，屬于“勒緊褲腰帶”的致富方式。但是“粒粒皆辛苦”，多條并用，積少成多，當(dāng)驗(yàn)證業(yè)務(wù)規(guī)模大的時(shí)候（除了芯片規(guī)模大之外還包括仿真數(shù)據(jù)量很大時(shí)，例如大數(shù)據(jù)量圖像視頻的壓測(cè)場(chǎng)景）你將獲得一個(gè)還不錯(cuò)的速度收益。

審核編輯：劉清