話說螺螄殼里做道場，UVM推出這么多年以來每年DVCon會議上總還是有人分享他們基于UVM package做的一些改動，使其能夠更適合項目的要求。正如這篇論文里針對uvm_cmdline_processor這個類做的改動，經過修改，UVM環境在運行時能夠接收更復雜的參數，繼而滿足更好的控制隨機數據發送的項目要求。

從項目要求來看，在驗證前期隨機數據的吞吐、間隔、長度并不需要特意去關注，而在數據完整性基本得到保證以后，就要考慮邊界條件、性能表現等問題，也因此需要對隨機數據的約束進行調節。SV調節約束，以往可以通過對隨機值的rand_model或者約束塊的constraint_mode進行調節，繼而選擇需要隨機的變量和采取的約束，也可以通過在約束中植入有關影響隨機范圍的變量，而在仿真過程中影響這些變量去間接影響接下來生成的隨機數值。

只不過，上面第一種辦法對每個sequence item約束塊的構造和組織有要求，而且還需要在仿真前重新編譯繼而影響整個RNG（random number generator），第二種辦法可以在仿真過程中通過對某些變量的修改繼而影響仿真過程中的隨機數值，看起來是可以實現動態控制的，但也仍然不夠靈活，無論是對隨機數值的范圍影響，還是將這種辦法規范下來，都不適合在整個團隊范圍里去推廣（可以用，但是不夠完善）。

相比于將測試意圖通過sequence和item傳遞到driver，再由driver解析驅動總線，在驗證后期階段，我們往往需要對測試序列做到更加精準的控制。論文中也提到了可以對以下幾點做到控制：

對數據之間的間隔長短做控制，繼而影響數據吞吐。

在處理器驗證中，要控制的指令內容以及指令之間的關系均需要更多約束，往往還可以需要對操作數做到更準確的要求（比如其包含的指令、數據等信息）。

有時我們還需要在仿真過程中某個階段，特意去控制某個component或者item，以往可以通過uvm_config_db傳遞（在仿真開始前）。

以上的控制盡管可以在代碼中實現，但從以前的經驗來看，這些代碼仍然不夠靈活。所謂更加靈活的要求是能夠在仿真過程中將要求隨時傳遞給仿真環境，而仿真環境又能及時接收這些配置、激勵數據，繼而動態地對驗證模式、激勵數據做出改變。

原本uvm_cmdline_processor可以支持傳遞int和string，但不夠靈活以至于不能很好地控制上面所說的隨機數有關的生成過程。而本文擴展的新類就能夠從仿真時傳遞的命令項（同其他仿真參數一起傳遞并啟動仿真模型）解析更為復雜的隨機變量約束控制方式，繼而更靈活地控制測試。

這個新的類advanced_cmd_line_processor可以解析的指令新囊括了與約束范圍有關的min_val/max_val/value/weight的形式（對字符串參數形式更靈活的支持）

也可以支持對不同數據格式的支持，例如Hex/Bin/Int

由于可以在測試時傳遞更為多樣的命令參數，UVM環境中也就可以利用advanced_cmdline_processor做相應的解析，繼而獲得參數。在Example1中，我們可以在測試時傳遞例如+opcode=ADD:80,SUB:20 或者+operand=32'hfffffff0 或者 +oprand=32'h00000000~32'h0000000f等信息，也均可以在對應的組件中獲得參數，并加以利用。

在packet::pre_randomize()函數中，就利用advanced_cmdline_processor的方法is_valid()檢查測試時傳遞的參數，并通過get_rand_enum()獲得一個符合+opcode=ADD:80,SUB:20要求的枚舉值。同時，也可以通過get_rand_val()獲得一個滿足類似+oprand=32'h00000000~32'h0000000f要求的隨機數。

除了通過命令項傳遞某個參數項以外，advanced_cmdline_processor也可以支持傳遞例如+uvm_set_config_string這樣的命令項，這些命令項仍然可以通過get_rand_val()和其傳遞的對應UVM層次獲得測試時傳遞的數值。這樣的方法可以基于UVM層次將變量、約束范圍、權重等信息更準確地傳遞到sequence中。

+uvm_set_config_string=*pkt_seq_1,pkt_delay,”0:50,1:50” +uvm_set_config_string=*pkt_seq_2,pkt_delay,”10~20:50,21~100:40,101~500:10”

這篇論文寫得要輕松一些，讀者在閱讀的時候也能跟的上，在解決了一些實際問題的時候可以會心一笑。更贊的一點是，它毫無保留地把解決方案里涉及到advanced_cmdline_processor和其它類/方法都展示在附錄中?；诖?，這篇論文提出了一個實際工作中的痛點，然后又輕巧地給出了一個解決方案。這樣的論文生命周期往往可以延續更久，因為它的目標更聚焦、也解決很多驗證工程師實際工作中的麻煩，更何況還有完整的代碼呈現，可以說是拿來就能用了。

不過，我們還可以圍繞著靈活控制隨機測試再給出路科的另外一種解決方案（來自于V3課程的某個模塊）。我們希望不僅僅是在仿真前通過傳遞參數項來控制驗證環境和激勵，還希望找到一種可能，在仿真過程中可以對驗證環境中的變量、約束等內容進行修改。

這里以VCS工具為例，它的UCLI（unified command line interface）提供了一種辦法，可以在Tcl命令窗口一側去調用SV中的函數或者任務。那么，我們可以將可供Tcl調用的方法放置在某個域中（例如module或者interface）。

比如我們下面的這個例子就可以實現在仿真中查詢、獲得、配置等目的，這些方法在接口中實現以后，在UVM和Tcl兩側均可以利用這些方法。

這里定義了一些進入某些特定scope hierarchy的接口，以便在Tcl中調用，繼而在該scope中調用某些方法。

這些接口方法可以用來在仿真中設定報告信息的冗余度。

這里給了一個例子，可以在Tcl腳本的特定時間，進入某個scope，再調用相應的調試接口方法，調用這些方式時也可以傳遞參數，并且取得返回值。

這樣的案例用來展示某些調試接口方法在仿真運行時對驗證環境的控制，實際上我們在文章上半部分談到的對于隨機值的影響、某些變量的修改、某些驗證組件的工作模式等，只要我們的調試接口方法定義得當，那么都可以在仿真運行過程中隨時調用。

從論文描述的解決問題的初衷來看，是為了更方便地去控制激勵的數據內容，而如果要再拓展那么就可以采用我們給的第二種方式在Tcl中調用某個scope中的接口方法，讓Tcl與測試用例之間形成一個互動。

其實不管是C-DPI的調用方式，還是Tcl調用SV的方式，都是為了讓測試在運行時能夠更靈活地配置、改動（SV的重復編譯在更大的環境結構下更為耗時），而相比于C-DPI的方式，通過對UVM uvm_cmdline_processor的拓展在驗證環境啟動，或者通過Tcl調用SV方法在驗證環境運行都更為靈活。而且這兩種方案也都能夠做成規范，推行到團隊中去。

審核編輯：劉清