框图
对于mcdf中的参考设计框图:
在uvm_lab_2中的mcdf_pkg.sv中 mcdf_refmod&mcdf_checker 的疑惑::
- 第69行:
这个流操作符是从右到左的顺序打包,但是流操作符前面的是什么?
要正确区分什么是左移什么是流操作符。很明显下面的应该是左移,因为流操作符按bit打包的形式不同【{<<byte{array}}表按照8bit倒叙打包】。
ot.length = 4 << (this.get_field_value(id, RW_LEN) & 'b11);
- 第202行:
这个需要确认下是否channel ready信号channel valid不能同时为高?需要查看spec
结论:这个是假设设计上的channel enable信号可以正确的传到到验证这一侧,很明显channel关闭之后不可能出现ready跟
if(this.chnl_vifs[id].mon_ck.ch_valid===1 && this.chnl_vifs[id].mon_ck.ch_ready===1)
- 第224行:
- 为什么在report phase中还要加一个formator 的mailbox num不为0?
if(this.fmt_mb.num() != 0)
在uvm_lab_2中的mcdf_pkg.sv中 mcdf_coverage 的疑问
- 每一个covergroup中都有
这个具体作用再温习一下?
表示:type_option.weight = 0表示覆盖率收集的时候不关心这个coverpin的bin。
weight,在不同的层次,表示对上一级贡献的百分比。cross中的weight,表示该cross对整个group的coverage report的影响。
type_option.weight = 0;
- t.addr[3:2]是如何计算的?
按照8421码来确定区间[3:2]里的值的。
那么例子中为何要使用这种方式?
mcdf_pkg.sv的第53行:this.regs[t.addr[3:2]].en = t.data[0];
因为在一开始的控制寄存器说明里提到了对于读写寄存器的地址就是0x00、0x04、0x08不会出现0x1*这样的读写寄存器地址。而t.addr[3:2]若是00,则代表实际寄存器0x00;t.addr[3:2]若是01则是0x04;t.addr[3:2]若是10则是0x08。