今天在添加環境的結束檢查時候，突然發現ral_model的mirror()無論如何也不進行數據比對：

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()我也執行過確實predict進去了奇怪的值，那么問題只能出現在do_check這里（這個想了好久）。在do_check里我找到了一個核心的操作：

if (!(m_fields[i].get_compare() == UVM_NO_CHECK ||
            acc == "WO")) begin
...

field本身不是UVM_NO_CHECK屬性的話才會進行比對，那么問題是不是可能出現在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的話，環境認為你這個寄存器存不住值也就不會進行compare操作。于是將其修改為（或者直接刪除，我就不應該多這一筆）：

< spirit:volatile >false< /spirit:volatile >

重新生成ral_model后mirror(status, UVM_CHECK)生效報錯。