化類：驗證環(huán)境實戰(zhàn)陷阱解析)
做驗證的兄弟應該都撞見過這種鬼打墻的 bug你在 scoreboard 里比較完數(shù)據(jù)順手改了一下某個 transaction 的字段做 debug結果下一拍發(fā)現(xiàn) reference model 那邊的同一筆數(shù)據(jù)也變了。代碼邏輯翻來覆去看了三遍沒有任何人對參考模型寫過數(shù)據(jù)。最后實在沒辦法把兩個對象的地址打出來一看——好家伙根本是同一個對象。這就是 SystemVerilogSV對象拷貝里最經(jīng)典的淺拷貝陷阱你以為是復制了一份數(shù)據(jù)實際上只是復制了一個句柄兩個變量牢牢握著同一塊內(nèi)存。再說到標題里的另一個主角參數(shù)化的類很多朋友剛接觸 SV 面向對象編程時會把它當成 C 模板的低配版簡單用class #(type T int)包一層就覺得完事。實際在驗證環(huán)境里對象拷貝、參數(shù)化類和數(shù)據(jù)類型轉換這三件事是纏在一起的參數(shù)化類經(jīng)常接收不同類型的 transaction而不同類型的對象在發(fā)出去之前往往需要做動態(tài)轉換轉換失敗又可能引出一堆和拷貝相關的連帶問題。這篇文章就把這三件事從原理到實操捋一遍最后再分享幾個我在真實項目里踩過、填過、覺得值得記住的坑。1. 改了 A 卻影響了 B對象拷貝中最常見的句柄共享事故1.1 一個能完美復現(xiàn)問題的最小用例先把問題現(xiàn)場還原出來。假設我們有一個最簡單的包class pkt; int data; int id; endclass然后寫兩行幾乎所有人都寫過的代碼pkt a; pkt b; a new(); a.data 100; a.id 1; b a; // 你以為復制了一份 b.data 200; $display(a.data %0d, b.data %0d, a.data, b.data);這段代碼的打印結果是a.data 200, b.data 200。如果你心里預期的結果是a.data 100那你就撞上了 SV 對象語義里最基礎的一個特點b a并不會創(chuàng)建一個新對象它只是把a這個句柄的值復制給了b兩個名字指到同一個對象上去了。很多從 C 語言或者從 Verilog 的reg、wire思維轉過來的朋友剛開始非常不適應這件事。因為在 C 里結構體變量之間可以直接賦值值是整體搬過去的在 SV 里類變量不是值是引用。你復制引用不會復制對象就像你抄了一份通訊錄的地址不代表你把那個人也復制了一份。1.2 句柄、對象與內(nèi)存地址先把這個基礎焊死要徹底理解對象拷貝必須分清楚三個概念句柄handle、對象object和內(nèi)存地址。我們寫pkt a new();干的事情是在仿真器的堆上創(chuàng)建了一個pkt對象然后把指向這塊內(nèi)存的門牌號存進變量a。a本身不是對象a是一個存放著對象地址的句柄變量。所以在 SV 里兩個句柄指向同一個對象是非常常見、也非常合法的狀態(tài)這不叫兩個一樣的對象而是對同一對象的兩個稱呼。一個更生活化的類比是對象是房子句柄是門牌號。b a只是把門牌號又抄了一份給你兩個人還是拿著同一個門牌號去找同一棟房子。你在房子 A 里重新裝修拿著另一份門牌號的 B 過來看看到的當然也是裝修后的樣子。理解了這一點再看下面這些行為就會很清晰操作結果是否創(chuàng)建新對象b a;b 和 a 指向同一對象否b new(); b.copy(a);b 是新對象成員值來自 a是b a.copy();若實現(xiàn)了 copy 返回新對象是b new a;取決于類中是否定義接收 a 的構造函數(shù)不一定1.3 從共享到獨立究竟差在哪知道了b a是共享句柄之后問題就變成怎么讓兩個對象真正獨立最常見的偷懶寫法是b new(); b.data a.data; b.id a.id;這個寫法對只有兩個成員的類沒有問題但 transaction 的成員通常不止兩三個。典型的一個總線事務對象可能有十幾個字段還有定長數(shù)組、動態(tài)數(shù)組、隊列、事件、其他對象的句柄甚至還要處理嵌套對象。你寫幾次b.xxx a.xxx就知道這種純手工逐字段復制的做法多寫兩個類之后一定會漏字段。前面表格里還提到一種寫法是b new a;這里要特別提醒SystemVerilog 不會像 C 那樣自動給你生成一個以同類對象為入?yún)⒌目截悩嬙旌瘮?shù)。b new a實際調用的是new(a)這個調用能不能編譯、語義是否做拷貝完全取決于類里面有沒有顯式定義一個接收a類型參數(shù)的function new。如果類里沒有定義很多仿真器會直接報錯或者行為未定義如果定義了那也是你寫的邏輯在起作用而不是語言默認幫你拷貝。所以 SV 社區(qū)里最常見的、可移植性最好的拷貝方式是自己實現(xiàn)一個copy()方法不要依賴這種語法糖。2. 淺拷貝和深拷貝的本質new、copy 與 clone 的分工2.1 默認行為解剖為什么 SV 不自動給你一個拷貝構造既然標準庫沒有默認拷貝構造那我們就得自己把拷貝這件事做對。在做之前先明確兩個概念淺拷貝shallow copy和深拷貝deep copy。淺拷貝的定義是新對象創(chuàng)建出來后每個成員變量的值都復制了一遍。這句話聽起來很簡單但有一個埋伏如果某個成員本身是另一個對象句柄那么復制這個句柄的值只是讓新對象和舊對象指向同一個子對象。舉個例子class addr_t; int addr; endclass class pkt; int id; addr_t addr; endclass如果我們寫一個淺拷貝函數(shù)function pkt shallow_copy(); shallow_copy new(); shallow_copy.id this.id; shallow_copy.addr this.addr; // 只復制了句柄兩個對象的 addr 還是同一個 endfunction那么復制出來的pkt對象它的addr成員和原來的addr成員仍然共享同一個addr_t對象。這不一定都是壞事但它一定是你需要明確知道的語義。如果你在復制后把那邊的addr.addr改了這邊的也會跟著改。深拷貝則是不僅復制頂層對象還要把頂層對象手里所有的子對象、數(shù)組元素、隊列元素等全部遞歸復制一遍。深拷貝之后新舊對象之間除了字段值相同再沒有任何共享內(nèi)存。2.2 自實現(xiàn) copy 函數(shù)處理基本成員、對象成員與隊列成員在 SV 里一個可復用的深拷貝函數(shù)通常按下面幾步來寫。第一步處理所有內(nèi)建值類型成員int、bit、logic、enum、string等。這些直接賦值即可。第二步處理對象引用成員。對每個類成員要么調用它自己的copy()方法要么new()一個新的再逐字段賦值。第三步處理動態(tài)數(shù)組、隊列、關聯(lián)數(shù)組。這一步最容易被漏。因為 SV 的數(shù)組賦值是比較智能的直接new_array old_array可以復制整個數(shù)組內(nèi)容所以不少人以為隊列也可以直接賦值就完事了。對動態(tài)數(shù)組和隊列來說直接賦值確實會復制元素但如果元素本身是對象句柄那復制的是句柄數(shù)組數(shù)組里的對象仍然是共享的。想深拷貝數(shù)組對象得用循環(huán)逐個 deep copy。第四步處理可能存在的自引用和循環(huán)引用。比如類 A 里有一個A next成員深拷貝時如果不加判斷會無限遞歸下去。簡單場景可以約定好只深拷貝數(shù)據(jù)對象不深拷貝連接關系復雜場景可以維護一個已經(jīng)拷貝過的舊對象到新對象的映射表碰到已拷貝過的對象直接返回已有副本。一個比較完整的手寫深拷貝模板如下class pkt; int id; string name; int payload[$]; addr_t addr; bit has_addr; function pkt copy(); pkt c new(); c.id this.id; c.name this.name; c.payload this.payload; // 隊列整體復制元素是 int沒問題 if (this.has_addr) begin c.addr new(); c.addr.addr this.addr.addr; end c.has_addr this.has_addr; return c; endfunction function void copy_to(pkt rhs); rhs.id this.id; rhs.name this.name; rhs.payload this.payload; if (this.has_addr) begin if (rhs.addr null) rhs.addr new(); rhs.addr.addr this.addr.addr; end rhs.has_addr this.has_addr; endfunction endclass這里我故意寫了兩個函數(shù)一個copy()返回新對象一個copy_to(rhs)把內(nèi)容復制到一個已存在的對象。為什么需要兩個因為驗證環(huán)境里兩種場景都有scoreboard 里希望再搞一個一樣的對象存起來用copy()driver 里希望把已經(jīng)創(chuàng)建好的對象內(nèi)容更新一下用copy_to()更省內(nèi)存。2.3 UVM 環(huán)境里 copy/clone 的常見約定如果你已經(jīng)在用 UVM很多對象繼承自uvm_objectUVM 自己有一套拷貝機制。核心是兩個 virtual 方法copy和clone。默認行為是copy調用do_copyclone創(chuàng)建新對象后調用copy。如果你的類沒有實現(xiàn)do_copy那么copy什么都不做clone只會返回一個空對象。UVM 的uvm_object_utils宏配合 field automation 時copy會按照字段宏定義逐個復制。但這里有個容易忽略的點field automation 對對象字段比如uvm_object_field默認只復制句柄也就是淺拷貝。你聲明了uvm_object_utils不代表自動深拷貝要深拷貝嵌套對象必須在do_copy里顯式處理或者約定好被嵌套對象不可變。我見過不少團隊在項目手里的 base transaction 里實現(xiàn)一次完整的深拷貝copy然后所有派生事務類在重寫do_copy時先super.do_copy(rhs)再補自己新增的字段。這個思路簡單又不容易漏推薦給還沒形成規(guī)范的項目。3. 驗證環(huán)境里對象拷貝的實戰(zhàn)位置從 driver 到 scoreboard3.1 transaction 對象在組件間流動時哪些環(huán)節(jié)必須拷貝搞清楚了拷貝的機制再把它放進完整驗證環(huán)境的上下文里。一個典型的約束隨機驗證平臺里transaction 對象是這樣流動的generator 生成對象通過 sequencer/driver 轉成接口信號monitor 從接口采樣得到對象發(fā)給 scoreboard 和 reference model。在這條鏈路上并不是每個環(huán)節(jié)都要拷貝。需要拷貝的地方通常是這兩類第一類是存檔場景。scoreboard 里經(jīng)常需要一個期望值隊列把進入 DUT 之前的數(shù)據(jù)包保存起來等 DUT 輸出再做比對。如果直接把 generator 的那個句柄塞進隊列后續(xù) driver 把同一對象改掉scoreboard 里存的東西也被改了比對就全面失真。這種場景必須深拷貝一份再入隊。第二類是并發(fā)處理場景。一個事務對象同時被多個 component 處理時如果 A 組件要對它做標記、加字段、改狀態(tài)而 B 組件希望看到原始狀態(tài)那么必須先復制出一份獨立對象給 A 用。不復制的話A 的修改會像一個全局變量一樣毒化所有引用者。不需要拷貝的場景interface 信號驅動、mailbox 的純傳遞、只讀的數(shù)據(jù)分析。在這些場景里拷貝純屬浪費仿真時間和內(nèi)存。3.2 mailbox 傳輸?shù)目截惻c否一種常見的性能與正確性權衡mailbox 是 SV 里最常用的線程間通信手段但它傳遞的同樣只是句柄。很多人也有一個疑問把對象放進 mailbox要不要先 copy 一份答案取決于接收方是否會修改對象。如果接收方拿到對象后只是讀取并轉換成信號那么不拷貝沒有任何問題還更高效。如果接收方拿到后要修改并且發(fā)送方之后還會用這個對象那么不拷貝就有隱患。一個比較穩(wěn)妥的約定是發(fā)送方一旦把對象放進 mailbox就視為所有權移交。后續(xù)想再保留數(shù)據(jù)發(fā)送方在 put 之前自己先深拷貝留存接收方擁有對對象的修改權。這樣責任邊界清晰不容易出現(xiàn)兩邊同時改一個對象的競爭。一個額外提醒如果發(fā)送方在循環(huán)中重復使用同一個句柄發(fā)數(shù)據(jù)比如forever begin trans new(); // 隨機化、填充字段 mb.put(trans); end這種情況每次都是新對象不需要拷貝。但如果是復用同一個對象forever begin // 不重新 new只改改字段再發(fā) trans.data data; mb.put(trans); end接收方拿到的每一個包實際上都是同一個對象。等下一個循環(huán)改了data已經(jīng)進入 mailbox 的包也會跟著變。這種 bug 比淺拷貝更隱蔽因為它看起來是每一包數(shù)據(jù)都一樣而不是某一包被篡改。排查到最后往往要打地址才會恍然大誤所有包全是一個地址。3.3 拷貝實踐中的典型錯誤與查驗習慣我在實際項目里見到的、以及自己犯過的典型錯誤大致有這么幾類第一類定義了copy()但忘記維護新增字段。類加了一個新字段copy()沒同步更新導致復制出來的對象某些字段是默認值。這個錯誤平時很難發(fā)現(xiàn)因為大多數(shù)時候你不比對每個字段只有在某個用例數(shù)據(jù)恰好依賴那個字段時才爆發(fā)。應對辦法每次改 transaction 類時強制看一眼copy/do_copy方法或者干脆在 base 類里加一個自查方法比較兩個對象所有字段是否一致測試時點用一下。第二類把淺拷貝當深拷貝用。對象成員、動態(tài)數(shù)組里的對象元素都沒復制導致所有引用者共享子對象。尤其 UVM 的 field automation 默認淺拷貝這個坑非常容易踩。寫代碼前先問自己一句這個對象會不會在被復制之后繼續(xù)被別人改如果會請確認嵌套成員都是深拷貝。第三類拷貝后忘記恢復隨機化狀態(tài)。SV 類的randomize()每次調用都會重新隨機如果拷貝函數(shù)內(nèi)部動不動new()出一個新對象把原來已經(jīng)滿足約束的數(shù)據(jù)覆蓋成隨機值就會出現(xiàn)比較不過但不知道哪里錯的詭異問題?？截惡瘮?shù)要嚴格只復制、不隨機。檢驗拷貝是否深的一個好辦法復制后把舊對象里最內(nèi)層的一個字段改掉看新對象是否跟著變。寫一個調試用的check_independent()函數(shù)在測試環(huán)境常駐比事后排查省時間得多。4. 參數(shù)化類把一類多用寫進類型系統(tǒng)4.1 參數(shù)化類解決了什么痛點對比宏定義和基礎類繼承對象拷貝解決的是內(nèi)容獨立參數(shù)化類解決的是類型通用。兩者在驗證組件復用里經(jīng)常遇到。假設你要寫一個通用的generator它可以產(chǎn)生eth_pkt也可以產(chǎn)生axi_txn還可以產(chǎn)生i2c_seq。不用參數(shù)化的時候有兩條路一條路是寫一個以uvm_object為基類的通用類內(nèi)部保存uvm_object item然后在具體使用點把它$cast成目標類型。這條路的問題在于類型安全性差$cast失敗要到運行期才能發(fā)現(xiàn)而且代碼里到處是類型轉換可讀性差。另一條路是用define宏生成整套代碼。宏替換做的代碼生成雖然也能復制代碼但它繞過了類型檢查、函數(shù)作用域和調試器宏展開的錯誤信息經(jīng)常把真實行號搞沒維護成本非常高。參數(shù)化類把類型作為參數(shù)傳入相當于讓編譯器幫你做類型檢查同時保留一套代碼的維護便利性。你用一份generator的實現(xiàn)就能生成generator#(eth_pkt)、generator#(axi_txn)這些類型特化每個特化都有自己的類型安全約束。4.2 語法拆解類型參數(shù)、整數(shù)參數(shù)、默認值與實例化參數(shù)化類的語法本身并不復雜核心是把參數(shù)列表放在類名后面class generator #(type T uvm_object, int MAX_CNT 100); T current_item; int cnt; function new(string name generator); super.new(name); endfunction task run_phase(uvm_phase phase); repeat (MAX_CNT) begin if (!$cast(current_item, create_item())) begin uvm_fatal(CAST, $sformatf(cannot cast to %s, current_item.get_type_name())) end item_port.write(current_item); end endtask // 由子類重寫 virtual function T create_item(); create_item null; endfunction endclass實例化也沒有特殊之處generator#(eth_pkt) eth_gen; eth_gen generator#(eth_pkt)::type_id::create(eth_gen, this);需要注意幾個細節(jié)。第一參數(shù)列表里type T是類型參數(shù)int MAX_CNT 100是值參數(shù)值參數(shù)必須帶默認值或者在使用時顯式給出否則實例化時編譯器會抱怨參數(shù)不夠。第二參數(shù)化類作為基類使用時子類必須指定參數(shù)不能繼續(xù)留一個未決定的 Tclass eth_generator extends generator#(eth_pkt); virtual function eth_pkt create_item(); eth_pkt p eth_pkt::type_id::create(p); return p; endfunction endclass第三如果你需要在類外前向聲明一個參數(shù)化類語法要寫成typedef class generator#(type T);不過這個寫法在不同仿真器上支持程度不完全一致如果你的仿真器不支持可以考慮換一種設計盡量避免對參數(shù)化類做前向聲明。4.3 參數(shù)化類中的靜態(tài)成員與常見假象參數(shù)化類一個容易出問題的點是static成員。普通類里static成員是全局唯一的參數(shù)化類里的static成員按 SystemVerilog 標準每個特化類型各有自己的一份。class typed_pool #(type T); static int pool_count; endclasstyped_pool#(A)::pool_count和typed_pool#(B)::pool_count是兩個完全獨立的變量。有些人會以為只要是 typed_pool 都是同一個靜態(tài)變量結果 A 類型累加了一個計數(shù)B 類型卻看不到查半天根本原因。這個行為在不同仿真器上曾經(jīng)也有過不一致的 bug如果你要大規(guī)模使用參數(shù)化類的靜態(tài)成員建議在項目初期先做一個最小用例跑一遍目標仿真器確認行為。還有一個常見的假象是兩個不同參數(shù)的特化類不要指望它們之間可以隨意賦值。generator#(eth_pkt)和generator#(axi_txn)是完全不同的類型即使它們的代碼結構一模一樣。如果你想讓它們之間做某種通用操作必須讓它們繼承同一個非參數(shù)化基類。5. 參數(shù)化類 數(shù)據(jù)類型轉換搭建一個類型安全的通用組件5.1 實戰(zhàn)需求一個可以指定事務類型的通用 generator最典型的組合使用場景是搭建一個帶約束的通用 generator它只負責生成、隨機化、發(fā)送對象至于具體生成什么類型的對象由參數(shù)T決定。比如 UART 項目需要一個uart_txn生成器SPI 項目需要一個spi_txn生成器代碼 90% 是重復的。參數(shù)化類把它縮成一份class gen_t #(type T uvm_sequence_item) extends uvm_sequence #(T); constraint c_default { item.size inside {[1:16]}; } virtual task body(); repeat (10) begin uvm_do(item) end endtask endclass這里面的關鍵技術點在于uvm_sequence #(T)的REQ類型已經(jīng)被參數(shù)化為 TUVM 的宏uvm_do(item)會自動對 item 做正確的類型處理。如果不用參數(shù)化類你就得為每個事務類型各寫一個幾乎相同的 sequence 子類或者在基類里寫一個uvm_sequence_item類型的 item然后再在 body 里到處$cast。對象拷貝在這里也有一席之地當你用uvm_do產(chǎn)生一個 item 時UVM 內(nèi)部會調用 clone 將 item 復制到 sequencer 的請求隊列。如果你自己的事務類沒有實現(xiàn)正確的 copy/clone那么 sequence 里生成的事務和 sequencer 實際收到的可能就是兩個不同的東西甚至 field 都是默認值。所以參數(shù)化組件和拷貝機制不是兩個孤立話題它們在你的環(huán)境里始終是一起工作的。5.2 $cast 與靜態(tài)轉換類型轉換在參數(shù)化場景下的正確用法參數(shù)化類里的T雖然類型安全但一旦你把T類型的對象放到一個更通用的容器里比如uvm_object類型的成員或者uvm_tlm_fifo#(uvm_object)取出來的時候仍然要做類型轉換。SV 的對象類型轉換有兩種靜態(tài)轉換語法dst target_type(src)。對數(shù)值類型很常用比如把int轉成bit[7:0]會做截斷把logic[15:0]轉成int可能做位寬擴展。對對象類型靜態(tài)轉換只是一個編譯期的斷言它告訴編譯器請認為這個句柄是目標類型但運行時如果實際類型不匹配行為是未定義的通常會讓仿真崩潰或者返回一個無效的句柄。所以對對象類型進行向下轉換時永遠優(yōu)先用$cast。$cast有兩種用法一種是函數(shù)形式eth_pkt p; if (!$cast(p, obj)) begin uvm_error(CAST, obj is not eth_pkt) end另一種是void $cast(p, obj);用于你確定類型一定匹配、并且不想檢查返回值的場景。前者用于防御式編程后者用于性能敏感且邏輯已保證安全的場景。在參數(shù)化類里因為T是編譯期已知的類型你往往可以直接把uvm_object轉回Tclass consumer_t #(type T uvm_object) extends uvm_component; uvm_tlm_fifo#(uvm_object) fifo; virtual task run_phase(uvm_phase phase); uvm_object obj; T item; fifo.get(obj); if (!$cast(item, obj)) uvm_fatal(TYPE, $sformatf(expect %s, got %s, $typename(T), obj.get_type_name())) // 安全使用 item endtask endclass$typename(T)是調試類型不匹配時的利器編譯期展開成實際的類型名打印出來非常直觀。5.3 在這個組件里如何安全地做對象分發(fā)再進一步參數(shù)化類加上$cast可以寫出很安全的分發(fā)器。比如你有一個uvm_analysis_port#(uvm_object)不同的 monitor 向里面扔不同類型的對象下游的參考模型通過參數(shù)化類只接管自己關心的類型。我這里有一個實際用過的簡化版本。先定義一個參數(shù)化的filter_tclass filter_t #(type T uvm_object) extends uvm_component; T cached; int hit_cnt; int miss_cnt; uvm_component_param_utils(filter_t#(T)) function new(string name, uvm_component parent); super.new(name, parent); endfunction virtual function void write(uvm_object obj); T item; if ($cast(item, obj)) begin cached item; hit_cnt; end else begin miss_cnt; end endfunction virtual function void report_phase(uvm_phase phase); uvm_info(FILTER, $sformatf(hit%0d miss%0d typename%s, hit_cnt, miss_cnt, $typename(T)), UVM_LOW) endfunction endclass把這個類從uvm_subscriber#(uvm_object)派生出來每個組件可以在構造函數(shù)里指定自己的 T。類型匹配的進來類型不匹配的直接過濾。這種模式下對象從上游傳到下游時全程只有一個句柄在流動沒有多余拷貝同時通過$cast保證了類型安全。關于這個組件還有一點值得提醒因為filter_t#(T)的參數(shù)化UVM 的工廠注冊宏要用uvm_component_param_utils而不是uvm_component_utils。UVM 1.2 提供uvm_component_param_utils就是為了適配參數(shù)化類如果你用的是老版本 UVM這個宏可能沒有需要自己手動實現(xiàn)type_id的 create 機制或者退一步用非參數(shù)化的基類加虛函數(shù)。這也是老項目里參數(shù)化類用得少的一個客觀原因。5.4 對象拷貝和數(shù)據(jù)類型轉換的聯(lián)動一個我踩過的假轉換坑最后分享一個把拷貝和類型轉換結合使用時我實際踩過的坑。當時我有一個base_txn里面定義了一個uvm_object_utils宏還有一個copy()方法邏輯看起來沒問題。子類ext_txn繼承它但copy()重寫時只調了super.copy(rhs)忘了復制自己新增的數(shù)組字段。然后在 scoreboard 里我寫了個通用比較邏輯把期望對象和實際對象都塞進一個uvm_object容器里等到比較時再$cast回base_txn。因為兩個對象都是ext_txn類型$cast成功了數(shù)據(jù)比對卻總是失敗。打印出來一個字段是對的另一個字段是默認值。最后定位才發(fā)現(xiàn)不是$cast的問題而是copy()漏字段導致期望隊列里的對象一開始就是殘缺的。這個案例給我的教訓是類型轉換負責分揀拷貝負責內(nèi)容完整分揀成功不代表內(nèi)容正確。排查問題時要分清階段先確認類型對不對再確認數(shù)據(jù)備份有沒有做全。兩者混在一起排查往往會浪費大量時間。6. 從對象拷貝到參數(shù)化類我在項目里用得最順的幾個技巧把前面幾章的東西收攏一下分享幾個我在真實項目里沉淀下來的、直接能用的技巧和習慣。這些內(nèi)容不復雜但確實能幫你少走彎路。第一個技巧給所有 base transaction 實現(xiàn)一個統(tǒng)一的deep_copy()約定。不管項目里有沒有 UVM我都建議在頂層基類里定義一個virtual function void deep_copy(input base_txn rhs)子類重寫時第一句永遠是super.deep_copy(rhs);后面再復制自己的新字段。這樣任何子類對象都能通過基類句柄完成深拷貝不需要在每個場景里做類型分支。第二個技巧拷貝函數(shù)里統(tǒng)一使用copy_to風格即把內(nèi)容填充到已分配的對象里而不是copy返回新對象。返回新對象在語法上更直觀但每次調用都會new()在高頻率的 scoreboard 比對場景里會產(chǎn)生大量對象創(chuàng)建和釋放給仿真器 GC 帶來壓力。copy_to配合對象池能把內(nèi)存分配次數(shù)降下一大截實測在高吞吐場景下仿真速度能有可感知的提升。第三個技巧參數(shù)化類的類名里盡量帶上類型名比如gen_t#(eth_pkt)在打印日志時會顯示gen_t#(eth_pkt)非常利于調試。如果嫌名字長可以在實例化時用typedef起個短名typedef gen_t#(eth_pkt) eth_gen_t;這個短名只在當前作用域生效不污染全局命名空間日志里還能看到完整類型信息兩全其美。第四個技巧多線程共享句柄時把 SV 的 timeslot 調度機制納入考慮。同一個 time slot 內(nèi)fork...join_none啟動的線程和主線程看到的對象狀態(tài)是一致的如果你在子線程里改了對象字段主線程下一行代碼立刻也能看到。這個立刻可見其實經(jīng)常是 copy 漏寫的信號如果你發(fā)現(xiàn)一個對象被多個線程同時修改與其依賴仿真器調度順序不如先檢查是不是某個地方缺少深拷貝。我見過不少偶發(fā)性的 compare mismatch最后都是這個原因。第五個技巧用$typename()打印真實類型尤其是在參數(shù)化類的工廠創(chuàng)建和$cast失敗現(xiàn)場。SV 的內(nèi)建$typename()函數(shù)對參數(shù)化類的輸出比get_type_name()更準確因為get_type_name()在參數(shù)化類里經(jīng)常返回空白或者同一個名字你沒法區(qū)分究竟是哪個參數(shù)特化出來的對象。結合前面的 filter 例子我在所有類型轉換失敗的地方都會打一行$typename(obj)對$typename(T)把實際類型和期望類型擺在一起看基本一眼定位。這些技巧看著零散但背后的核心思想是一致的面向對象驗證代碼的很多 bug本質都是對象身份和對象內(nèi)容這兩件事沒分清楚?？截惤鉀Q的是內(nèi)容獨立參數(shù)化解決的是類型通用$cast解決的是類型安全這三者配合好了驗證組件可以做到又通用又不容易出錯。最后再啰嗦一句SV 的面向對象機制上手語法一天就夠了但真正用得穩(wěn)一定是在項目里一遍遍踩過、觀察過對象生命周期之后。希望這篇從對象拷貝講到參數(shù)化類的文章能幫你少踩幾個我踩過的坑。 SystemVerilog對象拷貝與參數(shù)化類：驗證環(huán)境實戰(zhàn)陷阱解析
做驗證的兄弟應該都撞見過這種鬼打墻的 bug你在 scoreboard 里比較完數(shù)據(jù)順手改了一下某個 transaction 的字段做 debug結果下一拍發(fā)現(xiàn) reference model 那邊的同一筆數(shù)據(jù)也變了。代碼邏輯翻來覆去看了三遍沒有任何人對參考模型寫過數(shù)據(jù)。最后實在沒辦法把兩個對象的地址打出來一看——好家伙根本是同一個對象。這就是 SystemVerilogSV對象拷貝里最經(jīng)典的淺拷貝陷阱你以為是復制了一份數(shù)據(jù)實際上只是復制了一個句柄兩個變量牢牢握著同一塊內(nèi)存。再說到標題里的另一個主角參數(shù)化的類很多朋友剛接觸 SV 面向對象編程時會把它當成 C 模板的低配版簡單用class #(type T int)包一層就覺得完事。實際在驗證環(huán)境里對象拷貝、參數(shù)化類和數(shù)據(jù)類型轉換這三件事是纏在一起的參數(shù)化類經(jīng)常接收不同類型的 transaction而不同類型的對象在發(fā)出去之前往往需要做動態(tài)轉換轉換失敗又可能引出一堆和拷貝相關的連帶問題。這篇文章就把這三件事從原理到實操捋一遍最后再分享幾個我在真實項目里踩過、填過、覺得值得記住的坑。1. 改了 A 卻影響了 B對象拷貝中最常見的句柄共享事故1.1 一個能完美復現(xiàn)問題的最小用例先把問題現(xiàn)場還原出來。假設我們有一個最簡單的包class pkt; int data; int id; endclass然后寫兩行幾乎所有人都寫過的代碼pkt a; pkt b; a new(); a.data 100; a.id 1; b a; // 你以為復制了一份 b.data 200; $display(a.data %0d, b.data %0d, a.data, b.data);這段代碼的打印結果是a.data 200, b.data 200。如果你心里預期的結果是a.data 100那你就撞上了 SV 對象語義里最基礎的一個特點b a并不會創(chuàng)建一個新對象它只是把a這個句柄的值復制給了b兩個名字指到同一個對象上去了。很多從 C 語言或者從 Verilog 的reg、wire思維轉過來的朋友剛開始非常不適應這件事。因為在 C 里結構體變量之間可以直接賦值值是整體搬過去的在 SV 里類變量不是值是引用。你復制引用不會復制對象就像你抄了一份通訊錄的地址不代表你把那個人也復制了一份。1.2 句柄、對象與內(nèi)存地址先把這個基礎焊死要徹底理解對象拷貝必須分清楚三個概念句柄handle、對象object和內(nèi)存地址。我們寫pkt a new();干的事情是在仿真器的堆上創(chuàng)建了一個pkt對象然后把指向這塊內(nèi)存的門牌號存進變量a。a本身不是對象a是一個存放著對象地址的句柄變量。所以在 SV 里兩個句柄指向同一個對象是非常常見、也非常合法的狀態(tài)這不叫兩個一樣的對象而是對同一對象的兩個稱呼。一個更生活化的類比是對象是房子句柄是門牌號。b a只是把門牌號又抄了一份給你兩個人還是拿著同一個門牌號去找同一棟房子。你在房子 A 里重新裝修拿著另一份門牌號的 B 過來看看到的當然也是裝修后的樣子。理解了這一點再看下面這些行為就會很清晰操作結果是否創(chuàng)建新對象b a;b 和 a 指向同一對象否b new(); b.copy(a);b 是新對象成員值來自 a是b a.copy();若實現(xiàn)了 copy 返回新對象是b new a;取決于類中是否定義接收 a 的構造函數(shù)不一定1.3 從共享到獨立究竟差在哪知道了b a是共享句柄之后問題就變成怎么讓兩個對象真正獨立最常見的偷懶寫法是b new(); b.data a.data; b.id a.id;這個寫法對只有兩個成員的類沒有問題但 transaction 的成員通常不止兩三個。典型的一個總線事務對象可能有十幾個字段還有定長數(shù)組、動態(tài)數(shù)組、隊列、事件、其他對象的句柄甚至還要處理嵌套對象。你寫幾次b.xxx a.xxx就知道這種純手工逐字段復制的做法多寫兩個類之后一定會漏字段。前面表格里還提到一種寫法是b new a;這里要特別提醒SystemVerilog 不會像 C 那樣自動給你生成一個以同類對象為入?yún)⒌目截悩嬙旌瘮?shù)。b new a實際調用的是new(a)這個調用能不能編譯、語義是否做拷貝完全取決于類里面有沒有顯式定義一個接收a類型參數(shù)的function new。如果類里沒有定義很多仿真器會直接報錯或者行為未定義如果定義了那也是你寫的邏輯在起作用而不是語言默認幫你拷貝。所以 SV 社區(qū)里最常見的、可移植性最好的拷貝方式是自己實現(xiàn)一個copy()方法不要依賴這種語法糖。2. 淺拷貝和深拷貝的本質new、copy 與 clone 的分工2.1 默認行為解剖為什么 SV 不自動給你一個拷貝構造既然標準庫沒有默認拷貝構造那我們就得自己把拷貝這件事做對。在做之前先明確兩個概念淺拷貝shallow copy和深拷貝deep copy。淺拷貝的定義是新對象創(chuàng)建出來后每個成員變量的值都復制了一遍。這句話聽起來很簡單但有一個埋伏如果某個成員本身是另一個對象句柄那么復制這個句柄的值只是讓新對象和舊對象指向同一個子對象。舉個例子class addr_t; int addr; endclass class pkt; int id; addr_t addr; endclass如果我們寫一個淺拷貝函數(shù)function pkt shallow_copy(); shallow_copy new(); shallow_copy.id this.id; shallow_copy.addr this.addr; // 只復制了句柄兩個對象的 addr 還是同一個 endfunction那么復制出來的pkt對象它的addr成員和原來的addr成員仍然共享同一個addr_t對象。這不一定都是壞事但它一定是你需要明確知道的語義。如果你在復制后把那邊的addr.addr改了這邊的也會跟著改。深拷貝則是不僅復制頂層對象還要把頂層對象手里所有的子對象、數(shù)組元素、隊列元素等全部遞歸復制一遍。深拷貝之后新舊對象之間除了字段值相同再沒有任何共享內(nèi)存。2.2 自實現(xiàn) copy 函數(shù)處理基本成員、對象成員與隊列成員在 SV 里一個可復用的深拷貝函數(shù)通常按下面幾步來寫。第一步處理所有內(nèi)建值類型成員int、bit、logic、enum、string等。這些直接賦值即可。第二步處理對象引用成員。對每個類成員要么調用它自己的copy()方法要么new()一個新的再逐字段賦值。第三步處理動態(tài)數(shù)組、隊列、關聯(lián)數(shù)組。這一步最容易被漏。因為 SV 的數(shù)組賦值是比較智能的直接new_array old_array可以復制整個數(shù)組內(nèi)容所以不少人以為隊列也可以直接賦值就完事了。對動態(tài)數(shù)組和隊列來說直接賦值確實會復制元素但如果元素本身是對象句柄那復制的是句柄數(shù)組數(shù)組里的對象仍然是共享的。想深拷貝數(shù)組對象得用循環(huán)逐個 deep copy。第四步處理可能存在的自引用和循環(huán)引用。比如類 A 里有一個A next成員深拷貝時如果不加判斷會無限遞歸下去。簡單場景可以約定好只深拷貝數(shù)據(jù)對象不深拷貝連接關系復雜場景可以維護一個已經(jīng)拷貝過的舊對象到新對象的映射表碰到已拷貝過的對象直接返回已有副本。一個比較完整的手寫深拷貝模板如下class pkt; int id; string name; int payload[$]; addr_t addr; bit has_addr; function pkt copy(); pkt c new(); c.id this.id; c.name this.name; c.payload this.payload; // 隊列整體復制元素是 int沒問題 if (this.has_addr) begin c.addr new(); c.addr.addr this.addr.addr; end c.has_addr this.has_addr; return c; endfunction function void copy_to(pkt rhs); rhs.id this.id; rhs.name this.name; rhs.payload this.payload; if (this.has_addr) begin if (rhs.addr null) rhs.addr new(); rhs.addr.addr this.addr.addr; end rhs.has_addr this.has_addr; endfunction endclass這里我故意寫了兩個函數(shù)一個copy()返回新對象一個copy_to(rhs)把內(nèi)容復制到一個已存在的對象。為什么需要兩個因為驗證環(huán)境里兩種場景都有scoreboard 里希望再搞一個一樣的對象存起來用copy()driver 里希望把已經(jīng)創(chuàng)建好的對象內(nèi)容更新一下用copy_to()更省內(nèi)存。2.3 UVM 環(huán)境里 copy/clone 的常見約定如果你已經(jīng)在用 UVM很多對象繼承自uvm_objectUVM 自己有一套拷貝機制。核心是兩個 virtual 方法copy和clone。默認行為是copy調用do_copyclone創(chuàng)建新對象后調用copy。如果你的類沒有實現(xiàn)do_copy那么copy什么都不做clone只會返回一個空對象。UVM 的uvm_object_utils宏配合 field automation 時copy會按照字段宏定義逐個復制。但這里有個容易忽略的點field automation 對對象字段比如uvm_object_field默認只復制句柄也就是淺拷貝。你聲明了uvm_object_utils不代表自動深拷貝要深拷貝嵌套對象必須在do_copy里顯式處理或者約定好被嵌套對象不可變。我見過不少團隊在項目手里的 base transaction 里實現(xiàn)一次完整的深拷貝copy然后所有派生事務類在重寫do_copy時先super.do_copy(rhs)再補自己新增的字段。這個思路簡單又不容易漏推薦給還沒形成規(guī)范的項目。3. 驗證環(huán)境里對象拷貝的實戰(zhàn)位置從 driver 到 scoreboard3.1 transaction 對象在組件間流動時哪些環(huán)節(jié)必須拷貝搞清楚了拷貝的機制再把它放進完整驗證環(huán)境的上下文里。一個典型的約束隨機驗證平臺里transaction 對象是這樣流動的generator 生成對象通過 sequencer/driver 轉成接口信號monitor 從接口采樣得到對象發(fā)給 scoreboard 和 reference model。在這條鏈路上并不是每個環(huán)節(jié)都要拷貝。需要拷貝的地方通常是這兩類第一類是存檔場景。scoreboard 里經(jīng)常需要一個期望值隊列把進入 DUT 之前的數(shù)據(jù)包保存起來等 DUT 輸出再做比對。如果直接把 generator 的那個句柄塞進隊列后續(xù) driver 把同一對象改掉scoreboard 里存的東西也被改了比對就全面失真。這種場景必須深拷貝一份再入隊。第二類是并發(fā)處理場景。一個事務對象同時被多個 component 處理時如果 A 組件要對它做標記、加字段、改狀態(tài)而 B 組件希望看到原始狀態(tài)那么必須先復制出一份獨立對象給 A 用。不復制的話A 的修改會像一個全局變量一樣毒化所有引用者。不需要拷貝的場景interface 信號驅動、mailbox 的純傳遞、只讀的數(shù)據(jù)分析。在這些場景里拷貝純屬浪費仿真時間和內(nèi)存。3.2 mailbox 傳輸?shù)目截惻c否一種常見的性能與正確性權衡mailbox 是 SV 里最常用的線程間通信手段但它傳遞的同樣只是句柄。很多人也有一個疑問把對象放進 mailbox要不要先 copy 一份答案取決于接收方是否會修改對象。如果接收方拿到對象后只是讀取并轉換成信號那么不拷貝沒有任何問題還更高效。如果接收方拿到后要修改并且發(fā)送方之后還會用這個對象那么不拷貝就有隱患。一個比較穩(wěn)妥的約定是發(fā)送方一旦把對象放進 mailbox就視為所有權移交。后續(xù)想再保留數(shù)據(jù)發(fā)送方在 put 之前自己先深拷貝留存接收方擁有對對象的修改權。這樣責任邊界清晰不容易出現(xiàn)兩邊同時改一個對象的競爭。一個額外提醒如果發(fā)送方在循環(huán)中重復使用同一個句柄發(fā)數(shù)據(jù)比如forever begin trans new(); // 隨機化、填充字段 mb.put(trans); end這種情況每次都是新對象不需要拷貝。但如果是復用同一個對象forever begin // 不重新 new只改改字段再發(fā) trans.data data; mb.put(trans); end接收方拿到的每一個包實際上都是同一個對象。等下一個循環(huán)改了data已經(jīng)進入 mailbox 的包也會跟著變。這種 bug 比淺拷貝更隱蔽因為它看起來是每一包數(shù)據(jù)都一樣而不是某一包被篡改。排查到最后往往要打地址才會恍然大誤所有包全是一個地址。3.3 拷貝實踐中的典型錯誤與查驗習慣我在實際項目里見到的、以及自己犯過的典型錯誤大致有這么幾類第一類定義了copy()但忘記維護新增字段。類加了一個新字段copy()沒同步更新導致復制出來的對象某些字段是默認值。這個錯誤平時很難發(fā)現(xiàn)因為大多數(shù)時候你不比對每個字段只有在某個用例數(shù)據(jù)恰好依賴那個字段時才爆發(fā)。應對辦法每次改 transaction 類時強制看一眼copy/do_copy方法或者干脆在 base 類里加一個自查方法比較兩個對象所有字段是否一致測試時點用一下。第二類把淺拷貝當深拷貝用。對象成員、動態(tài)數(shù)組里的對象元素都沒復制導致所有引用者共享子對象。尤其 UVM 的 field automation 默認淺拷貝這個坑非常容易踩。寫代碼前先問自己一句這個對象會不會在被復制之后繼續(xù)被別人改如果會請確認嵌套成員都是深拷貝。第三類拷貝后忘記恢復隨機化狀態(tài)。SV 類的randomize()每次調用都會重新隨機如果拷貝函數(shù)內(nèi)部動不動new()出一個新對象把原來已經(jīng)滿足約束的數(shù)據(jù)覆蓋成隨機值就會出現(xiàn)比較不過但不知道哪里錯的詭異問題?？截惡瘮?shù)要嚴格只復制、不隨機。檢驗拷貝是否深的一個好辦法復制后把舊對象里最內(nèi)層的一個字段改掉看新對象是否跟著變。寫一個調試用的check_independent()函數(shù)在測試環(huán)境常駐比事后排查省時間得多。4. 參數(shù)化類把一類多用寫進類型系統(tǒng)4.1 參數(shù)化類解決了什么痛點對比宏定義和基礎類繼承對象拷貝解決的是內(nèi)容獨立參數(shù)化類解決的是類型通用。兩者在驗證組件復用里經(jīng)常遇到。假設你要寫一個通用的generator它可以產(chǎn)生eth_pkt也可以產(chǎn)生axi_txn還可以產(chǎn)生i2c_seq。不用參數(shù)化的時候有兩條路一條路是寫一個以uvm_object為基類的通用類內(nèi)部保存uvm_object item然后在具體使用點把它$cast成目標類型。這條路的問題在于類型安全性差$cast失敗要到運行期才能發(fā)現(xiàn)而且代碼里到處是類型轉換可讀性差。另一條路是用define宏生成整套代碼。宏替換做的代碼生成雖然也能復制代碼但它繞過了類型檢查、函數(shù)作用域和調試器宏展開的錯誤信息經(jīng)常把真實行號搞沒維護成本非常高。參數(shù)化類把類型作為參數(shù)傳入相當于讓編譯器幫你做類型檢查同時保留一套代碼的維護便利性。你用一份generator的實現(xiàn)就能生成generator#(eth_pkt)、generator#(axi_txn)這些類型特化每個特化都有自己的類型安全約束。4.2 語法拆解類型參數(shù)、整數(shù)參數(shù)、默認值與實例化參數(shù)化類的語法本身并不復雜核心是把參數(shù)列表放在類名后面class generator #(type T uvm_object, int MAX_CNT 100); T current_item; int cnt; function new(string name generator); super.new(name); endfunction task run_phase(uvm_phase phase); repeat (MAX_CNT) begin if (!$cast(current_item, create_item())) begin uvm_fatal(CAST, $sformatf(cannot cast to %s, current_item.get_type_name())) end item_port.write(current_item); end endtask // 由子類重寫 virtual function T create_item(); create_item null; endfunction endclass實例化也沒有特殊之處generator#(eth_pkt) eth_gen; eth_gen generator#(eth_pkt)::type_id::create(eth_gen, this);需要注意幾個細節(jié)。第一參數(shù)列表里type T是類型參數(shù)int MAX_CNT 100是值參數(shù)值參數(shù)必須帶默認值或者在使用時顯式給出否則實例化時編譯器會抱怨參數(shù)不夠。第二參數(shù)化類作為基類使用時子類必須指定參數(shù)不能繼續(xù)留一個未決定的 Tclass eth_generator extends generator#(eth_pkt); virtual function eth_pkt create_item(); eth_pkt p eth_pkt::type_id::create(p); return p; endfunction endclass第三如果你需要在類外前向聲明一個參數(shù)化類語法要寫成typedef class generator#(type T);不過這個寫法在不同仿真器上支持程度不完全一致如果你的仿真器不支持可以考慮換一種設計盡量避免對參數(shù)化類做前向聲明。4.3 參數(shù)化類中的靜態(tài)成員與常見假象參數(shù)化類一個容易出問題的點是static成員。普通類里static成員是全局唯一的參數(shù)化類里的static成員按 SystemVerilog 標準每個特化類型各有自己的一份。class typed_pool #(type T); static int pool_count; endclasstyped_pool#(A)::pool_count和typed_pool#(B)::pool_count是兩個完全獨立的變量。有些人會以為只要是 typed_pool 都是同一個靜態(tài)變量結果 A 類型累加了一個計數(shù)B 類型卻看不到查半天根本原因。這個行為在不同仿真器上曾經(jīng)也有過不一致的 bug如果你要大規(guī)模使用參數(shù)化類的靜態(tài)成員建議在項目初期先做一個最小用例跑一遍目標仿真器確認行為。還有一個常見的假象是兩個不同參數(shù)的特化類不要指望它們之間可以隨意賦值。generator#(eth_pkt)和generator#(axi_txn)是完全不同的類型即使它們的代碼結構一模一樣。如果你想讓它們之間做某種通用操作必須讓它們繼承同一個非參數(shù)化基類。5. 參數(shù)化類 數(shù)據(jù)類型轉換搭建一個類型安全的通用組件5.1 實戰(zhàn)需求一個可以指定事務類型的通用 generator最典型的組合使用場景是搭建一個帶約束的通用 generator它只負責生成、隨機化、發(fā)送對象至于具體生成什么類型的對象由參數(shù)T決定。比如 UART 項目需要一個uart_txn生成器SPI 項目需要一個spi_txn生成器代碼 90% 是重復的。參數(shù)化類把它縮成一份class gen_t #(type T uvm_sequence_item) extends uvm_sequence #(T); constraint c_default { item.size inside {[1:16]}; } virtual task body(); repeat (10) begin uvm_do(item) end endtask endclass這里面的關鍵技術點在于uvm_sequence #(T)的REQ類型已經(jīng)被參數(shù)化為 TUVM 的宏uvm_do(item)會自動對 item 做正確的類型處理。如果不用參數(shù)化類你就得為每個事務類型各寫一個幾乎相同的 sequence 子類或者在基類里寫一個uvm_sequence_item類型的 item然后再在 body 里到處$cast。對象拷貝在這里也有一席之地當你用uvm_do產(chǎn)生一個 item 時UVM 內(nèi)部會調用 clone 將 item 復制到 sequencer 的請求隊列。如果你自己的事務類沒有實現(xiàn)正確的 copy/clone那么 sequence 里生成的事務和 sequencer 實際收到的可能就是兩個不同的東西甚至 field 都是默認值。所以參數(shù)化組件和拷貝機制不是兩個孤立話題它們在你的環(huán)境里始終是一起工作的。5.2 $cast 與靜態(tài)轉換類型轉換在參數(shù)化場景下的正確用法參數(shù)化類里的T雖然類型安全但一旦你把T類型的對象放到一個更通用的容器里比如uvm_object類型的成員或者uvm_tlm_fifo#(uvm_object)取出來的時候仍然要做類型轉換。SV 的對象類型轉換有兩種靜態(tài)轉換語法dst target_type(src)。對數(shù)值類型很常用比如把int轉成bit[7:0]會做截斷把logic[15:0]轉成int可能做位寬擴展。對對象類型靜態(tài)轉換只是一個編譯期的斷言它告訴編譯器請認為這個句柄是目標類型但運行時如果實際類型不匹配行為是未定義的通常會讓仿真崩潰或者返回一個無效的句柄。所以對對象類型進行向下轉換時永遠優(yōu)先用$cast。$cast有兩種用法一種是函數(shù)形式eth_pkt p; if (!$cast(p, obj)) begin uvm_error(CAST, obj is not eth_pkt) end另一種是void $cast(p, obj);用于你確定類型一定匹配、并且不想檢查返回值的場景。前者用于防御式編程后者用于性能敏感且邏輯已保證安全的場景。在參數(shù)化類里因為T是編譯期已知的類型你往往可以直接把uvm_object轉回Tclass consumer_t #(type T uvm_object) extends uvm_component; uvm_tlm_fifo#(uvm_object) fifo; virtual task run_phase(uvm_phase phase); uvm_object obj; T item; fifo.get(obj); if (!$cast(item, obj)) uvm_fatal(TYPE, $sformatf(expect %s, got %s, $typename(T), obj.get_type_name())) // 安全使用 item endtask endclass$typename(T)是調試類型不匹配時的利器編譯期展開成實際的類型名打印出來非常直觀。5.3 在這個組件里如何安全地做對象分發(fā)再進一步參數(shù)化類加上$cast可以寫出很安全的分發(fā)器。比如你有一個uvm_analysis_port#(uvm_object)不同的 monitor 向里面扔不同類型的對象下游的參考模型通過參數(shù)化類只接管自己關心的類型。我這里有一個實際用過的簡化版本。先定義一個參數(shù)化的filter_tclass filter_t #(type T uvm_object) extends uvm_component; T cached; int hit_cnt; int miss_cnt; uvm_component_param_utils(filter_t#(T)) function new(string name, uvm_component parent); super.new(name, parent); endfunction virtual function void write(uvm_object obj); T item; if ($cast(item, obj)) begin cached item; hit_cnt; end else begin miss_cnt; end endfunction virtual function void report_phase(uvm_phase phase); uvm_info(FILTER, $sformatf(hit%0d miss%0d typename%s, hit_cnt, miss_cnt, $typename(T)), UVM_LOW) endfunction endclass把這個類從uvm_subscriber#(uvm_object)派生出來每個組件可以在構造函數(shù)里指定自己的 T。類型匹配的進來類型不匹配的直接過濾。這種模式下對象從上游傳到下游時全程只有一個句柄在流動沒有多余拷貝同時通過$cast保證了類型安全。關于這個組件還有一點值得提醒因為filter_t#(T)的參數(shù)化UVM 的工廠注冊宏要用uvm_component_param_utils而不是uvm_component_utils。UVM 1.2 提供uvm_component_param_utils就是為了適配參數(shù)化類如果你用的是老版本 UVM這個宏可能沒有需要自己手動實現(xiàn)type_id的 create 機制或者退一步用非參數(shù)化的基類加虛函數(shù)。這也是老項目里參數(shù)化類用得少的一個客觀原因。5.4 對象拷貝和數(shù)據(jù)類型轉換的聯(lián)動一個我踩過的假轉換坑最后分享一個把拷貝和類型轉換結合使用時我實際踩過的坑。當時我有一個base_txn里面定義了一個uvm_object_utils宏還有一個copy()方法邏輯看起來沒問題。子類ext_txn繼承它但copy()重寫時只調了super.copy(rhs)忘了復制自己新增的數(shù)組字段。然后在 scoreboard 里我寫了個通用比較邏輯把期望對象和實際對象都塞進一個uvm_object容器里等到比較時再$cast回base_txn。因為兩個對象都是ext_txn類型$cast成功了數(shù)據(jù)比對卻總是失敗。打印出來一個字段是對的另一個字段是默認值。最后定位才發(fā)現(xiàn)不是$cast的問題而是copy()漏字段導致期望隊列里的對象一開始就是殘缺的。這個案例給我的教訓是類型轉換負責分揀拷貝負責內(nèi)容完整分揀成功不代表內(nèi)容正確。排查問題時要分清階段先確認類型對不對再確認數(shù)據(jù)備份有沒有做全。兩者混在一起排查往往會浪費大量時間。6. 從對象拷貝到參數(shù)化類我在項目里用得最順的幾個技巧把前面幾章的東西收攏一下分享幾個我在真實項目里沉淀下來的、直接能用的技巧和習慣。這些內(nèi)容不復雜但確實能幫你少走彎路。第一個技巧給所有 base transaction 實現(xiàn)一個統(tǒng)一的deep_copy()約定。不管項目里有沒有 UVM我都建議在頂層基類里定義一個virtual function void deep_copy(input base_txn rhs)子類重寫時第一句永遠是super.deep_copy(rhs);后面再復制自己的新字段。這樣任何子類對象都能通過基類句柄完成深拷貝不需要在每個場景里做類型分支。第二個技巧拷貝函數(shù)里統(tǒng)一使用copy_to風格即把內(nèi)容填充到已分配的對象里而不是copy返回新對象。返回新對象在語法上更直觀但每次調用都會new()在高頻率的 scoreboard 比對場景里會產(chǎn)生大量對象創(chuàng)建和釋放給仿真器 GC 帶來壓力。copy_to配合對象池能把內(nèi)存分配次數(shù)降下一大截實測在高吞吐場景下仿真速度能有可感知的提升。第三個技巧參數(shù)化類的類名里盡量帶上類型名比如gen_t#(eth_pkt)在打印日志時會顯示gen_t#(eth_pkt)非常利于調試。如果嫌名字長可以在實例化時用typedef起個短名typedef gen_t#(eth_pkt) eth_gen_t;這個短名只在當前作用域生效不污染全局命名空間日志里還能看到完整類型信息兩全其美。第四個技巧多線程共享句柄時把 SV 的 timeslot 調度機制納入考慮。同一個 time slot 內(nèi)fork...join_none啟動的線程和主線程看到的對象狀態(tài)是一致的如果你在子線程里改了對象字段主線程下一行代碼立刻也能看到。這個立刻可見其實經(jīng)常是 copy 漏寫的信號如果你發(fā)現(xiàn)一個對象被多個線程同時修改與其依賴仿真器調度順序不如先檢查是不是某個地方缺少深拷貝。我見過不少偶發(fā)性的 compare mismatch最后都是這個原因。第五個技巧用$typename()打印真實類型尤其是在參數(shù)化類的工廠創(chuàng)建和$cast失敗現(xiàn)場。SV 的內(nèi)建$typename()函數(shù)對參數(shù)化類的輸出比get_type_name()更準確因為get_type_name()在參數(shù)化類里經(jīng)常返回空白或者同一個名字你沒法區(qū)分究竟是哪個參數(shù)特化出來的對象。結合前面的 filter 例子我在所有類型轉換失敗的地方都會打一行$typename(obj)對$typename(T)把實際類型和期望類型擺在一起看基本一眼定位。這些技巧看著零散但背后的核心思想是一致的面向對象驗證代碼的很多 bug本質都是對象身份和對象內(nèi)容這兩件事沒分清楚?？截惤鉀Q的是內(nèi)容獨立參數(shù)化解決的是類型通用$cast解決的是類型安全這三者配合好了驗證組件可以做到又通用又不容易出錯。最后再啰嗦一句SV 的面向對象機制上手語法一天就夠了但真正用得穩(wěn)一定是在項目里一遍遍踩過、觀察過對象生命周期之后。希望這篇從對象拷貝講到參數(shù)化類的文章能幫你少踩幾個我踩過的坑。