1 介绍
ADE Explorer、ADE Assembler是Cadence Virtuoso ADE一系列产品的重要模拟设计验证工具，将验证技术可视化，能够很好地支持工程师子模块的模拟设计验证，大大提高了验证效率。现有的验证直接根据仿真结果来决定验证设计的好坏与否。这种验证流程简单有效，但是也有其弊端——规格无标准可循、难以覆盖更高层的设计，导致难以及时发现并规避设计更深层的问题。在整合了ADE Explorer、ADE Assembler强大的简单有效的验证功能的基础上，ADE Verifier在验证流程上做了进一步的优化，能够有效弥补现有模拟设计验证存在的不足，很大程度上提高了模拟设计验证的可靠性和完备性。ADE Verifier特性如图1所示。
图1 ADE Verifier特性
2 Verifier验证流程
Verifier支持自顶向下、自下向上、混合的设计方法。本文描述Verifier自顶向下的设计方法。根据客户需求、业务场景和条件等原始需求，项目管理者（PM/PL）整合原始需求，转换成设计语言，细化、分解设计需求。然后将整个需求分配给不同的工程师。根据分配得到的需求，工程师深入理解设计需求，量化相应的设计规格，并设计仿真用例和测试用例，完成仿真。然后将需求设计和规格设计进行最后，工程师提交验证数据，项目管理者就可以及时观测验证结果，跟踪项目验证进度。ADE Verifier验证流程如图2所示。
图2 ADE Verifier验证流程
2.1 项目管理者建立Requirement
需求的建立有两种方式，一是项目管理者在verifier里面创建的，二是直接导入指定格式的需求表格，包括csv文件和excel文件。
需求的内容包括项目名称，模块名称，指标的最大值与最小值、指标的单位、责任人、类型以及详细的描述等。指标的最大值与最小值、指标的单位都是作为后续规格设计的约束。内容可以由中文、英文、日语、德语、北印度语5种语言组成。
需求的类型包括以下几种：Note，Spec Pass，Ran OK，Manual。Note类型的需求是不需要仿真验证；Spec Pass类型和Ran OK类型的需求是可以进行仿真验证的，二者差别就是Spec Pass类型的需求要考虑需求设计的指标值来决定需求的状态，Ran OK类型的需求只会根据仿真结果来决定需求的状态；Manual类型的需求是指是要人为判断设计的成功与否，而不是直接简单地根据仿真结果来决定。
需求是Hierarchy结构的。从顶层模块开始进行需求设计，细化到每个子模块的需求设计，直到完成整个项目的需求设计。每个需求设计都会指定一个责任人，后续每个责任人都只需要对各自被分配到的需求负责人。
在现有的整个项目需求设计基础上，可以新增需求、删除现有需求、编辑现有需求。
2.2 项目管理者分配Requirement
根据需求责任人，可以将master verification分成几个不同的owner verification。每个责任人只需要着眼于own verification，根据被分配到的需求进行规格设计。如图3所示，Fred、Harry是master verification的责任人，分配需求时，会生成相应的verification_Fred和verification_Harry。之后，Fred和Harry只需要分别修改、完善verification_Fred 和 verification_Harry即可。
图3 分配Requirement
2.3 工程师添加Implementation
根据需求设计，工程师进行相应的Implementation，支持adel、adexl、maestro类型的文件。如图4所示。
图4 工程师添加Implementation
2.4 工程师建立Mapping
工程师根据自己分配到的任务，建立testbench，和Requirement建立映射。Requiremment与SPEC之间可以是n：1或者1：n的关系。
需求的mapping有6种状态：Pass，Fail，No Results，Mapped，Unmapped，Spec check failed。
Pass是指在requirement的specification与implementation的specification保持一致的前提下，requirement的specification和仿真结果保持一致。
Fail是指在requirement的specification与implementation的specification保持一致的前提下，requirement的specification和仿真结果不同。
No Results是指在requirement的specification与implementation的specification保持一致的前提下，implementation没有仿真结果。
Mapped是指requirement的specification与implementation的specification保持一致。
Unmapped是指requirement还没有建立mapping。
Spec Check Failed是指如果requirement的specification与implementation的specification不能保持一致。
2.5 工程师加载、提交个人Result
Verifier提供了两种加载结果的方式：直接跑仿真和加载仿真结果。
Verifier呈现的结果包括整个项目的结果百分比，以及每个模块、需求的结果。需求的结果状态分为两种：Requirement Status 和Specification Status。Specification Status是根据spec的结果而定；Requirement Status是根据spec结果以及map结果而定。加载个人Results如图5所示。
图5 加载个人Results
2.6 项目管理者查看项目Result
等到工程师提交了个人结果之后，项目管理者就可以查看整个项目的验证进展和验证结果。如图6所示。
图6 查看项目Results
3 Hisilicon Verifier
3.1 定制化特性
根据海思的业务需求，在原有ADE Verifier平台上，添加了定制化特性，有以下两点：
(1)导入的requirement表格形式：通过新增列数，直观地呈现需求之间的Hierachy结构；
(2)结果的保存与呈现：通过收集工程师提交的结果，保存到数据库。保存结果能够让现有项目传承历史项目的优良基因；展示结果从项目和owner的维度展示数据，能够让项目管理者直观看到整个项目的验证进展，让工程师清晰认识到自己模块的进度。Hisilicon Verifier Results如图7所示。
图7 Hisilicon Verifier Results
3.2 定制化流程
在工程师提交verification时候，结果数据就会被收集。为了适配定制化特性——收集结果数据，整理了使用verifier的三种流程，这三种流程都能够保证收集到数据。为了能够清晰描述三种流程的特点，假设背景如下：工程P，项目经理是M，工程师E1，E2，E3。M新建一个verification，设置result路径为Current cellview，这样结果文件就在相应的verification路径下。分配任务，生成verification_E1, verification_E2, verification_E3。项目经理M check in verification，verification_E1, verification_E2, verification_E3。如图8～图11所示。
(1)流程1（如图8）
图8 项目背景
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加载结果，check in verification_E1，这样才能收集到数据；
Step3：
E1 Check in maestre_E1，这样M，E2，E3才能看到E1的结果；
(2)流程2（如图9）
图9 流程1
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加载结果，check in verification_E1，这样才能收集数据；
Step3：
E1 Check out verification，load E1的结果，check in verification，这样M，E2，E3才能看到E1的结果；
(3)流程3（如图10）
图10 流程2
Step1：
E1 新建maestre_E1，搭建testbench，跑仿真；
Step2：
E1 Check out verification_E1，和maestre_E1建立Map，加载结果，check in verification_E1；
这三个流程都能够达到收集数据以及呈现最新结果的目的，但是流程1和流程2都有其弊端。
流程1中，要想工程师的结果被其他人看到，必须提交maestre。首先，maestre很大，提交很费时。其次，maestre保存的是过程配置信息，不适合提交。
流程2中，整个项目组都需要操作一份文件—verification，很容易产生写冲突，不适合大项目、异地项目的合作。另外，工程师需要操作owner verification 和master verification，职责不够分明。
流程3，只需要选择HISILICON_VERIFIER为yes，这样加载结果来源是结果的快照文件。提交owner verification，即可收集数据，也可以保证其他人都能看到结果。职责分明，操作简单。
所以，Hisilicon Verifier采用流程3。
图11 流程3
4 验证完备性
4.1 完备性问题
以Hisilicon的验证流程进行分析，从制定原始需求开始，到编写测试用例，验证完备性的突出问题如下。
(1)OR：遗漏、客户自己不清楚；
(2)DR：功能/隐形需求遗漏；
(3)DS：内部规格未细化、规格条件不合理、非典电路规格不全。
4.2 Verifier方案
基于Verifier的验证流程，验证完备性问题能够在很大程度上得到解决。
(1)需求设计、规格设计、仿真等整个验证流程都是需求驱动的，保证了需求的可溯性。
(2)从上至下的验证流程，既保证了各个模块之间相互独立，互不干扰，也保证了各个子模块之间无缝契合。
(3)记录仿真结果，自动复现仿真结果，将仿真过程变得更加可溯和自动化。
(4)当工程师改变了某个设计模块，verifier具有联想功能，能够提示相关testbench需要重新进行仿真，进一步确保验证完备性。
5 结语
通过使用ADE Verifier工具，我们将在电路设计中解决由于验证不完备性的各种问题。这种问题在很大程度上是可以通过完善的验证流程去规避的。在海思的验证设计实践中，Virtuoso ADE验证工具技术与Virtuoso ADE组装工具技术具备设计规划能力，让设计团队更加高效，提升了模拟IP验证效率将近30%，验证发现的问题数量减少了一半。所以，ADE Verifier是验证设计中不可或缺的工具之一。
