在数字芯片验证中功能覆盖率是个什么角色?
对于验证小兵,它指导验证的方向;
对于验证经理,它量化评估验证项目进度的指标。
所谓“选择比努力更重要”,一旦涉及方向或者最终评估手段的,就绝对不能错。如果出错,必然会差之毫厘谬以千里。把错的当成对的,把没验过当成已验的。
在以前的文章中,强调过sdc对于综合和自动布局布线的决定性作用,功能覆盖率也同样地对验证工作的行为起着决定性的作用。
功能覆盖率建模(Functional Coverage Modeling)是当今数字芯片前端验证sign-off中使用的一个标准,还涉及到低功耗、混合信号和软件场景的覆盖,但是往往没有在建模之前进行清晰地规划。
验证覆盖率规划可以包含在验证计划(Verification Plan)内,作为设计需求和仿真结果之间的桥梁,即可以在设计需求和仿真结果之间相互追溯。
不管功能覆盖率文件是如何生成的(人工code或者是通过脚本生成),但是coverpoint的定义始终还是人为的,目前工具还是很难实现直接从需求文件到覆盖率定义文件的翻译工作。
为此,在规划覆盖率时需要谨记下面最重要的三件事:
1、准确
覆盖是指在指定事件触发时收集到期望的设计状态集合。为此,我们需要完全确保这个触发事件指定正确。如果被收集的状态data在valid为高时才有意义,就需要将“valid为高”作为触发条件,否则可能误收集,将未覆盖的场景分析成已覆盖的场景。
2、等价
工具的算力、验证工程师的精力以及公司的成本都是有限的,需要把握住任务的优先级,功能覆盖率规划也是如此。例如32bit的两位数加法,我们几乎不可能收集2^32 * 2^32中场景,这时候应该合理地使用较小的覆盖率子集进行等价,同时根据设计实现收集一些边界场景即可。
3、完备
基于等价的原则,我们自然是可以容忍不去收集某些低优先级的测试点覆盖率,但是这也是在经过仔细分析的基础上做出的无奈选择,否则往往会遗漏某些重要的场景,使得验证不完备。