1. 從“并發(fā)”說起為什么SV驗證繞不開這些基礎做驗證做了這么多年我一直有個感覺System Verilog入門階段最容易被忽視、但后來越來越覺得重要的就是并發(fā)與線程同步。前面筆記里我們聊過數(shù)據(jù)類型、接口、類、隨機化、覆蓋率這些基本上都是在搭建“單兵作戰(zhàn)”的能力——一個sequence怎么組織、一個driver怎么驅動、一個monitor怎么采樣。但到了真實項目里驗證環(huán)境從來不是單線程跑的激勵要一直發(fā)監(jiān)測要一直開參考模型要一直算計分板要一直比。這些任務如果不并發(fā)執(zhí)行仿真效率會低到讓人懷疑人生。所以這篇筆記想跟你聊聊我眼中SV里最核心、也最容易被新手搞混的并發(fā)基礎線程的創(chuàng)建與調度、fork-join家族的三種模式、以及事件、信箱、信號量這“三件套”。它們解決的問題很實際——怎么讓多個任務同時跑起來怎么安全地交換數(shù)據(jù)怎么協(xié)調上下游的節(jié)奏。標題雖然掛著“學習筆記9”的編號但我寫的時候盡量按“能直接抄進環(huán)境里用”的標準來代碼片段都是我在實際環(huán)境里跑過或者踩過坑的不是那種只能看書不能落地的例子。適合讀這篇的人我覺得有兩類一類是剛把SV語法過完一遍準備寫真正的驗證組件但看到fork和join就發(fā)怵的入門者另一類是已經(jīng)寫了些環(huán)境但偶爾會出現(xiàn)“數(shù)據(jù)比來比去對不上查了半天原來是同步姿態(tài)出了問題”的同行。前者可以從頭讀完后者可以直接跳到問題排查那一節(jié)對照看看。至于純做數(shù)字前端設計、不怎么接觸驗證的同學這篇對你可能幫助有限但如果你要跟驗證工程師聯(lián)調了解這些基礎也能讓你在debug時更清楚對方在忙什么。2. 線程建模的底層邏輯2.1 從程序塊到動態(tài)線程System Verilog里的“線程”簡單說就是一段可以獨立調度執(zhí)行的代碼流。它不是操作系統(tǒng)里的那種重量級線程而是仿真器調度器管理的一個執(zhí)行單元——每一次initial塊、always塊、fork...join塊、fork...join_none塊、fork...join_any塊的執(zhí)行體都會在仿真時間軸上產(chǎn)生一個或多個線程。理解這一點很關鍵因為仿真器本質上是一個離散事件驅動的調度器它把事件分成active、inactive、NBA、observe、reactive等不同region在每個時間片按優(yōu)先級逐層處理。線程不是“同時跑”而是“輪著跑”只不過切換速度快到你感覺不到。這個特性和軟件線程有相似之處但調度模型完全不同不能用寫Linux多線程的思路硬套。模塊里的initial和always是最早接觸的線程形式。initial塊在0時刻開始執(zhí)行執(zhí)行完就結束always塊則是死循環(huán)靠事件觸發(fā)生效。到了class環(huán)境里我們很少直接在模塊里寫一堆always更多是用fork...join塊在task里開并發(fā)線程。比如我常寫的driver run_phase里通常會fork出兩個線程一個處理reset一個處理正常激勵這樣復位和業(yè)務并行互不干擾。需要注意的點是SV的線程都是“軟”的它受仿真時間驅動也受事件調度順序影響。如果你在同一個時間槽里fork了多個線程它們的執(zhí)行順序并不是“寫在前面的先跑”而是取決于你觸發(fā)的region和優(yōu)先級。這也是為什么很多人第一次看到$display亂序會一臉懵——不是寫錯了是調度順序和直覺不一樣。想控制順序就得靠后面會聊到的(event)、semaphore、mailbox來人為加同步。2.2 線程的生命周期與會話控制線程從被創(chuàng)建那一刻起就進入仿真器的調度隊列。它的生命周期可以很短比如一個發(fā)完激勵就退出的線程也可以很長比如一個用于持續(xù)采樣的monitor線程從仿真開始一直活著到$finish?？刂凭€程生命周期的核心手段就是fork塊的模式選擇。一個常見的坑是fork塊里開的線程如果不加控制父線程退出時子線程并不會自動殺掉。這就像你在公司開了一堆子任務自己先下班了活兒還掛在那沒人管。在驗證環(huán)境里這會導致某些線程在test_done之后還試圖訪問已經(jīng)銷毀的對象輕則仿真警告重則產(chǎn)生意外的數(shù)據(jù)競爭。所以我個人習慣是能收斂的線程盡量收斂不能收斂的也要在shutdown階段做一次統(tǒng)一的kill或wait避免野線程殘留在環(huán)境里。另外還要提醒一句線程里如果用了局部變量要搞清楚這個變量是靜態(tài)的還是自動的。class方法里的變量默認是自動存儲但如果你在fork塊里引用循環(huán)變量并且該變量是靜態(tài)存儲那么所有子線程看到的可能是同一個變量的最終值——這就是經(jīng)典的“fork里所有線程拿到的i都一樣”問題。解決辦法要么用automatic變量拷貝要么在fork前先把值存到局部變量里再傳進去。這個坑我在后文會專門展示。3. fork-join家族三種模式怎么選3.1 三種模式的行為差異與最佳實踐fork-join家族在SV里就三個成員join、join_any、join_none。它們的區(qū)別一句話就能講清楚父線程到底等不等子線程。join等所有子線程都跑完父線程才繼續(xù)。適合“并發(fā)收集完畢再做后續(xù)處理”的場景比如同時采樣多個接口都采樣完了統(tǒng)一比對。join_any只要任意一個子線程先完成父線程就繼續(xù)其他子線程繼續(xù)在后臺跑。適合“誰先到誰先服務”的場景比如等多個握手信號任意一個先到就立即響應。join_none父線程根本不等fork完自己立刻往下走子線程在后臺跑。適合“發(fā)起即忘”的后臺任務比如開一個持續(xù)監(jiān)視器或者啟動一個獨立的統(tǒng)計線程。實際項目里我最常用的是join_none和join_any。join其實用得少因為它會讓父線程阻塞到所有子線程結束在很多場景下反而拖慢了節(jié)奏。比如我想同時啟動driver、monitor、reference model三個線程肯定不希望它們全跑完才繼續(xù)——那環(huán)境就串行了。這時候用join_none開三個后臺線程父線程run_phase繼續(xù)往下走子線程各自干活是標準打法。但join_none也有副作用你不好掌控這些后臺線程到底啥時候干完。所以通常我會配合一個wait語句或者一個done標志來收斂。比如fork...join_none啟動采集線程后接著一個wait(collect_done)等到采集完成再往下走。這樣既享受了并發(fā)的效率又保住了可控性。下面給一個簡單的選擇對照方便你們以后直接抄場景推薦模式原因并發(fā)采樣多路數(shù)據(jù)全部完成后再處理fork...join保證所有數(shù)據(jù)就緒等待多個事件任意一個觸發(fā)就繼續(xù)fork...join_any響應最快的事件在后臺啟動長期運行的監(jiān)視線程fork...join_none父線程不阻塞監(jiān)視線程獨立存活需要啟動一組任務但不關心它們什么時候結束fork...join_none最大程度并發(fā)父線程任務繼續(xù)3.2 fork-join結合disable與wait fork的實戰(zhàn)姿勢fork塊用得多了光會開線程還不夠還得會關線程、等線程。SV提供了一組配套控制手段其中最常用的是disable fork和wait fork。disable fork的作用是殺掉當前線程派生的所有子線程。注意是“當前線程派生的所有子線程”不是全局殺。這給了我們很細粒度的控制例如在reset階段我想把之前開出來的激勵線程全部終止掉重新來過就可以在reset任務里調用disable fork。但有個坑disable fork連自己所在線程派生的“兄弟線程”也會殺掉如果你在父線程里先fork了采集線程A再fork采集線程B然后想單獨殺掉B直接disable fork會把A也帶走。所以更安全的做法是給每個fork塊命名或者用disable 標簽來精準控制。wait fork則是反過來它會讓當前線程等待所有由它派生的子線程執(zhí)行完畢。這個在shutdown階段特別好用——保證環(huán)境里沒有遺留的未完成任務。但wait fork只能等“當前線程派生的”如果你在某個fork_none塊里又開了孫線程孫線程的狀態(tài)wait fork管不著需要額外設計。我自己的習慣是在每個phase結束時先disable fork再wait fork雙保險。雖然有點“一刀切”的粗暴但對大多數(shù)環(huán)境來說是夠用的。如果遇到需要精細控制多級線程的場景我建議你在fork塊上明確標注名字然后精準enable/disable不要怕代碼啰嗦debug時你會感謝當時的自己。這里還要提醒一個常見的坑fork_none創(chuàng)建的子線程里如果引用了調用者棧上的變量可能在父線程退出后就失效了。SV的class方法是自動存儲但如果子線程訪問的是一個靜態(tài)變量那它拿到的是全局共享的一份拷貝。想要每個線程都拿到獨立的當前值一定要把數(shù)據(jù)在fork之前通過參數(shù)傳進去或者用automatic變量重新聲明一份。下面給一個演示代碼你們可以自己跑一下感受差異task automatic test_fork_value(); for (int i 0; i 3; i) begin fork automatic int j i; begin #10; $display(fork with automatic j%0d, j); end join_none end #50; endtask如果不用automatic int j而是直接引用i你會發(fā)現(xiàn)三個線程打印出來的都是3因為循環(huán)變量i在迭代結束后保留的是最終值。這是SV里特別經(jīng)典的“閉包陷阱”寫并發(fā)代碼時一定要格外留意。4. 線程間的“三件套”event、semaphore、mailbox4.1 event最輕量的同步原語event是三種同步機制里最輕量的適合做“事件通知”。一個線程等待某個事件另一個線程觸發(fā)事件兩者之間通過事件完成握手。它的使用方式很簡單event e1; task wait_event(); (e1); $display(event received at %0t, $time); endtask task trigger_event(); #10; - e1; endtask上面代碼里wait_event線程會在(e1)處掛起直到trigger_event線程執(zhí)行-e1后才會繼續(xù)。注意事件觸發(fā)是瞬時的如果wait_event還沒執(zhí)行到(e1)觸發(fā)就已經(jīng)發(fā)生了那么這個事件就“錯過”了wait_event會永遠等下去。這就是所謂的“事件丟失”問題。想避免這個要么用電平方式的觸發(fā)要么用event的triggered屬性配合wait語句來檢測。我用event最多的場景是phase之間的先后控制。比如在driver里復位任務執(zhí)行完之后觸發(fā)一個reset_done事件后面需要等待復位完成的sequence就會等待這個事件。事件本身不攜帶數(shù)據(jù)它只傳達“某個時間點發(fā)生了某事”所以它不適合傳數(shù)據(jù)傳數(shù)據(jù)應該用mailbox。還有一個使用細節(jié)event有兩種等待方式一種是用一種是用wait(e.triggered)。的靈敏度是邊沿wait是電平檢查。如果你在同一個時間槽里又想觸發(fā)又想等待可能出現(xiàn)競態(tài)。我的經(jīng)驗是跨線程同步用wait(e.triggered)比用更穩(wěn)因為wait不會錯過事件只要檢查到曾經(jīng)被觸發(fā)過就會立即返回。4.2 semaphore控制資源訪問的神器semaphore最早的感覺就是“票務系統(tǒng)”。它維護一個整數(shù)計數(shù)線程想要進入臨界區(qū)就先key.get()用完再key.put()計數(shù)不夠時線程被阻塞。這個過程和操作系統(tǒng)的信號量概念一致只是SV里已經(jīng)封裝好了不需要我們自己用鎖去實現(xiàn)。我在總線建模里用semaphore非常多。比如一個AHB總線模型多個master通過它發(fā)起訪問但物理總線只有一個不能讓兩個master同時驅動總線。semaphore的初始值為1每個master訪問前先拿key用完歸還這樣天然地保證了同一時刻只有一個master持有總線控制權。如果某個master拿到key后長時間不歸還其他master就只能等著——這時候要小心死鎖尤其是在帶分支判斷的代碼里千萬別忘了在return之前釋放key。semaphore的另一個用法是做“資源池”。初始化時給多個key表示有多個同類型資源可用。比如你有四個DMA通道可以分給四個不同的agent使用。這樣做的好處是資源和任務之間的映射關系完全由semaphore協(xié)調代碼邏輯清晰不需要自己維護一套狀態(tài)機。semaphore bus_lock new(1); task automatic master_access(int id); bus_lock.get(); $display(master %0d acquired bus at %0t, id, $time); #20; bus_lock.put(); $display(master %0d released bus at %0t, id, $time); endtask這段代碼里兩個master同時調用master_access你會看到第二個master會在get處等20個時間單位直到第一個master釋放后才開始。這種串行化的效果正是我們想要的。4.3 mailbox數(shù)據(jù)搬運和線程解耦mailbox本質上是一個線程安全的隊列一個線程往里放數(shù)據(jù)另一個線程從里面取數(shù)據(jù)。它有兩種用法有界和無界。無界mailbox可以無限放數(shù)據(jù)只受仿真內存限制有界mailbox在創(chuàng)建時指定容量放滿后put會阻塞取空后get會阻塞。我在參考模型到計分板的數(shù)據(jù)通路中最常用的是有界mailbox。參考模型算出一個期望值就塞進mailbox計分板線程從mailbox里取出來和DUT采集到的實際值比對。如果參考模型跑得比DUT快mailbox滿了之后put會被阻塞這相當于一個自然的背壓防止數(shù)據(jù)無限堆積如果DUT跑得快計分板取數(shù)據(jù)會有等待但不會丟數(shù)據(jù)。這種機制讓兩邊可以被適度解耦時序上不用精確對齊。mailbox還有個特性它內部可以帶一個內置的semaphore所以多個生產(chǎn)者和多個消費者并發(fā)訪問時數(shù)據(jù)不會錯亂。這一點在我之前沒仔細想后來在寫多通道環(huán)境時深有體會——如果用簡單隊列自己實現(xiàn)多寫多讀很容易出問題而用mailbox就省了很多事。mailbox #(transaction) mbx new(4); // 容量為4的有界mailbox task automatic producer(); transaction t; for (int i 0; i 10; i) begin t new(); t.data i; mbx.put(t); $display(produced %0d at %0t, i, $time); #5; end endtask task automatic consumer(); transaction t; repeat (10) begin mbx.get(t); $display(consumed %0d at %0t, t.data, $time); #7; end endtask看到這里你可能會發(fā)現(xiàn)mailbox實際上已經(jīng)涵蓋了semaphore的很多用法——它內部自帶同步。但兩者的語義不同semaphore側重“對資源數(shù)量的控制”mailbox側重“數(shù)據(jù)的傳遞”。在同一個環(huán)境里兩者往往要配合使用。比如多個master共享總線用semaphore控制總線使用權而master發(fā)出的請求數(shù)據(jù)用mailbox傳給總線仲裁器。各司其職代碼結構就清晰了。5. 實操復盤一次多通道數(shù)據(jù)比對環(huán)境的設計5.1 需求與架構前面講了一堆概念這里用一個我近期做過的多通道數(shù)據(jù)比對環(huán)境來收個尾。場景是這樣的DUT有4個輸入通道每個通道連續(xù)送數(shù)據(jù)DUT處理后輸出到單路總線。驗證環(huán)境需要同時監(jiān)控4個輸入通道的數(shù)據(jù)經(jīng)過參考模型計算期望值再把期望值跟DUT的輸出現(xiàn)采值比對。聽起來不復雜但實現(xiàn)上有幾個并發(fā)關鍵點。首先是數(shù)據(jù)采集每個通道都要有獨立的monitor線程持續(xù)采樣并打包成transaction。其次是參考模型它要同時接收4路輸入按特定算法算出期望輸出順序發(fā)往scoreboard。最后是scoreboard它要跟DUT輸出端的monitor配合一個線程負責接收參考模型期望值另一個線程負責接收DUT實際輸出然后二者比對。如果環(huán)境里只用一個線程去做接收和比對大概率會丟數(shù)據(jù)或者對不上。于是我的環(huán)境結構是這樣的4個input monitor每個monitor的run_phase里fork一個循環(huán)線程持續(xù)采集數(shù)據(jù)并put到各自的mailbox。參考模型是一個獨立線程它同時從4個mailbox里get數(shù)據(jù)按時間戳對齊后計算出期望輸出放入期望mailbox。scoreboard里兩個線程一個從期望mailbox取期望值一個從輸出monitor的mailbox取實際值配對后做比較。5.2 關鍵代碼摘錄參考模型的對齊邏輯是這里最微妙的部分。4個通道的數(shù)據(jù)不是同時到來的為了對齊它們我的做法是給每個transaction打上采樣時刻的時間戳然后參考模型循環(huán)里先等到4路數(shù)據(jù)都有再統(tǒng)一處理。這里涉及到跨線程等待多個數(shù)據(jù)源直接用mailbox的get會阻塞不方便做“等待4路同時就緒”的邏輯。所以我用了一個更樸素的方案每個通道配一個獨立的mailbox參考模型每次循環(huán)先從一個通道的mailbox get一個數(shù)據(jù)檢查它的時間戳再從另三個通道里get時間戳最接近的數(shù)據(jù)統(tǒng)一處理。這種“先取一路再取其余”的方式雖然簡單但要注意死鎖如果某一路數(shù)據(jù)遲遲不來參考模型會一直阻塞在get上其他通道的mailbox可能會被塞滿。為了避免這種情況我把每路mailbox的容量設得足夠大同時在參考模型里設置超時機制——用fork...join_any或者定時器來實現(xiàn)。這里就不展開全部代碼了但核心思路你可以復制到自己的環(huán)境里。5.3 仿真結果與調試過程第一次跑這個環(huán)境時scoreboard報了經(jīng)第一對數(shù)據(jù)就不匹配而且錯誤出現(xiàn)得很隨機。我花了大半天查結果發(fā)現(xiàn)根本不是DUT的問題而是輸入monitor的采樣時機和參考模型的時間戳對齊邏輯對不上。原因是DUT內部有流水線延時輸入數(shù)據(jù)到達輸出端的時間比參考模型估計的要多一拍導致scoreboard總是拿前一個周期的實際值和后一個周期的期望值去比。后來在scoreboard里加了一個可配置的延時補償參數(shù)對齊之后比對就全綠了。這個坑給我的教訓是參考模型和DUT之間的時序對齊不能只靠功能邏輯正確還必須顯式處理流水級數(shù)和握手延時。如果你在環(huán)境里發(fā)現(xiàn)比對錯誤隨機出現(xiàn)優(yōu)先懷疑對齊而不是急著懷疑DUT邏輯。這類問題用debug波形看很直觀但定位效率不高我的辦法是把期望值和實際值同時打印出來加上時間戳肉眼觀察它們的相位差確定偏移量后反推延時參數(shù)。6. 常見問題與排查技巧實錄6.1 線程不退出導致仿真卡住這是剛寫并發(fā)環(huán)境時最容易遇到的問題。一個任務里fork...join_none開了一個循環(huán)線程循環(huán)條件是while(1)而父線程本身又沒有任何停止機制仿真到$finish也不退出。表現(xiàn)就是仿真器一直不結束或者卡在某個phase里。排查思路先看是不是有線程在等待一個永遠等不到的事件或mailbox。如果是再加上一層超時保護。我常用的辦法是給每個長期運行的線程配一個“軟停止”標志在仿真的shutdown階段置位線程每輪循環(huán)檢查這個標志真了就退出。bit stop_flag 0; task automatic monitor_loop(); while (!stop_flag) begin // 采樣邏輯 end endtask在test的shutdown_phase里置位stop_flag再wait fork就能優(yōu)雅退出。6.2 mailbox死鎖死鎖的典型場景是兩個線程互相等在對方的mailbox上誰也沒法先發(fā)數(shù)據(jù)。比如線程A等B的數(shù)據(jù)B等A的ack結果兩邊都阻塞在get上永遠沒有數(shù)據(jù)進來。解決死鎖的思路無非兩種一是改變通信方式讓數(shù)據(jù)流單向化避免循環(huán)等待二是增加超時機制如果get超時了說明存在異?！獔箦e并強制退出。在關鍵路徑上我傾向于兩種都做盡量從設計上規(guī)避循環(huán)依賴同時用超時兜底。SV里mailbox的get不支持超時參數(shù)如果我想做超時一般用fork...join_any配合一個延時器來實現(xiàn)。等mailbox和等一個時間戳誰先完成就繼續(xù)如果超時完成就告警。代碼示意task automatic get_with_timeout(mailbox mbx, output transaction t, int timeout); fork mbx.get(t); join_any disable fork; if (t null) begin $display(ERROR: mailbox get timeout at %0t, $time); end endtask這種手法在排障時特別好用能快速定位是數(shù)據(jù)沒產(chǎn)生還是數(shù)據(jù)沒送達。6.3 事件丟失與競態(tài)事件丟失的根源在第一節(jié)就提過事件的觸發(fā)是瞬時的如果接收方?jīng)]有在觸發(fā)瞬間掛起等待這個事件就再也等不到了。典型的競態(tài)場景是兩個線程在同一時刻一個執(zhí)行-e一個執(zhí)行(e)。如果觸發(fā)線程先跑接收線程后跑接收線程會永遠等下去。解決方式就是在接收端用wait(e.triggered)替代(e)。wait檢查的是“事件曾經(jīng)被觸發(fā)過”這個狀態(tài)因此不會丟失。但要注意wait(e.triggered)不會自動清除觸發(fā)狀態(tài)如果你后續(xù)還想再用這個事件需要用-或者event的reset操作來手動重置?？缇€程同步時我一般會明確區(qū)分“一次性事件”和“可重復事件”一次性事件用wait(e.triggered)沒問題可重復事件就得自己做狀態(tài)管理。6.4 調試建議讓并發(fā)問題“現(xiàn)形”寫并發(fā)代碼最怕的是問題不可復現(xiàn)。我這邊有一個習慣在所有關鍵的線程入口和同步點加上時間戳打印這能幫你快速判斷線程的執(zhí)行順序和阻塞位置。$display([%0t] thread %s starts, $time, name);仿真跑掛之后從打印日志里看順序通常能一眼找到問題要么某個線程沒啟動要么某個線程卡在了某個同步點。這個方法比打開波形一點點翻效率高得多尤其是環(huán)境很大的時候。另一個技巧是把fork塊里的每個線程都起一個名字配合打印的線程名debug時能直接定位是哪個任務出的問題。7. 我的幾條實操心得寫到這里冒昧分享幾點個人心得不一定正確但都是我踩過坑之后總結出來的。第一并發(fā)代碼寧笨勿巧。能用mailbox就少用全局變量能用event就少用輪詢能用semaphore就少用sleep。SV提供的這三種同步原語已經(jīng)把常見并發(fā)模式封裝好了直接拿來用就好別自己發(fā)明輪子。第二fork塊里能命名就命名。disable一個命名的fork比disable fork一刀切來得精準得多尤其在多級線程嵌套的環(huán)境里這也是我在大項目里踩過“誤殺兄弟線程”的坑之后學乖的。第三收斂比并發(fā)更重要。開線程很容易但確保線程按照預期退出很難。在大型驗證環(huán)境里野線程不僅會導致仿真卡住還可能因為訪問了已經(jīng)釋放的對象而產(chǎn)生隨機崩潰。我在每個phase結束時都會顯式檢查一次線程狀態(tài)寧可多寫幾句冗余代碼也不留隱患。第四不要迷信“參考模型算得一定對”。在我多年經(jīng)驗里scoreboard報錯有一半以上是參考模型自身的時序或對齊問題而不是DUT的真實bug。先把參考模型和比對邏輯的自檢做扎實再判斷DUT對錯。最后想對還處在入門階段的讀者說一句System Verilog的并發(fā)模型并不難難的是在真實環(huán)境里把“同時產(chǎn)生、安全傳遞、正確匯合”這三件事做好。多寫、多跑、多debug慢慢地你會找到自己的節(jié)奏。后續(xù)我打算寫一篇專門講sequence和driver之間如何通過mailbox聯(lián)動控制復雜總線協(xié)議的文章如果你也在關注這兩塊咱們下篇筆記見。