我們說的“提速”到底提的是什么時(shí)間？

1、驗(yàn)證仿真中的“3個(gè)時(shí)間”

在驗(yàn)證仿真過程中，我們腦中需要閃過至少3個(gè)概念：

墻上時(shí)鐘時(shí)間（wall clock time）

cpu時(shí)間（cpu time）

仿真時(shí)間（simulation time）

他們都是什么呢？

1.墻上時(shí)鐘時(shí)間（wall clock time）：

顧名思義，它是“掛在墻上的時(shí)鐘”的時(shí)間，這個(gè)時(shí)間也就是我們真實(shí)世界真正“走過的時(shí)間”。

你跑一個(gè)case，對(duì)于linux系統(tǒng)來說，就是一個(gè)或多個(gè)進(jìn)程，而這個(gè)wall clock time，它是進(jìn)程運(yùn)行的時(shí)鐘總量。它除了包括cpu真正的運(yùn)行時(shí)間之外，還包括了如：

就緒時(shí)間：

進(jìn)程具備運(yùn)行條件，但是還沒有CPU資源可用。例如你提交了一個(gè)case，但是半天提不上去跑不起來，可能因?yàn)槠渌说腸ase太多，導(dǎo)致機(jī)器滿載了，等別人釋放了之后你的case才真正獲得cpu資源運(yùn)行起來。

阻塞時(shí)間：

例如你的case已經(jīng)跑起來了，發(fā)現(xiàn)某個(gè)vip lisence不夠了，“卡”到那里了。

或者例如你編譯運(yùn)行過程中因?yàn)榇疟P不太充足出現(xiàn)的卡頓現(xiàn)象等。

2.cpu時(shí)間（cpu time）：

當(dāng)進(jìn)程運(yùn)行起來之后，占用cpu進(jìn)行計(jì)算花費(fèi)的時(shí)間。同樣是代碼在cpu上運(yùn)行，依據(jù)代碼類別不同，cpu時(shí)間也分為用戶cpu時(shí)間和系統(tǒng)cpu時(shí)間。

用戶cpu時(shí)間是代碼在用戶態(tài)（User Mode）運(yùn)行的時(shí)間。

系統(tǒng)cpu時(shí)間是代碼在內(nèi)核態(tài)（Kernel Mode）運(yùn)行的時(shí)間。

我們可以簡(jiǎn)單理解：依據(jù)代碼權(quán)限不同，用戶態(tài)執(zhí)行用戶代碼，內(nèi)核態(tài)執(zhí)行的是操作系統(tǒng)代碼。這里不深入展開了，感興趣的朋友可以查閱一些資料（為什么這里要多引申提一下這個(gè)概念，主要幫沒有聽過這些概念的朋友，在仿真性能分析報(bào)告中如果碰到相關(guān)詞匯，至少可以有一個(gè)簡(jiǎn)單的感性認(rèn)知）。

此外，從前面的wall clock time解釋可以看出，比如你的case被阻塞了、掛起了是不占用cpu時(shí)間的，但是真實(shí)時(shí)間還是繼續(xù)走的。有兄弟可能會(huì)問：“照這么說，wall clock time是不是肯定是大于cpu time？”

答案是：不一定。

如果是多核處理器機(jī)器上，cpu總時(shí)間是所有不同線程或進(jìn)程cpu時(shí)間之和，此時(shí)wall clock time時(shí)間就會(huì)比cpu總時(shí)間小了。其實(shí)依據(jù)wall clock time和cpu總時(shí)間的關(guān)系，也把進(jìn)程分為計(jì)算密集型（wall clock time小于cpu time，有多核并行的優(yōu)勢(shì)）和I/O密集型（wall clock time大于cpu time，沒有多核優(yōu)勢(shì)，很多等待時(shí)間）。

舉一個(gè)例子，如下截圖，VCS軟件對(duì)于verilog設(shè)計(jì)部分的編譯過程中，允許通過-j選項(xiàng)指定并行數(shù)量。在選擇合適的并行數(shù)量的情況下，相關(guān)部分編譯的wall clock time就會(huì)小于cpu time哦~

3.仿真時(shí)間（Simulation time）

仿真時(shí)間是仿真器維護(hù)的時(shí)間，就是我們波形中看到的那個(gè)多少ns多少ps那個(gè)時(shí)間，它顯然不是仿真過程中真實(shí)的時(shí)間。這個(gè)時(shí)間是為了表示實(shí)際電路的運(yùn)行時(shí)間，給電路仿真建模用的一個(gè)“數(shù)字”。

我們知道SystemVerilog是在值的更新、計(jì)算等一個(gè)個(gè)離散事件的相互觸發(fā)“推著”往前走的（推著走的單位就是也就是我們之前講過的global time precision，也就是timeslot）。

所以仿真時(shí)間長(zhǎng)短和運(yùn)行時(shí)間長(zhǎng)短、仿真速度沒什么關(guān)系，主要是看“步子”有多少。在其他所有因素都一樣的情況下，誰(shuí)的事件少、推的步子少誰(shuí)仿真的速度也就更快。

再舉個(gè)例子：`timescale 1ns/1ps 和`timescale 10ns/10ps，它們的time unit和time precision都同時(shí)擴(kuò)大了10倍，但它們的比值是一樣的，即“步子”數(shù)量是一樣的。在其他背景完全一樣的相同仿真單位度量情況下（這里指的不帶具體單位，如，#1；前者代表運(yùn)行1ns后者表示運(yùn)行10ns），仿真速度是一樣的。

Tips：我們說平臺(tái)提速到底要提哪個(gè)時(shí)間？

剛才Jerry給大家拋出了驗(yàn)證仿真的“3個(gè)時(shí)間”，我們回到本系列文章“驗(yàn)證仿真提速”主題，拋出一下最底層的問題：我們追求“提速”，根本目標(biāo)是想要減少哪個(gè)時(shí)間？

沒錯(cuò)，我們追求的最根本目標(biāo)是減少墻上時(shí)鐘時(shí)間（wall clock time），即我們需要的是減少自己浪費(fèi)的真實(shí)世界的時(shí)間，多跑幾輪case或者早點(diǎn)跑出結(jié)果早下班。如果你費(fèi)盡心思減少cpu time、仿真時(shí)間，最后wall clock time沒有降下來對(duì)于我們有個(gè)毛線意義？？雖然如前面有提到這3個(gè)時(shí)間有相關(guān)性，但是希望大家心中一定要明確我們的根本目標(biāo)。

2、怎么看見和定量分析驗(yàn)證平臺(tái)的時(shí)間？

有了前面的認(rèn)知鋪墊，我們回到實(shí)戰(zhàn)。如何定量分析驗(yàn)證平臺(tái)的時(shí)間和資源，我們以VCS工具為例（其他家工具大家自行探索），一般可以有兩種抓取性能信息的方式，一種是以“輕量級(jí)”的方式輸出編譯和運(yùn)行仿真過程中的性能匯總信息，一種是相對(duì)“重量級(jí)”的方式進(jìn)一步詳細(xì)分析仿真運(yùn)行性能信息。第二種為什么說比較“重量級(jí)”呢？主要原因是它本身就會(huì)造成很大的時(shí)間消耗。我們都簡(jiǎn)要介紹一下：

1.以“輕量級(jí)”的方式輸出編譯和運(yùn)行仿真過程中的性能匯總信息。

增加vcs編譯選項(xiàng)： -reportstats

增加simv仿真選項(xiàng)：-reportstats

工具將會(huì)直接把編譯和運(yùn)行的匯總性能報(bào)告直接打印在屏幕上，我們示意性跑出來的一組截圖如下：

上面的主要細(xì)節(jié)vcs手冊(cè)解釋原文如下：

? VCS start time

? Elapsed real time: wall clock time from VCS start to VCS end

? CPU time: Accumulated user time + system time from all

processes spawned from VCS

? Peak virtual memory size summarized from all the contributing

processes at specific time points

? Sum of resident set size from all the contributing processes at

specific time points

? Sum of shared memory from all the contributing processes at

specific time points

? Sum of private memory from all the contributing processes at

specific time points

? Major fault accumulated from all processes spawned from VCS

我們本篇主要關(guān)心時(shí)間，有了前文的鋪墊相信這里可以看得比較清楚了。

從上面的解釋可知：Elapsed real time就是編譯或運(yùn)行階段的墻上時(shí)鐘時(shí)間（wall clock time），cpu time是vcs產(chǎn)生所有進(jìn)程的用戶cpu時(shí)間和系統(tǒng)cpu時(shí)間總和。

順便，從這個(gè)舉例的截圖報(bào)告也可以明顯看出wall clock time大于cpu time，沒有任何多核優(yōu)勢(shì)，屬于I/O密集型。

這里提一個(gè)點(diǎn)，我們前面討論3種時(shí)間的時(shí)候可以了解到：即使是跑同樣的case，用同樣的種子，跑出來的時(shí)間統(tǒng)計(jì)信息也一定會(huì)因?yàn)榇疟P狀態(tài)等原因而不同。所以對(duì)于測(cè)試某種手段是否減少了總時(shí)間花費(fèi)，是否有收益（尤其是不太明顯的手段），單純的通過前后兩次跑同樣的case，對(duì)比統(tǒng)計(jì)結(jié)果是不足以判別的，如果不是明顯的提速手段，可能會(huì)出現(xiàn)使用后wall clock time和cpu time反而比使用前花費(fèi)更多時(shí)間。但是如果基于相同的服務(wù)器等因素的狀態(tài)，或基于統(tǒng)計(jì)的方式多次測(cè)試評(píng)估，就可以看出總體速度的提升趨勢(shì)。

2.以相對(duì)“重量級(jí)”的方式進(jìn)一步詳細(xì)分析仿真運(yùn)行的性能信息。

增加vcs編譯選項(xiàng) -lca -simprofile

增加simv仿真選項(xiàng) -simprofile time

（這個(gè)仿真選項(xiàng)后面除了跟time觀測(cè)仿真時(shí)間信息還可以加：如mem收集服務(wù)器內(nèi)存消耗信息等，當(dāng)然也可以如time+mem同時(shí)收集） 這些選項(xiàng)加了之后，工具會(huì)生成如下帶“profile”關(guān)鍵詞的文件和文件夾，我們主要看profileReport.html文件。

html文件打開后會(huì)發(fā)現(xiàn)分左右兩個(gè)區(qū)域，通過左邊區(qū)域可以控制出現(xiàn)在右邊區(qū)域你想要看到的性能信息，示意圖如下：

Jerry通過time+mem的選項(xiàng)，隨意跑了一個(gè)case，相關(guān)的summary示意圖如下：

我們還是關(guān)心time，主要貼下time的相關(guān)copmponent的含義（下面有的條目在上圖例子中不涉及，別的case也許就會(huì)有）：

?CONSTRAINT

The CPU time needed to solve and simulate the SystemVerilog constraint blocks.

?KERNEL

The CPU time needed by the VCS kernel. This CPU time is separate from the CPU time needed to simulated your Verilog or SystemVerilog, VHDL, SystemC, or C or C++ code for your design and testbench.

?VERILOG

The CPU time needed by VCS to simulate this example’s SystemVerilog code, which is a program block. For Verilog and SystemVerilog there are sub-components.

?DEBUG

The CPU time needed by VCS to simulate this example with the debugging capabilities of Verdi and the UCLI or to write a simulation history VCD or FSDB file.

?Value Change Dumping

The CPU time needed by VCS to write a simulation history VCD or VPD file.

?VHDL

For VCS only, the CPU time needed to simulate the VHDL code design.

?PLI/DPI/DirectC

The CPU time needed by VCS to simulate the C/C++ in a PLI, DPI, or DirectC application.

?HSIM (Hybrid Simulation)

This is about the CPU time used by HSOPT (Hybrid Simulation Optimization). The HSIM bucket indicates the CPU time consumption of design constructs that are optimized by HSOPT. It has become prominent in GLS design/RTL. The HSIM cost is more with GLS design because most constructs are optimized by HSOPT. But it cannot be zero because there are some global HSIM activities.

?COVERAGE

The CPU time needed for functional coverage (testbench and assertion coverage). Code coverage is not part of this component.

?SystemC

The CPU time needed for SystemC simulation.

通過調(diào)節(jié)前面提到html左邊區(qū)域選項(xiàng)，還可以看到更多的信息，如進(jìn)一步查看仿真過程中rtl和tb各個(gè)模塊層級(jí)花費(fèi)的時(shí)間信息，這里就不多贅述了，其他的玩法大家感興趣可以自己研究。

這種“重量級(jí)”的方式，雖然會(huì)拖慢仿真時(shí)間，但一個(gè)優(yōu)勢(shì)是收集的信息更加詳細(xì)，可以更直觀的看到各部分資源消耗百分比，更好的協(xié)助我們找到消耗時(shí)間的性能瓶頸，提供優(yōu)化方向和縮小優(yōu)化范圍。

結(jié)語(yǔ)

我們今天圍繞“時(shí)間”這個(gè)主題，首先討論了驗(yàn)證仿真中的“3個(gè)時(shí)間”建立了基礎(chǔ)認(rèn)知，接著明確了平臺(tái)提速到底要提哪個(gè)時(shí)間？最后以vcs工具舉例了怎么收集和分析相關(guān)信息。

審核編輯：劉清