如何通过设计验证让SoC芯片流片成功

本文主要是介绍如何通过设计验证让SoC芯片流片成功，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

原文并没有介绍后仿。即netlist的presim/postsim（presim是未经过后端布局布线的netlist，sdf文件由PrimeTime产生；postsim是经过后端布局布线的netlist，sdf文件由后端提供）。我觉得这一步骤，对SOC验证来说也很重要。

引言
SoC验证的研究内容
SoC验证流程与技术
- 1功能验证内容
  - 11 模块IP核级验证
  - 12 系统级验证
  - 13 仿真
  - 14 FPGA验证
- 2 功能验证方法
  - 21 直接测试向量生成
  - 22 约束随机测试
  - 33 覆盖驱动验证
  - 34 基于断言的验证方法
- 4 形式验证
SoC验证技术发展方向

1.引言

随着工艺能力和设计能力的快速发展，为了满足嵌入式系统市场对于成本、功能和功耗的要求，在单芯片上实现以往的嵌入式系统的SoC(System on-a-Chip)设计技术已经成为一种发展趋势。然而，随着SoC的规模和功能的不断急剧膨胀，验证已经变得日益重要，并向业界提出了巨大挑战，已成为了整个SoC设计流程的瓶颈。
目前芯片一次投片成功率只有35%左右，造成芯片重复投片的主要原因就是验证不够充分。SoC设计的验证需要投入的资源已占整个设计资源的60%~80%。1999年当VSIA举行验证专题会时，许多世界级验证专家得出结论：验证是件困难的事（hard）,几周后更把结论更正为“Verificationis not hard,it is very hard”。现在愈来愈达成共识：单一的设计工具难以解决验证问题，而需要一系列复杂的工具和技术，来减少设计错误数，使之达到可接受的程度。
SoC经过多年的发展，有了广阔的市场。SoC验证研究领域在验证技术、验证方法学、测试码提取、验证描述语言、IP核重用验证、验证流程及验证评估方面取得了长足进步。但总体而言验证技术已经落后于设计和制造能力，模拟和验证工作成为整个SoC学科发展的制约瓶颈，给提高设计生产率造成了障碍。如何构建一种更快更好的设计验证方法学是当前SoC业界所关注的问题。

2.SoC验证的研究内容

SoC验证工作比较繁杂。Janick Bergeron给“验证”下的定义是“证明一个设计的功能是否正确的过程”。SoC的验证工作贯穿整个设计流程，从行为级HDL设计，一直到芯片TAPE-OUT之前都需要做充足的验证工作。当前验证工作已经占整个设计工作70%左右。在整个SoC“设计缺陷（BUG）”分布中，其中功能缺陷超过60%。可见SoC验证工作重点应在功能验证上。
SoC验证研究内容很多，如：IP核/模块级验证（Block-LevelVerification）、系统级验证（System-Level Verification）、仿真验证（Simulation）、软硬件协同验证(Hardware/SoftwareCo-verification)、等价性检查（Equivalent checking）、静态时序分析和时序验证（Static timing analysis & Timing Verification）、版图验证（Physical verification）等。随着验证技术的逐步发展，验证方法由最初的直接测试向量生成（Directed Test Vector Generation）,到约束随机测试(Constrainted Random Test),再到覆盖驱动验证(Coverage-driven Verification),一直到最新的基于断言的验证方法(Assertion-basedVerification)及基于方法学的各种验证方法都在不断创新发展。

3.SoC验证流程与技术

SoC的验证工作始终贯穿整个设计流程。从阶段划分上说，SoC验证可以分为功能验证、等价性验证、静态时序分析、动态时序分析和版图验证等几个主要阶段。
有了SoC验证流程还远远不够，我们还需要验证计划（Verification Plan），这为SoC验证工作提供重要质量保证，它规划如何来验证一个设计，主要包括以下内容：
1. 对模块和顶层的测试策略
2. 组成标准测试程序（Testbench）的各个组件的定义和规范，如BFM、总线监视器（Bus monitor）等
3. 用到的验证工具和流程
4. 仿真环境的定义和搭建
5. 关键的验证点
6. 验证工作结束的标准
一个高质量的验证计划使得验证工程师可以更早地开发标准测试程序环境。这种并行的开发验证环境，能尽早给验证团队一个明确的目标，也是保证验证可重用（re-used）的关键。为了得到一个高质量的验证计划，验证工程师要正确和充分地理解设计需求和规范，要与设计工程师及时地交互，这样才能保证验证计划的易读、易用和可重用。因此可以说一个好的验证计划可以有效提高验证效率，缩短开发周期，在SoC开发中有着重要的意义。

3.1功能验证内容

功能验证（Functional Verification）是验证中最复杂，工作量最大同时也是最灵活的部分，包括模块/IP核级验证、系统级验证、模拟仿真等。

3.1.1 模块/IP核级验证

任何SoC设计均由一系列模块组成。模块可能是自己开发，也可能是重用第三方的IP核。不论哪种情况，在系统集成前做IP核验证工作是必需的。模块/IP核级验证主要包括以下几个方面，软性检查(Link Checking)主要检查代码语法、可综合性、变量未初始化、结构化可支持性和端口失配性等；规范模型检查(Formal Model Checking)主要做设计特征遗漏性检查，以在早期发现错误状况，尤其对控制流设计效果明显，通过设计文档非正式说明、与设计者非正式沟通等途径抽取特征疑问，逐一验证，消除缺陷；功能验证(Functional Verification)主要利用基准测试向量基于事件或基于时钟进行功能验证，如黑盒测试、白盒测试和灰盒测试（gray-box）等；协议检查(Protocol Checking)主要验证是否违犯总线协议或模块互连约定，按照协议逐一检查并比较结果；直接随机测试(Directed Random Testing)通过随机产生数据、地址、控制等信号检查功能正确性，减少模拟仿真工作量；代码覆盖率分析(Code Coverage )主要对RTL代码的Line，Brance，Toggle，Condition，FSM等进行统计分析，使其覆盖率达到100%（包含解析过的不可覆盖的部分）以提高设计可信度。

3.1.2 系统级验证

系统级验证主要确认芯片体系结构满足所赋予的功能/性能要求。系统级设计阶段将用户需求转换成功能/性能要求，并实现行为/功能设计，然后映射到相应的体系结构上（设计输入、硬IP核、软IP核、软/硬件划分、性能分析、总体优化、性价比评估等反复叠代），最后进行系统级验证。

3.1.3 仿真

在复杂SoC设计开发中，模拟仿真占整个验证工程师团队工作量的40%~70%，由于成本和市场压力，寻找灵巧的仿真技术显得十分迫切。
功能仿真：主要关注模块-模块（IP核-IP核）间互连验证、系统总线协调性验证和标准规范兼容性验证等，由于复杂度高，可通过事件驱动和加速技术，如硬件加速器、模拟发生器和快速建模试验等来加速和简化仿真工作。
基准测试包：首先搭建SoC整体架构，然后将每一模块（IP核）经基准测试包挂接到系统总线上。这些基准测试包有利于缺陷的识别工作，但它们不是设计工作的一部分，而是为了验证而引入的。基准测试包测试向量来自于IP核供应商、直接随机产生、手工编制或由系统级测试捕获。
事件驱动仿真：使用比较普遍，像NC-Verilog、VCS等均支持，但受芯片规模和性能限制。首先设计代码被仿真工具所接受，其次编制基准测试向量（波形或RTL），第三运行仿真生成波形文件（FSDB），第四通过Verdi等波形debug工具来定位错误、改正后可再次仿真。
时钟驱动仿真：在每一时钟结束时计算电路稳态响应，不考虑时序方面的问题，时序需要静态时序分析工具来验证是否满足要求。时钟驱动仿真比事件驱动仿真速度要快10~100倍，适合大规模电路仿真。
基于传输仿真：传输操作是指传输虚拟部件（TVM）和设计模块间的数据或控制传递，简单的如访存读操作，复杂的如结构化数据包传递。首先获取或编制TVM，其次确定测试内容，第三步编译和连接，第四步进行仿真，第五步作输出分析，最后做功能覆盖分析。

3.1.4 FPGA验证

随着半导体制造技术不断的前进和相应的设计规模以及复杂度飞速的增长，使得传统的软件仿真工具已不可能完全解决功能验证的问题。而且一些需要处理大量实时数据的应用（如视频）也越来越多，因此要求能够在接近实时的条件下进行功能验证。
FPGA验证成为SoC设计流程中重要的一个环节,一方面作为硬件验证工具，可以将所设计的RTL级代码综合实现后写入FPGA芯片进行调试检错；另一方面可以进行软件部分的并行开发，在验证板上检测驱动程序、启动操作系统。FPGA验证的流程相当于一个FPGA设计的主要流程，它主要分为设计输入、综合、功能仿真（前仿真）、实现、时序仿真（后仿真）、配置下载、下载后板级调试检错这几个步骤。总的来说，FPGA验证是整个SoC设计中一个重要而且有效的验证步骤，用来改进RTL级设计代码，验证功能的正确和完整性，提高SoC流片成功率。

3.2 功能验证方法

3.2.1 直接测试向量生成

直接测试向量生成（DirectedTest Vector Generation）遵守WYTWYVO原则，即What-You-Thought-of-is-What-You-Verify-Only，所以需要产生大量的测试向量才能覆盖尽可能多的各种传输组合。这不但要耗费大量的时间和精力，而且很难达到满意的覆盖率。另外这种方法还需要手工检查结果，只适合比较简单的模块或系统，已经逐渐淡出。

3.2.2 约束随机测试

直接测试向量往往需要手工加入，这样难免会遗漏一些考虑不到的情况，因此有学者提出了随机测试（Random Test）的方法。这种方法让测试向量随机生成，因此在足够长的时间内可以产生大量的随机向量，这样可以比较容易地覆盖到一些考虑不到的情况。
但随着验证技术的发展，验证工程师发现这种完全随机的验证方法一般需要比较长的时间才有可能达到令人满意的覆盖率，而且有些设备的传输类型只有几种，这样就导致把时间浪费在了一些根本不需要产生的测试向量上，所以又提出了约束随机测试(Constrained Random Test)这种新的验证方法，这种方法可以有效的缩短验证时间，在短时间内达到令人满意的覆盖率。
由于约束随机测试可以约束验证环境中各个层次上的属性，所以这种方法可以更真实地反映一个实际的系统。使用约束，特别是带权值（在整个测试中出现的比例）的约束可以很容易地按事先确定的比例产生验证工作所需要的具有某些特殊属性值的一类或几类测试向量，而且如果加入记分板（Scoreboard）技术和自检测（Self -check）技术，会更加易于发现设计中的错误。

3.3.3 覆盖驱动验证

覆盖率一般表示一个设计的验证进行到什么程度，也是一个决定功能验证是否完成的重要量化标准之一。覆盖主要指的是代码覆盖（Code Coverage）和功能覆盖（Functional Coverage）。代码覆盖可以在仿真时由仿真器直接给出，主要用来检查RTL代码哪些没有被执行到。使用代码覆盖可以有效地找出冗余代码，但是并不能很方便地找出功能上的缺陷。
使用功能覆盖则可以帮助我们找出功能上的缺陷。一般说来，对一个设计覆盖点的定义和条件约束是在验证计划中提前定义好的，然后在验证环境中具体编程实现，把功能验证应用在约束随机环境中可以有效检查是否所有需要出现的情况都已经遍历。功能验证与面向对象编程技术结合可以在验证过程中有效地增减覆盖点。这些覆盖点既可以是接口上的信号，也可以是模块内部的信号，因此既可以用在黑盒验证也可以用在白盒验证中。通过在验证程序中定义错误状态可以很方便地找出功能上的缺陷。

3.3.4 基于断言的验证方法

在验证过程中，一般很难找出跨多个时钟周期、顺序相关的一系列操作的时序和功能是否有不符合规范的地方，为此研究出基于断言的验证方法(Assertion -based Verification)来推动验证技术发展。这种方法要用基于断言的验证语言，比如OpenVeraAssertion语言（OVA）、SystemVerilog Assertion语言（SVA）、Property Specification 语言（PSL）等。
使用断言可以很方便的对一个给定输入的设计的期望行为进行精确的描述，从而可以很方便的描述输入/输出行为、总线协议以及设计中的一些复杂的关系。基于断言的验证语言可以使用简单的语言结构来建立精确的时序表达式。这些表达式可以代表HDL或者HVL中的事件（events）、序列（sequences）和事务（transactions）等。通过检查这些表达式是否发生，可以很简单地进行功能覆盖的检查，并且这种覆盖率分析是针对跨多个时序周期的一个事件序列或者整个传输的，所以比传统的覆盖驱动验证的抽象层次要高。
传统覆盖分析要专门为覆盖分析而写大量的代码，而断言的覆盖分析可以直接使用在协议检查或者事件描述中用到的那些时序表达式，因此编码会更加灵活、简洁。在验证环境中使用基于断言的验证语言书写的模块（一般为Checker和Monitor）的可重用性优于用HDL和HVL写的模块，此外要结合仿真器在仿真环境中进行验证的工作，不过这些代码可以直接应用到形式验证（Formal Verifi- cation）上。

3.4 形式验证

形式验证（Formal Verification）主要是用来在覆盖所有可能的输入情况下检查是否与给定的规范一致。形式验证主要包括两部分：一是等价性检查（equivalence checking），二是模型检查（model checking）。等价性检查主要是检查两个门级网表（gate-level netlist）之间是否一致，保证网表处理后不会改变电路的功能，或者保证网表能正确地实现RTL代码所描述的功能，或者保证两种RTL描述逻辑一致。这种方法主要是用来寻找实现（implementation）中的缺陷，而不是设计中的缺陷。因此这种方法很难发现同时存在于两种要比较的描述中的固有缺陷。
模型检查主要是检查RTL 代码是否满足规范中规定的一些特性（properties）。在规定这些特性时一般使用特性规范语言（PropertiesSpecification Languages），目前一般也使用基于断言的验证语言。由于这种方法可以在不需要仿真的前提下检查设计中所有可能出现的情况是否满足规定的特性，所以使用这种方法不会遗漏任何的边界情况（corner-case）。但是随着设计复杂度的增加和特性的增多，状态空间（statespace）会成指数级增长，为了克服这一困难出现了一种新的验证方法——半形式验证（semi-formal verification），如Candence公司的IFV工具。这种方法把仿真技术的低复杂性和形式方法的完整性结合了起来。

4.SoC验证技术发展方向

在对IP核进行验证时，传统的方法是，IP核提供者在提供IP核的同时也要提供该IP核的测试向量和测试环境，使用这些测试向量和测试环境来验证测试结果是否正确。这种方法的缺陷在于，虽然这个IP核本身设计是正确的，但是在一个SoC中，每个IP核并不是独立存在的，它与其他的IP核之间必然存在数据交互和总线竞争，没有其他IP核协同验证是很难接近真实情况的，这样的验证也是不完备的。在SoC的实际设计过程中，设计上的问题很多都是在对SoC进行系统仿真验证的时候才暴露出来，主要体现在IP核与IP核之间信号时序的不匹配。这样的错误的定位和更正所需工作量都比较大，造成验证效率低下。在一个实际系统中，经常会有几个IP核同时发出请求让总线仲裁。但是由于C语言和汇编语言不支持并行的操作，因此使用这些语言书写的测试程序只能串行地去控制每个IP核，因而很难模拟这种多个IP核并发的情况。而使用FPGA进行系统级测试时，由于FPGA对外输出有限，系统工作起来只能通过有限的输入输出引脚来辅助定位，对于设计中的错误较难定位和纠正。
SoC验证与其他数字芯片相比最大的不同在于：因为SoC中需要集成大量的IP核，而且由于IP核经常是来自于不同的供应商，使得它们的验证更加困难。有时候甚至需要对IP核进行部分修改才能适合具体SoC的要求。因此IP核协同验证成为IP核验证中的一个难点。IP核提供商所提供的测试向量和测试环境很难重用在多个IP核协同验证的环境下。供应商有时不提供IP核的RTL描述，只是给出行为级的描述和接口时序文档。这样的IP核不能烧入FPGA进行系统级验证，这就要求我们能提供一个系统的验证环境来解决多个IP核协同验证的问题。同时，如果每一次系统级验证都要重新搭建验证环境、编写验证代码，从时间上和人力上都是无法接受的。由于SoC设计中系统结构和大量IP核存在着可重用性，在SoC验证中也可以尽量重用以前的验证代码，使之适应新的设计要求，从而提高验证效率。
验证平台的设计开发，重点的是设计开发通用、自动、便捷和可控可观测的验证平台，使用中科SoC通用验证平台有效的降低了验证人员和设计人员的工作量，更大限度的提高了验证的效率。
为了解决上述设计中的问题，可采用灵活可配置的集合了多种验证手段的系统验证平台，如下图给出的是一种可能验证平台方案。该平台综合使用直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种方法，进行一定量的仿真工作，通过观察时序属性检测报告、数据检查报告、覆盖数据报告和波形来判断是否完成了验证工作。
一般来讲，为了验证一个SoC将对每个模块分别建立一个模块级Testbench，模块级验证通过后，再在模块级的Testbench基础上建立系统级的Testbench。并且在各个层次验证中还要考虑到行为级、RTL级、门级和物理级的不同。这样在整个验证过程中，我们要建立多个Testbench，这样验证工程师把大量的工作耗费在建立和维护这些不同的Testbench中，显然这样是很不经济的。因此我们提出了建立一个通用的验证平台，使用这个平台既可以进行模块级验证，也可以进行系统级验证，并且支持从行为级一直到物理级的验证。
这类验证平台有以下优点：
1．解决了IP核集成时多个IP核协同验证的问题；
2．克服了传统验证方法中测试程序只能串行控制各个模块的缺点；
3．建立了一个统一的可配置的系统测试环境，不需要像传统验证方法那样为每个IP核建立各自的测试环境，提高了验证代码的可重用性；
4．不但可以验证RTL级的IP核，也可以验证行为级和门级的IP核；
5．平台中综合使用了直接测试、约束随机测试、形式化属性检查和覆盖驱动验证等多种验证方法，使得验证更直观，效率更高。
模块级：
CPU的实例化层次为: SOC.VCPU
芯片级：
CPU的实例化层次为:SOC.CSPF.CPUSYS.VCPU
在验证内嵌CPU的SOC时，想要实现验证平台的可重用，对于CPU的仿真模型的设计是必不可少的。当采用了CPU的仿真模型后，驱动器就可以直接控制CPU的仿真模型来对周边模块进行读写操作。这样在单体IP验证和整体chip验证的时候，可以通过在驱动器里面通过define定义CPU仿真模型的实例化层次来对应是单体仿真还是chip级的仿真。这样对于抽象的Testcase来讲，对DUT如何施加激励就变得一致了。从而达到同一个项目的单体case和chip整体仿真case的重用。提高验证效率。

对于使用不同总线协议的Master，还是需要重新改写driver部分。对于这样的情况笔者还没有找到更好的方法。不知道您是否有更好的实现方式？
1，如何用更好的方式实现分层验证环境来验证内嵌CPU的MCU芯片
2，可以使用形式验证工具如IFV来验证芯片的IOMUX部分的纯组合逻辑吗？
3，如何实现多系列MCU周边仿真模型的重用？比如UART模块对应的仿真模型即可以在MO的MCU仿真环境里面用，又可以在M3的MCU仿真环境里面用。