其实工作里几乎没有人会“寄存器测试等级”这么提，这个题目起成这样完全是为了跟前一篇能联系上：
寄存器测试贯穿在TO前芯片项目交付的全流程中，因为之前做了一些寄存器测试方面的工作（细想做的东西是挺杂的），所以借本篇聊一下。寄存器测试穿插在功能测试流程里，比如一般的冒烟测试至少应该有一条要求是寄存器配置通路可以正常的下配置到DUT，这本身就是在覆盖从ral_model到配置组件到RTL配置通路的功能正确性。而项目收尾的质量活动里，通常也会要求测试一下DUT内和DUT间的寄存器地址“黑洞”区域，确保不会挂死访问通路或者高要求返回固定值或error信息。在这种测试场景下就不好通过ral来下配置了，因为ral里没有这些空洞地址的寄存器信息（因为就没有真实的寄存器在这嘛），所以通常可以封一个task来根据配置地址直接对apb/axi口发起读写测试。
掐头去尾之后，中间留下的就是常规一些的寄存器测试了，这里也可以分为两部分：reg_test case和用例中寄存器访问。reg_test case通常包括复位默认值测试、读写测试、属性测试、动态复位测试等。比如对于一个RC型的寄存器A，一般需要RTL复位同时ral.reset()后读取A的值检查是否为default值；之后通过force或后门写（前提是配置了RC可被后门写）将RTL内寄存器实体赋为随机值（后release掉），而后第一次读取检查读取值是否正确，第二次读取检查读取值是否为0以确认其读清属性；之后再赋值，而后RTL复位，读取A的值来确定是否可以呗正确复位（或者，确定其不被某些复位信号影响）；其他的测试还包括写a5a5、5a5a来测试位之间是否有粘连等（但没见过这个发挥作用）。UVM本身是提供了一组寄存器测试的sequence的，随便搜一下有很多使用实例白皮书上也有讲：
reg_test case之外呢，就是在普通用例中对寄存器的读写与覆盖了。在之前交付的项目里，reg_test case是不能计入覆盖率的，因为你是遍历而非在真实芯片工作场景中进行的读写，覆盖项本质是伪覆盖。于是就必须想办法在功能用例中去提高寄存器的覆盖率，那终于回到了本篇的主题：寄存器的动态改配测试与等级。
而对于T0级，可以采用“白噪声”的策略在提高覆盖率和加强系统稳健性。白噪声，顾名思义就是在用例正常跑功能的同时，一般伴随着主流程嗡嗡作响的一些操作。从这个维度来说，我们可以把所有的寄存器分成以下四类：
| 可动态读 | 不可动态读 | |
|---|---|---|
| 可动态写 | 白噪声中随意读写 | 白噪声中随意写 |
| 不可动态写 | 白噪声中随意读 | 白噪声中禁用 |
比如某个RO型计数器，其显然属于“白噪声中可随意读”的范畴，那么我们可以给他配置这个关键词，而后在白噪声的seq里随机遍历到这个寄存器时，发现可以随意读就下发一笔读请求。通过这样的方式，即确认了这类寄存器确实可以带流读写，又增加了寄存器值的覆盖率，还进行了系统的稳健性测试。当然需要注意的是，白噪声不应该影响用例主流程推进（环境保证），其造成的结果也不应该对RTL的行为有影响（RTL保证）。
系列文章入口——
| 【芯片验证】sva_assertion: 15道助力飞升的断言练习 |
| 【芯片验证】可能是RTL定向验证的巅峰之作 |
| 【芯片验证】RTL仿真中X态行为的传播 —— 从xprop说起 |
| 【芯片验证】年轻人的第一个systemVerilog验证环境全工程与解析 |
| 【芯片设计】verilog中有符号数和无符号数的本质探究 |
| 【芯片设计】论RTL中always语法的消失术 |
| 【芯片设计】代码即注释，注释即代码 |
| 【芯片设计】700行代码的risc处理器你确实不能要求太多了 |
| 入职芯片开发部门后，每天摸鱼之外的时间我们要做些什么呢 |
| 如何计算系统的outstanding 和 burst length？ |
| 芯片搬砖日常·逼死强迫症的关键词不对齐事件 |
| 熟人社会里，一群没有社会价值的局外人 |
