卢骏 · 2020年06月19日

cadence vmanager(一) MDV介绍

之前,无意之中,了解到这软件,开始学习,感受到这软件的强大,并且成功将该软件,用到了我们部门的flow中。因此,准备一系列的博文,来介绍下cadence的vmanager工具。强烈建议,做验证的团队,使用这个工具,并建立相应的flow。

在说,vmanager工具之前,首先要先介绍一下功能验证方法学。

一、功能验证方法学

做IC验证,我们都是基于功能进行验证。针对功能验证,历经了三个方法学。如下图所示:
1.png

◾directed-test Drive:直接给dut施加激励,然后判断DUT输出是否正确,来验证DUT的各个功能,但是带来的问题,验证不能完备,会遗漏很多隐藏的bug。

◾coverage drive:基于coverage,施加激励,然后最后收集coverage,来判断功能验证是否完备,但是带来的问题是,编写coverage可能会遗漏,造成验证不能完备,并且很难去预估验证是否完成。

◾metric drive:是目前新提出的功能验证方法学。基于验证计划的各个feature,施加激励,最后收集各个feature的metric,反标到验证计划中,得到可视化结果,从而确定验证是否完备。

下面,就要重点介绍这第三种验证方法学,metric drive verification,简称MDV。

二、MDV

MDV,是一种新的功能验证方法学。核心,还是基于coverage,但是将coverage好久和验证计划进行了结合。

将验证得到的metric,反标到验证计划,得到可视化结果,从这可视化结果,从而确定验证到达了哪一个阶段,下一步的验证方向应该是什么,以及最终判断验证是否完备。保证了验证的快速收敛。

metric,其实就是覆盖率,在cadence工具中,是这样称呼的。

cadence,为了实现MDV,提供了vmanager和vplan工具,并制定了一套MDV流程。

三、MDV流程

cadence将MDV流程,分成了4部分,如下图所示:
2.png

◾plan: 制定验证计划,根据验证的testpoint(测试点),利用vplan工具,转化为vplan工程,供后续metric反标使用。

◾construct:根据验证计划,编写coverage和checker。来保证,各个testpoint是否有验证到。

◾execute:利用各个工具,如irun,PXP,formal等工具,对验证环境进行仿真。

◾measure/analyze: coverage收集和分析,反标到vplan,确定验证是否signoff。

其中,最核心的部分,就是中间的部分,负责验证管理和数据管理。这部分,就是由cadence的vmanager工具来负责的。

总之,coverage是MDV的关键,验证中,时时刻刻以coverage为中心,将coverage反标到vplan中,判断vplan中的各个测试点,是否有达到,从而指导下一步的验证方向。
3.png

MDV,可以让你知道,下一步你应该怎么做,并且怎么快速的实现他(Know where you are going and get there faster)。

后面,我会逐一的介绍,vmanager工具和vplan工具,以及怎么利用这2个工具,来实现MDV。

更多相关阅读

uvm中获取cmdlind内容
sv的常数数组参数传递
uvm中run_test


原文首发于骏的世界博客
作者:卢骏
更多IC设计相关的文章请关注IC设计极术专栏,每日更新。

推荐阅读
关注数
10974
内容数
1216
主要交流IC以及SoC设计流程相关的技术和知识
目录
极术微信服务号
关注极术微信号
实时接收点赞提醒和评论通知
安谋科技学堂公众号
关注安谋科技学堂
实时获取安谋科技及 Arm 教学资源
安谋科技招聘公众号
关注安谋科技招聘
实时获取安谋科技中国职位信息