【管中窥豹集】你真的了解“随机”这两个字意味着什么吗？

|原创作者| Jerry

“举管而望，观一斑可思全豹”

--管中窥豹集· 杰瑞IC验证

今日聊“随机”。

有哥们儿说：“这东西太熟悉了不用聊！我们跑仿真的时候，每天都在随机测试嘛”。

好的，Jerry给你讲一个小明的验证故事，看看如果给随机“换了一身衣服”，你还是不是真的认识它。

小明有一天接到了这样一个验证需求：他的待验证对象是一个公共的RTL模块，且这个公共RTL模块带了很多parameter，正因为是公共的模块所以它的parameter没有固定值，而是依据未来不同系统应用传入不同的parameter值，但是小明的任务是完整验证这个公共模块，他就需要考虑例化时传入不同parameter的情况。

请注意这个验证需求的特殊点：例化时传入不同的parameter代表着完全不同的RTL！即假如有500种parameter的组合，小明相当于需要验证500个完全不同的RTL！

聪明的小明马上制订了验证策略：

1.不论如何变化parameter一定要保证验证平台和绝大部分验证case可以复用，这样只需要改变parameter就可以完成不同RTL的快速回归测试。

2.parameter以宏的方式传入，500种parameter使用脚本一键生成独立的宏定义文件，不同RTL通过切换宏文件实现即可。

3.紧抓重点，面向未来应用场景，找到最核心且使用可能性最大的10种parameter组合重点验证分析，并且当作10个独立的RTL进行10次覆盖率分析。

4.其余490种parameter组合怎么办呢？小明说出了那两个字：“随机”～

这里听到“随机”这两个字，是不是熟悉而陌生？

说“熟悉”是因为这里小明说随机的思路并不违和，重点的patameter场景重点照顾，非重点的场景直接靠随机去“撞”。

说“陌生”是因为这里说的“随机”和我们平时说的“随机”场景不太一样，即前文所谓的“换了一身衣服”。之前验证时候说到“随机”，都是针对某一个RTL，验证平台随机它的激励约束范围，而这里我们随机的是“宏文件切换”，这个场景比较陌生。

我们不讨论小明的验证方案是否完美，我们只关注今天的题目：

你真的了解“随机”这两个字意味着什么吗？“随机”这两个字，隐藏着哪些工作需要做呢？

本文由“壹伴编辑器”提供技术支持

1.首先，谈到“随机”意味着要考虑随机约束范围和权重

正如我们平时在constraint写某个变量的随机范围和权重一样，其实不管什么样的随机，只要听到“随机”两个字，都应该想到合理的权重分布和不同的边界范围！

在小明的例子中：

490种parameter组合随机切换起来都一样的权重吗？

是不是在这些非重点的组合中还有稍微重点的组合？

哪些范围的parameter是重点？

是不是某些parameter在极限值边界值的时候更恶劣？

有没有可能某些parameter为某特殊数值时出问题的概率更大？

是否有某几个parameter在某种组合的情况下更容易产生错误？

……

这个机制，小明不论是在脚本中生成时处理或是在文件引用时处理，如果体现出了随机重点和权重，便一定程度上提高了他随机和验证的效率。

2.然后，谈到“随机”意味着你要知道到底随机到了什么程度？

随机到什么程度这个问题，我们自然可以联想到动态仿真时候分析的“覆盖率”。

回望验证的发展历史，我们可以发现，在芯片集成度还没有像现在这么大的时候，在早期的验证工作中，覆盖率并不是一个受到广泛重视的指标，除了工具和语言支持不给力之外，有一个原因是因为早期针对不是很大规模的设计，大部分验证是基于纯定向case测试的方式进行的，这种方式验证者很清楚自己能覆盖到哪些点。只要通过如波形确认等手段保证没有假pass，跑完一遍完备的定向case就可以等同认为覆盖率达标了。

什么时候我们开始重视覆盖率了呢？语言工具发展、芯片规模变大的背景下，最重要原因就是因为那两个字“随机”！因为你是随机的，你随机的这部分你到底随机成什么样子了？它不像定向测试让人有更大的把控感，随机的部分是乱撞的、是让人心里没底的！因为某个代码失误随机半天只是随机了很小一部分怎么办？所以分析覆盖率就可以让你的随机程度看得见摸得着～

小明的例子也是如此，490种parameter组合，假如小明说我遍历这490种组合，那问题不大，跑完了肯定都覆盖了。但是偏偏验证时间不允许小明同学遍历，他选择了“随机”的切换方式，期望尽可能覆盖更多的组合撞出想不到的问题，此时他一定要需要考虑如何捕捉“随机到什么程度”这个信息，只有这样才能更好的保证完备性，保证随机和验证质量。

3.接着，谈到“随机”意味着你要想到如何复现

一旦回归时出现了bug，你就需要复现出这个bug。

还是类比于验证发展早期的纯定向case，此时期这些case的波形每次跑每次都是一样的，如果出现bug，你只需要关心是哪个case重新跑下就可以复现问题。但是一旦涉及随机验证，同样一个case，每次跑每次不一样，这时你需要考虑“复现”的问题！

随机动态仿真时，我们在相同代码相同case的前提下，通过保证相同的随机种子即可以复现我们的case。

小明的490种parameter组合随机切换的验证场景就会稍微复杂点，一旦出错，在回归结果信息中，首先要能确定出是哪种parameter组合的文件信息，同时要能进一步确认出具体出错case的种子信息。然后基于相关信息进一步复现case。

结语

今天我们从一个“非常见”随机场景出发，给随机“换了一身衣服”，在不同的着装之下重新与“随机”相识相知相爱，审视它的本质和内在。

Jerry希望通过今天的讨论，可以形成一个思维条件反射：

听到“随机”这两个字，即想到“权重与约束范围”，即想到“覆盖率”，即想到“如何复现”。

举管而望，观一斑可思全豹。以验证思维看世界可以看到更美丽的风景～

这里是杰瑞IC验证，祝大家越来越牛逼，加油！！！

——The End——