参数化RTL的验证思路

参数化设计

参数化的设计代码和验证组件具有一定的灵活性：

设计模块常使用参数化，比如FIFO深度，总线宽度等

验证组件支持不同的通道数等

参数化的"水平"复用:

同一个RTL代码可以在不同的项目中交付使用

相同的验证代码适配不同的项目

参数化的代码需要在灵活性和复杂性之间做出平衡，而且高度参数化代码的验证是一个非常具有挑战性的工作。

参数化的"ripple effect"

在验证平台的设计中，参数化class常用来提升验证组件的复用性，如果使用不当，会存在 "ripple effect"：使用参数化设计class时，在class的定义和例化时，均需要进行参数传递。当参数个数增多时，会使得代码变得臃肿，代码的简洁性和可读性变差。

因此原文中，作者不推荐在验证环境中使用参数化class的设计。而是采取uvm harness，参数信息提取和pairwise测试等手段，提升参数化RTL验证的效率：

避免参数的ripple efect问题

保持tb和rtl参数同步

不同的RTL参数，tb自动化适配

更有效利用验证时间

TB和ENV连接：UVM harness

UVM harness的介绍，可参见：UVM harness：可复用的interface连接方法

这里给出使用UVM harness后的示意图：

此处的方法和UVM harness的思路相同，实现上略微有些差异，UVM harness中使用的是bind interface to modules，此处使用的是bind module to modules。

RTL参数信息提取和传递

文中也提到自动化提取参数信息的几个出发点：

避免验证平台中大量使用ifdef的宏定义

简化不同参数验证下的功能覆盖率合并

减少DV工程师的工作量，TB的可读性

主要使用两个手段：

在UVM harness中收集RTL参数信息

使用UVM config db向验证环境中传递参数信息

核心思路是在UVM harness中使用rtl_info_struct结构体，存储RTL的参数取值，并使用uvm_config_db set方法，将rtl_info_struct传递至验证环境中。

验证环境使用uvm config db get到参数信息后，可以在SVA、RAL以及功能覆盖率的收集中使用。细节编码不在此赘述，可以参见文末的原文链接。

在此给出主要的编码截图：

参数随机优化

对于参数化的RTL, 当参数个数增多时，很难在有限时间内完全遍历参数的组合场景。此处涉及两个问题：

需要随机出所有参数组合的RTL规格

针对某一个具体的随机规格，需要完成验证完备性的确认

因此文中使用pairwise的方法来代替全组合场景的测试。pairwise保证覆盖任一对参数之间的组合，而不是参数间的全组合。即：for every pair of variables, test every combination of that pair。

pairwise的思路在软件测试中经常被使用，它基于两个假设：

众多参数中的每个参数维度都是正交的

73%的缺陷是由单因子或2因子相互作用产生的

审核编辑：刘清