今天在添加環(huán)境的結束檢查時候,突然發(fā)現(xiàn)ral_model的mirror()無論如何也不進行數(shù)據(jù)比對:
ral_model.xxx.predict(xxxx);
ral_model.mirror(status, UVM_CHECK);
我自己非常的確定語法肯定時沒有問題的,但是無論往寄存器里predict什么奇怪的值進去,mirror時候都不會報錯。這就非常令人費解了,于是只能去源碼里找。
mirror的最底層邏輯在uvm_reg.svh:
if (check == UVM_CHECK)
exp = get_mirrored_value();
...
if (check == UVM_CHECK) void'(do_check(exp, v, map));
鑒于UVM_CHECK我已經傳入了,get_mirrore_value()我也執(zhí)行過確實predict進去了奇怪的值,那么問題只能出現(xiàn)在do_check這里(這個想了好久)。在do_check里我找到了一個核心的操作:
if (!(m_fields[i].get_compare() == UVM_NO_CHECK ||
acc == "WO")) begin
...
field本身不是UVM_NO_CHECK屬性的話才會進行比對,那么問題是不是可能出現(xiàn)在field屬性身上呢?轉到uvm_reg_field.svh文件,找get_compare()方法:
function uvm_check_e uvm_reg_field::get_compare();
return m_check;
endfunction
進一步的看下m_check屬性是怎么定義的:
function void uvm_reg_field::configure(uvm_reg parent,
int unsigned size,
int unsigned lsb_pos,
string access,
bit volatile,
uvm_reg_data_t reset,
bit has_reset,
bit is_rand,
bit individually_accessible);
...
m_check = volatile ? UVM_NO_CHECK : UVM_CHECK;
...
問題大概明確了,應該是field在進行configure是volatile賦值為1,查了一下確實如此:
this.xxxx.configure(this, 20, 0, "RW", 1, 20'h0000, 1, 1, 1);
那么問題就大概清晰了,溯源來看ral_model是通過ralf生成的,ralf是通過xml生成的,那么只能是xml中寫錯了:
< spirit:volatile >true< /spirit:volatile >
我這才理解了xml中這個“易失性”。之前就一直不明白,為啥一個仿真模型要關心volatile呢,原來如果易失性=true的話,環(huán)境認為你這個寄存器存不住值也就不會進行compare操作。于是將其修改為(或者直接刪除,我就不應該多這一筆):
< spirit:volatile >false< /spirit:volatile >
重新生成ral_model后mirror(status, UVM_CHECK)生效報錯。
-
寄存器
+關注
關注
31文章
5294瀏覽量
119814 -
UVM
+關注
關注
0文章
181瀏覽量
19121
發(fā)布評論請先 登錄
相關推薦
評論