探討一下在UVM中典型的驗證平臺

驗證平臺顧名思義就是為了驗證而存在的。普通意義上來說，如果是IP驗證，當驗證人員拿到設計的某模塊的RTL代碼（DUT，Design Under Test），設計文檔之后，就會根據文檔，基于自己的理解去著手寫驗證計劃，提取功能點，準備搭建驗證平臺（其實大多數情況下，是迭代上一代的驗證平臺），開始寫驗證的case（成熟的公司也很可能是繼承上一代的驗證case，進行改動或者增加）。所以，驗證平臺可以看做是一個“測試機器”，專門是為了測試RTL代碼以及功能的正確性，找出其中“躲藏”的bug，千里之堤潰于蟻穴，芯片的流片失敗，可能只是其中的一個小小bug。

形象一點來說，RTL代碼你可以想象成一根彎彎繞繞的水管，現在的情況是，你不知道這根水管通不通，能不能順利的把水從這頭送到那頭。那怎么辦，找另一根有水的管子，和這根管子接上，再觀察這根管子的出口有沒有水出來即可。同樣的道理，驗證平臺就相當于一根有水的管子，把它和DUT的輸入端口（input）連起來就可以了，這個“水”就相當于激勵。

為了找出bug，我們就需要這樣一個測試平臺，能夠發(fā)送激勵，也就是數據（data），對代碼進行檢驗，為什么要叫做激勵，我想，可能是想激勵DUT努力工作吧。這里就涉及到激勵發(fā)生器。比如說，我們要驗證一個加法器。加法器都知道，它的功能就是實現a+b=c，這樣的運算。激勵發(fā)生器負責產生a和b的值，DUT負責運算出c的值，驗證平臺通過對照c的值來判定DUT的代碼是否正確。

上面這段描述，就涉及UVM里面幾個重要的知識點：

· Driver，負責產生，發(fā)送激勵（后面會將產生和發(fā)送分開）；

· Scoreboard就像是一個質檢員，負責把樣品和合格品進行對比；

· monitor負責進行數據收集、以及發(fā)送給scoreboard；

· 正確與否我們需要一個參照，這個就是所謂的reference model。

這四個部分就可以組成UVM中簡單的驗證平臺，如圖所示：

但是有一天，driver說我不干了，我干的事情太多了。所以，就要把driver的功能進行拆分，俗話說，術業(yè)有專攻嘛，driver就負責發(fā)送激勵，而不再產生激勵。把功能拆分之后，另一個好處就是，復用程度更高。針對不同的case，往往只是激勵的不同，拆分之后，我們不再需要每次都改變driver。如此一來，這么一拆分，就有了UVM中，經典的驗證平臺，如下圖所示。

有的同學可能會說，怎么沒有sequence？請記住，sequence不屬于驗證平臺的任何一個部分。在這個經典的驗證平臺中，其實是沒有產生激勵的部分了。這就相當于，你給DUT這根管子接了一根沒水的新管子，你需要在這根新管子上再接一根有水的管子。這樣的好處是什么呢，還是復用。這樣，你的驗證平臺就不需要怎么改動了，只要每次去切換那根有水的管子，也就是sequence。在實際的工作當中，針對一個項目，會有很多很多的sequence，但是驗證平臺的組件，基本上對于一個項目來說，是不動的。