驗證平台自動化篇之一：你為什麼需要一款代碼生成器？

在介紹UVM的部分中，我們突出了它的結構性和復用性，UVM作為基於SystemVerilog語言的驗證方法學，彙集了原有的方法學和特性，在最近的幾年中已經成為了公認的驗證方法學標準，而且從最新的消息來看，UVM-1.2已經被IEEE批准為1800.2的標準。這一消息無疑會讓手握了IEEE-1800標準（SystemVerilog）的verifier們感到振奮，這意味著以後行業在底層驗證的結構化構建上面也有了統一的標準。無論是1800還是1800.2，可以說都是好東西，然而對於一個初級選手，要入門這兩個標準，其難度一點也不亞於當年如何學習C語言的。

對於一個新手，掌握SystemVerilog，這需要他們一邊熟悉語法，一邊實踐來了解SV的語言特性；而對於UVM的學習又有不同，這一點在我授課的時候就能體會到。因為SV的語言特性是可以模塊化，進行剝離分解傳授的，而UVM的不同的地方在於，首先要進入UVM世界獲得一張門票，就挺有難度，比如你得建立好UVM的世界觀，懂得UVM世界是怎麼運作的，其次再來認識UVM中的各個組件、通信、序列方式等。而學生們在上課的簽到表中，也可以看到SV部分還有很多的同學堅持簽到，而到了UVM部分則有很大的簽到缺失。這麼看來，UVM缺失對它的初學者們不那麼友好。儘管在軟體領域，也有別的基於某些語言的包（package），但是自稱體系和標準的包並不多，UVM就是一個。

UVM讓絞盡腦汁的不單單是在校學生，也包括那些初次接手UVM項目的菜鳥verifier。一本UVM類的索引手冊和方法子集就難免叫人頭疼，更何況如果沒有一個貼心的IDE開發工具，這就很考驗verifier的記憶，去熟悉那些常用的類、方法和參數列表。UVM為了提供一個良好的環境結構，對於可行的結構搭建和序列控制提供了不止一種方法，這也使得verifier們在考慮使用哪一種方法更為合適前手足無措。UVM另外一個對於新人不好的地方是，它需要大量的培訓、練習和經驗來將UVM中的各個組件、環境建立和場景創建有機組合為自己知識體系。這些要求對於一個新人而言很難滿足，但公司的工作要求卻實實在在的這麼描述。

即使新人可以通過在校期間的實習來彌補一些距離，但也無法保證他親自搭建的驗證結構會不會對今後的復用不那麼友好，需要的時間是否為項目進度所允許。有很多的公司提供UVM培訓，譬如「90天UVM從零到精通」，「UVM實戰」等題目都可以搜索到，只要你花一些時間和錢，就能得到專業的培訓。同時，網上也能搜索到不少UVM的代碼生成器，譬如「UVM模板」、「UVM生成器」，用來協助生成一些公共的代碼結構。培訓是為了幫助應聘者進入一家好的平台環境工作，是從乙方的角度出發；而UVM模板和生成器則是從甲方的角度出發，它的目的是將構建UVM驗證環境好的代碼規則和結構方式作為底層框架植入到verifier的手中，這可以避免代碼的凌亂不規則，從而提高效率。當然，代碼生成器也有一些缺陷，譬如會生成一些冗餘的代碼、不那麼容易理解代碼、或者無法按照使用者的要求生成更準確的代碼。

在介紹代碼生成器之前，我們首先要考慮，一個verifier需不需要代碼生成器？擁有了它，會有什麼好處呢？什麼菜算得上一款出色的代碼生成器呢？我們可以從它產生的代碼質量幾個方面來評估它：

好的編碼風格。

代碼有足夠的穩定性和可移植性。可以在多個模擬器運行，且易於將來做擴展和修改。

可讀性，且便於維護。

靈活性。用戶自定義的代碼部分可以很好地嵌入。

高產出。即屬於可以自動化生成的代碼可以盡量多地產生並作為驗證環境的框架基礎。

迭代性。即支持伴隨著項目的變化，對驗證環境做出調整時，生成代碼也可以做出快速的迭代反應，繼而修改驗證環境結構。

那麼代碼生成器的好處在哪兒呢？對於UVM新的用戶，代碼生成器可以快速地給用戶提供完整的工作環境，繼而節省構建和調試驗證環境的時間，對於一個標準的模塊驗證環境，這往往可以節省2周到3周的時間。那麼UVM的老用戶而言，它就可以幫助節省冗長乏味的結構搭建時間，還能在既有的框架上很快地完成激勵通路。另外，如果在整個項目組中都流行同一個代碼生成器，那麼它良好的結構和代碼風格，使得代碼在後續繼承時便於維護，而不會出現繼承新環境時要花太多的時間去理解前人構建環境的「奇異思路」。所以無論對於新用戶還是老用戶，代碼生成器都有它的優勢。所以就提供工作效率來看，一個verifier應該需要掌握代碼生成器的常規使用方法，並且有一款自己熟悉的代碼生成器，而且最好在所在的公司內能夠有一款一致的工具。

那麼一款代碼生成器可以協助我們完成哪些場景的需求呢？

首先它仍然有助於UVM學習。因為通過快速的環境結構建立，可以使得用戶不再拘束於某些代碼的碎片，而是可以在一棟能夠使用的「房子」中間落腳。在此基礎上他可以實現需要自定義的方法。當然，也有的一些UVM用戶認為，代碼生成器使得UVM小白無法經歷從無到有的構建過程，丟失了深入UVM並且調試環境的機會。對於這種觀點，路桑認為還需兩方面看待，一方面，代碼生成器可以帶小白們「一日看盡長安花」；另外一方面，在小白們通讀了生成的代碼，知道了什麼是「套路」、什麼是好的代碼風格以後，再參考這種代碼形式，從零開始嘗試構建環境，進一步學習也是好的學習途徑，畢竟高手一開始也是從模仿別人開始的。

在項目過程中，代碼生成器的介入期限往往只會在驗證一開始的環節。在這個時候，需要收集DUT的介面類型、數量和其它信息，繼而將這些信息作為生成器的輸入文件，進而依靠它來生成環境的框架。一旦產生之後，我們便不再需要生成器，而是手動來修改代碼，添加自定義部分。那麼有人會問，如果DUT的介面修改了怎麼辦呢？有沒有可能使用生成器再生成一次新的代碼框架，同時又可以保留和合并之前的自定義代碼呢？這要看代碼生成器本身是否支持。如果代碼生成器產生的代碼結構，無法清晰分清公共部分（自動生成部分）和自定義部分，文件也沒有清晰剝離的話，那麼我們就無法再次生成環境框架。如果剝離得清晰，那麼生成器仍然可以實現框架的更新和自定義代碼的合并。

其實有很多公司和組織提供了不錯的代碼生成器，無論是已經開源發布的，還是被囊括在商用套件中，又或者是公司內部開發的。這些代碼生成器一般都可以解決下面這些問題：

生成模塊化的uvm_agent。

頂層的uvm_env將各個agent進行例化。

各個agent內的monitor到scoreboard的TLM埠連接。

按照uvm_env中各個組件的層次，生成相應的config對象和層次化的config結構，繼而從頂層傳遞到目標對象，完成配置。

各個driver對應的sequence基類，和頂層的virtual sequence。

virtual sequencer和各個agent中的sequencer在頂層環境中的連接。

虛介面的創建的傳遞。

同時，不同的代碼生成器也有一些個性化的功能，譬如：

將寄存器模型（已生成的）集成到頂層環境中。

創建寄存器到匯流排driver的adaptor模板。

創建subscriber模板，為scoreboard服務。

創建頂層的TB，包括例化DUT，而DUT同interface之間的連接關係需要預先給定。

目前，有這樣一些代碼生成器可以供用戶下載學習和使用。在使用的同時，請注意這些工具的licence類型，避免使用衝突：

Easier UVM Code Generator @Doulos

https://www.doulos.com/knowhow/sysverilog/uvm/easier_uvm_generator/

VCS UVM Template Generator (uvmgen) @Synopsys

這個工具插件綁定與VCS工具，使用之前請確認你的機器是否已經安裝有VCS。

VerificationWorks envBuilder @Paradigm Works

http://paradigm-works.com/products/

該公司的這個環境自動化工具前些年是免費的，然而現在看起來也要收費了。

UVM Framework @MentorGraphics

https://verificationacademy.com/sessions/dvcon-2017/testbench-automation

MentorGraphics推出的UVM驗證環境自動化工具，它的功能不再局限於生成空模板盒子，而在於結合Questa VIP，更快地建立可以直接使用（給出激勵）的環境。這個工具的特性與我們接下來本章要重點介紹的驗證平台自動化理念有很大的相似之處。我們會在稍後進一步介紹該工具的特性。讀者還可以在上面給出的網址中觀看這個工具的特性介紹和視頻，這個工具對於Questa模擬用戶和VIP用戶是一大福利，因為它解決了基於Questa模擬工具和VIP的驗證環境快速構建的問題。該工具在QuestaSim10.6的基礎上就集成到模擬工具中了，作為一個驗證環境自動化的工具相信對於QuestaSim的用戶是一個賣點。

目前推薦使用的一款開源代碼生成器是Doulos的"Easier UVM Code Generator"，除了免費之外，就是它的生成器代碼可供讀者參考和修改，進而有可能貼合自己團隊的使用要求。而這一生成器的限制在於，它使用的假設是使用者缺少可以服用的VIP，無論是商用的還是自己公司內部的，可這假設往往與公司的實際情況不一樣。對於大公司而言，它有足夠的資金保證商業VIP的供應，並且在此基礎上開發，這服用資源的效率配置最大化，而對於小公司而言，它們也會在項目的積累上面逐步完善出自己的VIP。無論對於哪一種情況，這種代碼生成器都無法很好地貼好已有的VIP介面，和公司的實際開發流程，因此要做到真正的生成器深度嫁接，是有不小的困難。而對於UVM的新手，或者輕量級的驗證場景，這一生成器又是一個不錯的助手。因此，我們這一章，不再就普通的代碼生成器開發進行更多的代碼展示，而讀者可以就上面提到的生成器下載，完成實例演示應用，掌握該生成器的使用。

在這一章中，路桑就自己參與過研發的驗證平台自動化工具Pangu，介紹它的設計理念和實現流程。之所以代替EDA廠商，自己研發一款驗證平台自動化工具需要額外的精力，但在下一節MentorGraphics UVM Framework的介紹中，用戶可以理解到，開發一款貼合自己公司開發流程的自動化工具是多麼為整個項目團隊省心，而如果讀者你所在的公司已經擁有了這麼一款工具，那麼請感謝它的開發者吧，如果你的公司還沒有，那麼希望你在讀完本章之後，可以從中獲取開發的理念和所需要的一點技術，在將來合適的時機能夠幫助公司完善這項空白。

謝謝你對路科驗證的關注，也歡迎你分享和轉發真正的技術價值，你的支持是我們保持前行的動力。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！