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

1、驗證仿真中的“3個時間”

在驗證仿真過程中，我們腦中需要閃過至少3個概念：

墻上時鐘時間（wall clock time）

cpu時間（cpu time）

仿真時間（simulation time）

他們都是什么呢？

1.墻上時鐘時間（wall clock time）：

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

你跑一個case，對于linux系統來說，就是一個或多個進程，而這個wall clock time，它是進程運行的時鐘總量。它除了包括cpu真正的運行時間之外，還包括了如：

就緒時間：

進程具備運行條件，但是還沒有CPU資源可用。例如你提交了一個case，但是半天提不上去跑不起來，可能因為其他人的case太多，導致機器滿載了，等別人釋放了之后你的case才真正獲得cpu資源運行起來。

阻塞時間：

例如你的case已經跑起來了，發現某個vip lisence不夠了，“卡”到那里了。

或者例如你編譯運行過程中因為磁盤不太充足出現的卡頓現象等。

2.cpu時間（cpu time）：

當進程運行起來之后，占用cpu進行計算花費的時間。同樣是代碼在cpu上運行，依據代碼類別不同，cpu時間也分為用戶cpu時間和系統cpu時間。

用戶cpu時間是代碼在用戶態（User Mode）運行的時間。

系統cpu時間是代碼在內核態（Kernel Mode）運行的時間。

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

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

答案是：不一定。

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

舉一個例子，如下截圖，VCS軟件對于verilog設計部分的編譯過程中，允許通過-j選項指定并行數量。在選擇合適的并行數量的情況下，相關部分編譯的wall clock time就會小于cpu time哦~

3.仿真時間（Simulation time）

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

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

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

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

Tips：我們說平臺提速到底要提哪個時間？

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

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

2、怎么看見和定量分析驗證平臺的時間？

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

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

增加vcs編譯選項： -reportstats

增加simv仿真選項：-reportstats

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

上面的主要細節vcs手冊解釋原文如下：

? 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

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

從上面的解釋可知：Elapsed real time就是編譯或運行階段的墻上時鐘時間（wall clock time），cpu time是vcs產生所有進程的用戶cpu時間和系統cpu時間總和。

順便，從這個舉例的截圖報告也可以明顯看出wall clock time大于cpu time，沒有任何多核優勢，屬于I/O密集型。

這里提一個點，我們前面討論3種時間的時候可以了解到：即使是跑同樣的case，用同樣的種子，跑出來的時間統計信息也一定會因為磁盤狀態等原因而不同。所以對于測試某種手段是否減少了總時間花費，是否有收益（尤其是不太明顯的手段），單純的通過前后兩次跑同樣的case，對比統計結果是不足以判別的，如果不是明顯的提速手段，可能會出現使用后wall clock time和cpu time反而比使用前花費更多時間。但是如果基于相同的服務器等因素的狀態，或基于統計的方式多次測試評估，就可以看出總體速度的提升趨勢。

2.以相對“重量級”的方式進一步詳細分析仿真運行的性能信息。

增加vcs編譯選項 -lca -simprofile

增加simv仿真選項 -simprofile time

（這個仿真選項后面除了跟time觀測仿真時間信息還可以加：如mem收集服務器內存消耗信息等，當然也可以如time+mem同時收集） 這些選項加了之后，工具會生成如下帶“profile”關鍵詞的文件和文件夾，我們主要看profileReport.html文件。

html文件打開后會發現分左右兩個區域，通過左邊區域可以控制出現在右邊區域你想要看到的性能信息，示意圖如下：

Jerry通過time+mem的選項，隨意跑了一個case，相關的summary示意圖如下：

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

?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.

通過調節前面提到html左邊區域選項，還可以看到更多的信息，如進一步查看仿真過程中rtl和tb各個模塊層級花費的時間信息，這里就不多贅述了，其他的玩法大家感興趣可以自己研究。

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

結語

我們今天圍繞“時間”這個主題，首先討論了驗證仿真中的“3個時間”建立了基礎認知，接著明確了平臺提速到底要提哪個時間？最后以vcs工具舉例了怎么收集和分析相關信息。

審核編輯：劉清