uvm驗(yàn)證環(huán)境里一般通過(guò)objection機(jī)制來(lái)控制仿真的結(jié)束，不過(guò)在機(jī)制之外，有時(shí)還需要通過(guò)看門(mén)狗來(lái)watchdog避免仿真環(huán)境掛死，watchdog配合objection一起來(lái)控制仿真的進(jìn)行與結(jié)束。我一直自詡為對(duì)環(huán)境watchdog這件事?tīng)€熟于心了，不過(guò)沒(méi)想到這天還是被傷害到了。

事故背景

一個(gè)中規(guī)中矩的watchdog是怎么組織的呢？要明確一下watchdog發(fā)揮的作用，就是在objection的基礎(chǔ)上進(jìn)行補(bǔ)充，在環(huán)境長(zhǎng)時(shí)間沒(méi)有動(dòng)靜的情況下能夠使環(huán)境報(bào)錯(cuò)推出并打印此時(shí)阻止仿真結(jié)束的罪魁禍?zhǔn)住?/p>

基于這個(gè)認(rèn)識(shí)，watchdog應(yīng)該是base_test的run_phase（）中進(jìn)行調(diào)用，這樣既從時(shí)間全程參與又從空間上統(tǒng)攬全局。當(dāng)然了，因?yàn)榄h(huán)境的主要行為集中在main_phase（）中，所以把watchdog放在main_phase（）中我覺(jué)得也是可以的。

task base_test：：run_phase（uvm_phase phase）： super.run_phase（phase）; phase.raise_objection（this）; this.watchdog（phase）; phase.drop_objection（this）; endtask： run_phasewatchdog上下的objection還是很有必要的，畢竟你要保證watchdog無(wú)論在哪里調(diào)用都可以執(zhí)行起來(lái)，別這個(gè)phase沒(méi)有objection就直接略過(guò)了。watchdog內(nèi)部邏輯就是幾個(gè)并行的線程，簡(jiǎn)單來(lái)說(shuō)可以這樣寫(xiě)：

task base_test：：watchdog（uvm_phase phase）： #1000; if（this.cfg.watchdog_en == 0） return; while（1）begin bit vr_reached; fork： timeout begin //normal finish phase.phase_done.wait_for_total_count（null， 1）; vr_reached = 1; end begin //timeout #this.cfg.watchdog_th; `uvm_fatal（“watchdog”， $psprintf（“watchdog timeout（%s_phase）：： %s”， phase.get_name（）， phase.phase_done.convert2string（））） end #100 @prj_scoreboard：：feed_watchdog; #100 @harness.dut.hand_en; #100 wait（this.env.num ！= 0）; join_any disable timeout; #10; if（vr_reached && phase.phase_done.get_objection_tatal == 1）begin `uvm_info（“watchdog”， $psprintf（“watchdog timeout（%s_phase） normal reached”， phase.get_name（））， UVM_LOW） break; end end `uvm_note（“watchdog”， “watchdog Finished！”， UVM_LOW） endtask代碼的主體就是一個(gè)大的while（1）循環(huán)，循環(huán)內(nèi)以fork - join_any的形式起多個(gè)喂狗線程，根據(jù)fork - join_any的機(jī)制，只要任何一個(gè)線程完成了都會(huì)觸發(fā)喂狗機(jī)制。

線程1：正常結(jié)束的線程，因?yàn)楸旧韜atchdog占著一個(gè)raise_objection，所以只要等待wait_for_total_count（null， 1）就可以了，為1說(shuō)明其他的objection都已經(jīng)drop了，那么就可以正常結(jié)束程序，和uvm本身的objection機(jī)制完全一樣；

線程2：超時(shí)線程，如果很長(zhǎng)的時(shí)間里都沒(méi)有喂狗，那么報(bào)fatal推出仿真。注意這里必須是fatal使方正立即結(jié)束，報(bào)error的話環(huán)境還是會(huì)掛死狀態(tài)；

線程3：所有的scoreboard都可以喂狗，因?yàn)閟cb里比對(duì)的一方是可以信任的環(huán)境預(yù)期，如果比對(duì)還在進(jìn)行那么就說(shuō)明仿真不應(yīng)該結(jié)束；

線程N(yùn)：可以喂狗的其他線程，使用rtl線程需要萬(wàn)分謹(jǐn)慎，很有可能rtl里做錯(cuò)了一致重復(fù)出數(shù)據(jù)導(dǎo)致仿真無(wú)法結(jié)束；

當(dāng)喂狗一次后，就可以殺掉timeout這個(gè)線程了，然后根據(jù)情況看看是否重新回到看門(mén)狗循環(huán)中。

事故現(xiàn)場(chǎng)

看門(mén)狗的核心起始就是，確定仿真在“動(dòng)”，能動(dòng)就是還活著不能結(jié)束仿真，所以在fork-join_any里除了超時(shí)線程以外，其他的都是證明系統(tǒng)還活著的“喂狗”線程。這些線程里如果使用rtl的信號(hào)作為系統(tǒng)還活著的參照，一定要萬(wàn)分的小心，萬(wàn)分的小心，萬(wàn)分的小心。第一點(diǎn)小心是該停止但是停不下來(lái)，取材自上個(gè)月的bug。

場(chǎng)景很簡(jiǎn)單，#100 @harness.dut.hand_en這個(gè)線程里hand_en做錯(cuò)了，進(jìn)入了無(wú)限發(fā)包無(wú)限握手的死循環(huán)，帶著環(huán)境也一直停不下來(lái)看門(mén)狗直接失效了。第二點(diǎn)小心是該仿真但是挺下來(lái)了，這個(gè)事我以前就沒(méi)想過(guò)能出現(xiàn)。

事故現(xiàn)場(chǎng)是這樣的還是#100 @harness.dut.hand_en這個(gè)線程（就是這么頭鐵，出過(guò)錯(cuò)了還繼續(xù)用），這次確實(shí)是RTL正常的發(fā)包握手，但是，性能模式下外部沒(méi)有反壓拍拍握手成功，hand_en起來(lái)之后就沒(méi)見(jiàn)到下降沿！這就導(dǎo)致了什么問(wèn)題呢，導(dǎo)致@harness.dut.hand_en線程根本就觸發(fā)不了！這就涉及到@和wait的區(qū)別了，@捕捉的是event trigger是信號(hào)的跳變，harness.dut.hand_en恒1不跳導(dǎo)致看門(mén)狗直接超時(shí)了。簡(jiǎn)直目瞪口呆，只要每天比別人多碰到3個(gè)bug，兩年能積累別人五年經(jīng)驗(yàn)。

事故解決我把@harness.dut.hand_en改成wait harness.dut.hand_en了

審核編輯：黃飛