uvm驗(yàn)證環(huán)境里一般通過objection機(jī)制來控制仿真的結(jié)束,不過在機(jī)制之外,有時(shí)還需要通過看門狗來watchdog避免仿真環(huán)境掛死,watchdog配合objection一起來控制仿真的進(jìn)行與結(jié)束。
我一直自詡為對(duì)環(huán)境watchdog這件事爛熟于心了,不過沒想到這天還是被傷害到了。
事故背景
一個(gè)中規(guī)中矩的watchdog是怎么組織的呢?要明確一下watchdog發(fā)揮的作用,就是在objection的基礎(chǔ)上進(jìn)行補(bǔ)充,在環(huán)境長(zhǎng)時(shí)間沒有動(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()中我覺得也是可以的。
super.run_phase(phase);
phase.raise_objection(this);
this.watchdog(phase);
phase.drop_objection(this);
endtask: run_phase
watchdog上下的objection還是很有必要的,畢竟你要保證watchdog無論在哪里調(diào)用都可以執(zhí)行起來,別這個(gè)phase沒有objection就直接略過了。
watchdog內(nèi)部邏輯就是幾個(gè)并行的線程,簡(jiǎn)單來說可以這樣寫:
#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)::n %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說明其他的objection都已經(jīng)drop了,那么就可以正常結(jié)束程序,和uvm本身的objection機(jī)制完全一樣;
*線程2:超時(shí)線程,如果很長(zhǎng)的時(shí)間里都沒有喂狗,那么報(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)行那么就說明仿真不應(yīng)該結(jié)束;
*線程N(yùn):可以喂狗的其他線程,使用rtl線程需要萬分謹(jǐn)慎,很有可能rtl里做錯(cuò)了一致重復(fù)出數(shù)據(jù)導(dǎo)致仿真無法結(jié)束;
當(dāng)喂狗一次后,就可以殺掉timeout這個(gè)線程了,然后根據(jù)情況看看是否重新回到看門狗循環(huán)中。
事故現(xiàn)場(chǎng)
看門狗的核心起始就是,確定仿真在“動(dòng)”,能動(dòng)就是還活著不能結(jié)束仿真,所以在fork-join_any里除了超時(shí)線程以外,其他的都是證明系統(tǒng)還活著的“喂狗”線程。這些線程里如果使用rtl的信號(hào)作為系統(tǒng)還活著的參照,一定要萬分的小心,萬分的小心,萬分的小心。
第一點(diǎn)小心是該停止但是停不下來,取材自上個(gè)月的bug。場(chǎng)景很簡(jiǎn)單,#100 @harness.dut.hand_en這個(gè)線程里hand_en做錯(cuò)了,進(jìn)入了無限發(fā)包無限握手的死循環(huán),帶著環(huán)境也一直停不下來看門狗直接失效了。
第二點(diǎn)小心是該仿真但是挺下來了,這個(gè)事我以前就沒想過能出現(xiàn)。事故現(xiàn)場(chǎng)是這樣的還是#100 @harness.dut.hand_en這個(gè)線程(就是這么頭鐵,出過錯(cuò)了還繼續(xù)用),這次確實(shí)是RTL正常的發(fā)包握手,但是,性能模式下外部沒有反壓拍拍握手成功,hand_en起來之后就沒見到下降沿!這就導(dǎo)致了什么問題呢,導(dǎo)致@harness.dut.hand_en線程根本就觸發(fā)不了!這就涉及到@和wait的區(qū)別了,@捕捉的是event trigger是信號(hào)的跳變,harness.dut.hand_en恒1不跳導(dǎo)致看門狗直接超時(shí)了。
簡(jiǎn)直目瞪口呆,只要每天比別人多碰到3個(gè)bug,兩年能積累別人五年經(jīng)驗(yàn)。
事故解決
我把@harness.dut.hand_en改成wait harness.dut.hand_en了
-
看門狗
+關(guān)注
關(guān)注
10文章
560瀏覽量
70789 -
RTL
+關(guān)注
關(guān)注
1文章
385瀏覽量
59759 -
UVM
+關(guān)注
關(guān)注
0文章
182瀏覽量
19167 -
Watchdog
+關(guān)注
關(guān)注
0文章
11瀏覽量
9415
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論