原帖：http://www.eetop.cn/blog/html/28/1561828.html
芯片验证的方法篇本文分八个部分：
上篇：
验证的方法篇之一：动态仿真
验证的方法篇之二：静态检讨
验证的方法篇之三：开拓环境
验证的方法篇之四：虚拟模型
下篇：
验证的方法篇之五：硬件加速
验证的方法篇之六：效能验证
验证的方法篇之七：性能验证
验证的方法篇之八（终）：趋势展望
芯片验证的方法篇（上篇）
验证的方法篇之一：动态仿真
（博客链接：http://www.eetop.cn/blog/html/28/1561828-438525.html）
从这一季开始我们进入了《验证的方法篇》，之以是单独分出一季来先容验证的方法和工具，一方面是目前验证方法的分支和其工具种类繁多，其余的是希望读者可以在系统理解了验证的工具库之后，在验证设计的时候首先有一套工具箱，而后再根据设计的特点将其结合不同的验证方法和事情，终极取得满意的效果。
从Wilson 2014年调查数据来看，验证霸占了紧张的人力资源，同时也是设计能否达标低毛病率的紧张保障。从2007年到2014年的增长趋势来看，由于设计的繁芜度逐年攀升，与之带来的验证压力和实际人力资源配置都相应提高。除了人力的投入，设计自动化（DA，design automation）工具关于验证的方法、特性、性能提高都在帮忙验证职员来面对新的验证寻衅。
到了目前的阶段，已经没有一种单一的工具、措辞或者方法可以供应用来实现验证完备性。实际的验证事情中，我们须要通过多种措辞、方法、脚本、工具终极达到验证的的目的。这些不同的措辞、方法、脚本和工具之间没有绝对的利害，比如仿真验证办法会协同形式验证办法一同来完善功能覆盖率，也有可能通过不同措辞的脚本之间的整合来终极完成一项验证流程。总而言之，作为一名有履历的工程师，他须要在节制现有的各种方法和工具的条件下，通过合理的选择，末了“保质高效低耗”地完成验证任务。
以是，我们将根据验证的方法分为多少类为大家梳理目前主流的验证方法和工具。这些紧张的验证方法可以分为：
动态仿真（dynamic simulation）
静态检讨（formal check）
虚拟模型（virtual prototype）
硬件加速（hardware acceleration）
电源功耗（power consumption）
性能评估（performance evaluation）
在此之上，我们额外引入一篇开拓环境来将日常的编码环境与大家先容，所谓工欲善其事，必先利其器，有一个应手的开拓办法，也是迈向高效率的一步。
这一篇我们为大家带来日常最常见的验证办法——动态仿真（dynamic simulation），该办法实在便是通过测试序列和勉励天生器给入待验设计适当勉励，结合韶光的花费，进而判断输出是否符合预期的。简而言之，我们须要仿真器来合营这一项事情，验证职员也须要通过查看比较结果、仿真波形比对终极来剖断测试用例是否通过。如果按照勉励天生办法和检讨办法的不同，我们又可以将动态仿真中的验证办法分为：
直接测试（directed test）
随机测试（random test）
参考模型检讨（reference model check）
断言检讨（assertion check）
由于参考模型一样平常都会伴随着直接测试或者随机测试，以是我们接下来带着大家着重理解这三部分：直接测试、随机测试和断言检讨。
直接测试
直接测试指的是勉励的值在仿真之前已经决定下来，测试用例给出的勉励序列会不才一次重新提交任务往后保持不变。我们日常会通过C/C++/汇编代码来履行测试用例，该场景最常见的是SoC子系统级或芯片系统级的测试，由于待验设计一样平常会包含处理器在期中，而且根据硅后测试复用的角度，我们也方向于利用C代码来编写测试用例。
从下图中可以看出，测试用例经由编译、二次映射成为硬件存储器可以读入的镜像文件（一样平常为二进制文件，紧张包含地址和数据两部分）。待验设计经由上电复位（power up and reset）往后会从存储器中读取二进制文件，进而处理器会将二进制数据译码（decoding）为指令和数据进走运算或者寄存器访问。而终极的数据比较分为两种情形：
通过内置的C代码进行数据精确性检讨
通过外置的参考模型或者其它检讨器来进行旗子暗记同等性检讨
有时候我们也会考虑直接将第三方供应的可实行文件或者预先映射的二进制文件作为勉励源交给存储器，这就跳过了C代码编译的步骤，也须要额外的运行环境兼容方法。
我们将上述的直接测试的流程对照到实际项目中，如下面这个例子，测试用例可以通过C代码交给处理器，进行硬件行为的仿真检讨。如果在模块验证环境中短缺处理器，我们如何在这一级实现C代码的垂直复用（从模块级到芯片系统级）呢？可以考虑下面的步骤：
将C代码交给转换器将其转换为文本命令格式
文本命令格式可以被总线翻译器识别进而转换为总线上的读写操作
上面的步骤中须要引入转换器实现复用，我们也可以考虑将转换器和总线翻译器结合成为SystemVerilog C-DPI的形式来将翻译层通过标准的C-DPI接口实现更多的复用性。关于SystemVerilog C-DPI的实践办法我们会在后面的篇章《SystemVerilog实战点全讲》里跟大家详细谈论。
直接测试的利用场景一样平常会在模块测试的早期或者在系统级芯片测试场景中，它适宜于测试待验设计的基本功能，且能最直接地翻译出验证职员想要的场景，而它的毛病也较明显那便是，每一个直接测试用例在通过之后的重复仿真是冗余的，由于这不会提高更多的覆盖率，也无法产生新的测试序列。不过也正由于它的勉励序列确定性（determinacy），直接测试有时候可以构成基本测试表来在验证前期担保设计的基本功能。
随机测试
与确定性序列相反的则是随机序列（random sequence），随机序列通过预先定义的约束每次随机产生合理的数值，进而通过勉励产生器给出测试序列。下图可以解释，与直接测试比较，随机测试用例可以直接通过勉励天生器转化为测试序列。
产生随机数的方法有很多种，有很多措辞可以实现，但是考虑到灵巧地给随机绑定一些约束的时候，我们须要特定的措辞供应这样的属性，目前常用的措辞有SystemVerilog和e措辞。从下面Wilson 2014年调查数据来看，SystemVerilog的 利用率大致已经上升到了75%以上。
约束实际上是随机勉励能否符合接口协议，以及朝着验证焦点而去的关键。随机约束天生器一样平常可以通过静态约束或者动态反馈约束来给出每一轮的勉励。从下图可以看出，在实际的验证环境中，每每有很多对随机约束起到掌握和反馈的成分，它们分别是：
静态随机约束：即默认的约束，一样平常是同勉励一起定义的，不会随着测试而变革。
反馈的动态随机约束：在测试的过程中通过上一轮的结果来对下一轮随机序列给予反馈，通过额外的定向约束（biasing constraint）给出更小的随机域（random region）。
待验设计的功能验证开关：待验设计的功能点有时候可以通过测试序列来关联，进而从该序列是否要验证某一项功能来决定某一组随机约束是否生效。
勉励的构造成员：随机勉励的成员构成，一样平常分为接口成员（跟设计交互），和成员间的逻辑变量（决定成员之间数值关系的变量）。
验证环境的配置参数：验证环境如果是可以配置的，那么这些配置参数也可能会影响序列的产生。
验证环境中不同勉励组件之间的同步通信：如果验证环境中包含多个勉励组件，那么如果要实现这些随机组件之间的协同，我们就须要考虑它们之间实现同步通信（synchronization communication）来实现勉励组合之间的合理性。
基于覆盖率驱动的随机验证
目前常利用的一种随机验证办法是基于覆盖率驱动的，而这种办法也同我们上面提到的影响随机天生的成分“反馈的动态随机约束”一样。从下图可以看出，与常用的随机约束验证办法不同的一点是，覆盖率网络器在每次测试中都会通过监视器来网络覆盖率（紧张指功能覆盖率），将其与已有的覆盖率数据库进行合并，同时根据现有的覆盖率数据库来为下一次随机约束给出反馈。这些正向的反馈便是用来进一步缩窄随机约束域，使其能够定向产生一些序列来覆盖那些未知的功能测试点。
基于TLM的随机验证
对付测试用例而言，它可以指定每一次勉励的数据内容，也可以在较高层次上指定每一次勉励数据包（data packet）的内容。我们在之前《设计的流程》中就先容过用TLM建模来在产品定义早期对设计建立模型，而TLM本身是就模型层次而言，它在更高一级用来描述设计或者验证环境。对付基于TLM的随机验证办法，它指的是在随机环境中利用到的最小颗粒是TLM级别的数据包。该勉励数据包中不但是包含一个时钟周期内该给出的勉励，而是在更长的韶光范围（一样平常为一次完全的数据操作，例如完全的数据读写或者完全的数据包传输）将利用到的数据都加以定义。
通过TLM级别的验证办法带来的好处是验证职员可以更为便捷地描述一些测试场景，更加贴近于真实的用例。这也是由于真实的用例，例如硅后系统测试和固件开拓时基于系统级别的高层次，它们专注的并非某个模块的某一项功能，而是关注于某个子系统或者全体系统的联合事情模式。
从下面这张图可以看到，TLM测试用例由于抽象级较高，须要有TLM2RTL勉励天生器来做进一步的转换。我们将TLM勉励天生器进一步放大往后可以看到它内部的一些转换模块，包括读写操作、复位操作、中断操作还有其它操作。这些方法一样平常都是根据TLM操作命令经由翻译来利用的，我们将这样的勉励天生器称之为总线功能模型（BFM，bus functional model），它的浸染便是将高抽象级的TLM命令转换为低抽象级的硬件端口时序。进一步看，在高抽象级到低抽象级的转换中，除过数据抽象度是在降落以外，勉励所用的韶光也在转换中被实现加注到待测设计接口上面了，因此要完成一项TLM命令的转换，常常须要数十上百个时钟周期。
断言检讨
影响验证产出的一个主要成分是如何将功能描述部分准确地描述，由于准确地描述可以帮助验证职员更方便地去翻译功能描述文档。而对付设计职员而言，他们也须要去捕捉各种可能设计行为来证明设计符合预期。断言（assertion）就供应了这样的特性，它长于针对某一个特定的逻辑或者时序进行预设，一旦设计的实际行不符合断言的描述，则会给出检讨报告。
断言本身不限定于某一种措辞或者工具，而是就它的特性来讲，它可以准确地描述出设计的预期行为。以是有多种实现断言的方法和工具，在比来的20年间，这些被业界支持的基于断言的验证方法和工具如下图所示，在这里我们按照断言方法不同的利用过程可以将它们分为如下几类：
商业开拓的断言IP，可用来插入到HDL中做检讨，例如CheckWare（0-In/Mentor）。
专门开拓的断言措辞，例如PSL（Property Specification Language）。
广义的验证模块，不依赖于特定的措辞或者工具，例如OVL（Open Verification Language/Accellera），这些验证库中含有多个常用的验证模块，可以用来在设计中例化。
根据广义的验证措辞描述而利用其他措辞实现的验证库，例如在按照OVL来实现的QVL（Questa Verification Library/Mentor）和OVA（OpenVera Assertion checker library/Synopsys）。
扩展某一种措辞的特性，延伸出断言的功能，例如SVA（SystemVerilog Assertion）。
由于断言的利用可以分为在验证平台中和插入到设计中，这也使得断言可以同时为验证职员和设计职员所利用。利用断言的上风在于以下几个方面：
由于断言的位置更贴近于不同功能点的源码位置，这使得一旦相应检讨的功能点发生缺点，可以更快更清晰地定位出错误源。
断言自身可以表达更长的时序，覆盖任意长度的功能时序，这就使得它可以在更高的抽象级别来描述设计行为。
断言也有覆盖率的功能，通过断言覆盖率可以建立量化数据来衡量验证进度。
由于断言可以被直接置入到设计中（无论是设计职员置入还是验证职员置入），这都使得断言可以在不同的层次上得到复用，这使得它有更久的生命周期和验证延展。
这里谈到了断言的复用性，实际上断言的运用处景非常多，且它自身便捷的即插即用的特性使得有多种可选的商业断言IP。下面这个例子用来解释断言利用的场景以及它可以垂直复用的特性。
从利用场景来看，范例的断言场景可以包括：
集成连接：例如片上网络多个发起端和目标端之间的访问路径检讨，或者系统集成中各个模块之间的连接关系。
总线协议：针对工业标准总线，有商业验证IP可以帮忙准确验证设计是否按照总线协议履行。
仲裁机制：仲裁机制中的各种类型通过检讨来担保仲裁实行合理。
数据同等性：对付存储单元，数据的同等性检讨可以通过检讨端口读写来预期数据的同等性。
数据进出：对付行列步队设计，断言也可以建立模型来检讨。
状态机：检讨状态机的跳转是否正常。
输入限定：基于假设的输入限定也可以通过输入真个断言来判断输入首先是否符合预期，这对付缺点源排查也有帮助。
自定义断言：用来检讨各个设计的细节，常日这些细节属于设计职员和验证职员关注的功能焦点。
从复用角度来看，断言可以实现从模块级到子系统级再到芯片系统级的垂直复用。从上图可以看出，从单元1在模块级验证时插入的断言“数据进出”和“状态机”两部分在子系统级和芯片系统级两个环境都可以保持监测检讨的状态，这一点要归功于断言可以作为非综合模块被置入到设计中，或者通过绑定的形式作为模块并行于设计进行例化（同时不影响设计构造）。而在子系统中，新的断言部分“子系统集成”又可以履行用来检讨从单元1与从单元2之间的集成关系，这一关系检讨在芯片系统中也可以连续保留下来。
至此，我们将动态仿真验证的方法先容完了，在今后更多的篇章中还将对这些主流方法进一步谈论。下一篇将会同大家一起领略《静态检讨》的魅力。
验证的方法篇之二：动态仿真
（博客链接：http://www.eetop.cn/blog/html/28/1561828-438526.html）
与动态仿原形对的是静态检讨，它本身不须要仿真、波形勉励，通过工具的赞助，验证职员即可以创造设计中存在的问题。静态检讨方法较为分散，且关注的验证领域也不为同等，我们将目前紧张的方法概括为：
语法检讨（syntax check）
语义检讨（linting check）
跨时钟域检讨（CDC，cross-clock domain check）
形式验证（formal verification）
语法检讨
如大多数编译器（compiler）自带的功能一样，各种硅前验证的工具一旦须要建立模型（无论是针对动态仿真还是静态检讨的模型），都须要其编译器对目标措辞供应语法检讨。对付硅前阶段，各种编译器带来紧张的好处是帮助检讨明显的语法缺点，例如拼写、声明、引用、例化、连接、定义等等常见的语法缺点。
不同仿真工具对付同一措辞标准的阐明和理解也可能存在偏差或者不同的严格程度，以是在利用不同厂商、不同工具供应的编译器时须要把稳的地方包括：
理解不同的语法格式或者实现路子，可能在编译器A面前可以通过，却不见得在编译器B之前可以通过。这种差别常日来讲，跟仿真器的特性和支持也有关系。如果在同一个硅前周期利用了不同的工具，那么我们要做的该当是让目标代码（无论是设计代码还是验证代码）知足所有工具的哀求，确保它们跟工具之间良好的语法认可度。
由于措辞本身也有不同年份的标准，以是我们须要在编译过程中把稳加注不同的选项，例如如果默认编译器按照VHDL93标准来编译VHDL文件，那么要显式地声明VHDL文件是87格式，须要额外加注编译选项。
除过语法检讨，编译器选项中也会包含一些检讨设计代码风格是否符合可综合规范，建议在编译阶段加上这些选项，它们会帮助检讨设计中较明显的漏洞。
对付SystemVerilog，值得把稳的是，最新的SystemVerilog2012中的标准并没有全部被编译器支持，而且不同工具的支持程度也是不尽相同的。如果你在利用一个看起来较“偏门”的功能，在实现它之前可以查看一下工具支持文档，或者看编译器的编译结果来查看是否被支持。
对付初步认识仿真工具的人而言，可能不同编译器对付同一项语法缺点给出的缺点提示也不相同。这里我们能够给出的建议是：
负责阅读缺点信息。没错，请你负责阅读缺点信息。
在负责阅读无果的情形下，根据缺点信息的代码可以通过工具命令结合缺点代码来查看缺点信息的详细阐明。
如果你对前面两个步骤仍旧免疫，请找一位更有履历的领路人帮你一起检讨缺点，并且给你一些如何阅读缺点、查找语法缺点点的方法。
语义检讨
语义检讨和语法检讨比较，是在设计可行性上做深入检讨的（当然条件也是首先通过了语法检讨）。语义检讨是通过专用的工具来帮忙完成的，例如0-In（Mentor）以及Spyglass。常见的语义检讨包括的范围有：
常见的设计缺点
影响覆盖率收敛的问题
可能会产生‘X'以及受其影响的设计部分
进一步细化这些检讨项，它们会检讨设计的这些部分：
验证收敛性检讨
无法达到的逻辑部分
无法跳转到的状态机状态
无法完成的状态机跳转逻辑
硅效用检讨
寄存器被固定赋值
寄存器未初始化
X值的传播
功能问题检讨
状态机检讨
总线检讨
case语句检讨
数学逻辑检讨
这些静态检讨最大的便捷在于，一些功能实现以外的设计问题可以在更早期就被创造，而且这些静态检讨也有助于完善设计编码风格，使其更有助于覆盖率的收敛和后端综合往后的逻辑实现保持（例如寄存器未初始化或者固定赋值）。语义检讨最明显的两个上风在于：
不须要验证环境：即无论设计职员还是验证职员可以险些同设计同步来检讨设计中明显的设计问题，这对仿真之前扫清明显障碍、担保设计质量很有帮助。
不须要写断言：这跟我们接下来先容的形式验证办法有关。由于语义检讨无关乎设计从功能描述到功能实现的翻译准确度，以是也就无须要断言参与进来。
跨时钟域检讨
大多数繁芜的设计都拥有不止一个时钟，而且多个时钟之间也是异步的关系。对付设计中的不同功能模块如果被不同的时钟驱动，那么就会形身分歧的时钟域（clock domain）。对付单一时钟域的设计而言，它的设计办法和验证环境都较为大略。而对付多时钟域而言，不同时钟域之间的逻辑通讯就须要考虑同步问题了。在这里，用来验证这些设计哀求的过程就被称为跨时钟域检讨。
之以是须要同步是由于不同时钟域的时钟是异步的关系，这使得从时钟域A的旗子暗记进入时钟域B被采样时，每个周期都会有相对时钟B不同的延迟，这种随机性可能会导致建立或者保持韶光无法知足（setup timing or violation timing violation），进而导致不可预期的功能失落败。
这种跨时钟域问题无法通过常规的验证方法剖析，例如动态仿真，也不能被静态时序剖析（static timing analysis）判断出来。而这里通过静态的跨时钟域检讨就可以剖析这一问题。通过该方法可以在早期的RTL阶段来识别出跨时钟域的通信电路上面是否有得当的同步处理。
以是跨时钟域检讨（CDC）是为了担保所有的CDC旗子暗记都能够得到精确的同步，而进一步来看，CDC检讨是为理解决更大的问题：
是否CDC旗子暗记同步逻辑防止数据在跨时钟域采样往后不准确？
目前支持CDC检讨的商业工具有Spyglass、0-In（Mentor）。
形式验证
形式验证分为两种办法：
等价检讨（EC，Equivalence Check）：用来担保两个电路的行为是等价的，可以用来检讨不同抽象级的电路是否是同等的，例如RTL级和网表之间。
属性检讨（PC，Property Check），又称之为模型检讨（MC，Model Check）：电路的行为通过验证措辞来描述其属性（property），随后通过静态办法来证明在所有状态空间下都知足该条件，否则举出反例（counter example）来证明设计行为不符合属性描述（property description）。
我们在这里先容的是属性检讨，即通过验证措辞（PSL、SVA）来描述设计行为，用断言（assertion）的办法结合设计源进行检讨，来证明设计行为同属性描述保持同等。属性检讨的流程常日如下：
在动态仿真验证中，我们是通过天生各种测试序列来去访问待验设计中的状态（state）的，而理论上所有可能仿真的设计状态被称作可及状态空间（reachable state space）。对付动态仿真而言，要遍历可及验证空间的所有状态是一项非常大的寻衅，这种通过访问状态、检讨结果的办法须要覆盖率反馈来衡量可及状态空间还有多少未被访问。
然而动态仿真验证的办法实际上无法来穷举所有可能的序列去访问设计的可及状态空间，而形式验证可以通过数学办法来穷举出所有的状态空间，彻底验证设计。从下图可以看到，在仿真过程中，通过随机和覆盖率反馈的形式，我们可以产生不同的测试序列来访问状态空间，直到我们创造新的毛病。这是一种实用的测试办法，但是其余一方面，动态仿真验证没有办法去确定设计中不存在毛病，由于图中其它隐蔽毛病依然有待于去挖掘更多的状态空间才能被创造。
而形式验证可以通过数学的方法来遍历状态空间，进而证明设计行为符合属性描述（property description）。在遍历过程中，一旦碰着反例，形式验证工具便会停滞下来，报出反例情景，由用户来核对缺点是否属实，再考虑修正设计或者进一步约束属性使其更精确地描述设计行为。下图中可以看到，在大量的状态空间中，形式验证工具只须要针对某一项属性描述举出反例，即可报告给验证职员，而并不须要穷举所有的反例。等待设计毛病一旦确认、经由改动之后，验证职员可以连续通过工具来对设计和所有的属性进行检讨。
像上面所讲的将属性描述（由断言构成）与设计结合进行同等性检讨的方法已经提出超过20年了，且在这期间也有着不同的商业工具供应支持，例如：OneSpin，0-In（Mentor），Jasper等。下面的图概括出这些工具的进化进程：
在今后关于“基于断言的验证（assertion-based verification）”我们会详细先容SVA、OVL的利用办法。
下一篇我们将对验证中日常利用的开拓环境做一个先容《开拓环境》，感谢你对路科验证的关注。
验证的方法篇之三：开拓环境
（博客链接：http://www.eetop.cn/blog/html/28/1561828-438527.html）
如果我们将影响验证编码效率的成分分为“硬件成分”和“软件成分”，那么硬件成分的配置在短期是可以补齐的，而软件成分则会设计到验证职员的技能能力、调试能力和其它软实力。以是从实用的角度上来看，如果准备在验证道路上长期深耕的话，更早地提高硬件环境配置是一笔越早投入收益越大的事情。
如果这是一篇知乎上的文章我的笔风可能是这样的——
首先你的担保你的手、肩、颈、腰在十年往后还是你的。
其次你须要养成深度编码的习气——论如何不受打扰的方法。
末了回到编码本身，如何可以“键步如飞”，让你的键盘跟上你的脑速。
实际上我们作为稍显严明的一个订阅号，要跟大家分享的验证师日常会是下面这样——
为什么你须要一组得当的鼠标、键盘、座椅和显示器？
编码的时候怎么屏蔽周围的环境对你的影响？——什么样的耳机、音乐对你有帮助？
一套完备的验证开拓环境对你的主要性究竟有多大？
如果是软文，我们会紧张谈论前两个问题，不过这显然不符合我们的气质。有多少位涉世未深的青年在一开始在对SV编码时，手足无措，跟大圣一样手头短缺一件像样的兵器。我们这篇文愿抛砖引玉，将验证职员日常SV编码的开拓环境做一个先容。实际上，我们之前也先容过验证职员须要节制其它的软件措辞例如C/C++或者脚本措辞，这些措辞也须要不同的开拓环境，只是这一部分并不在我们这篇的谈论范围内。
Vim开拓环境
大多数Unix用户的编辑器无外乎利用Vim或者Emacs，而自打有了这两样编辑神器以来，两路的铁粉们从未就孰优孰劣达成同等，这也反响了两种编辑器都有着广大的用户群体。由于我们团队是重度Vim利用者，以是我们就着Vim开拓SV的环境配置做一些先容。下面先容的环境配置中，大量的插件来自于Vim官方网站，有一小部分是用户自定义的设置。
由于Vim添加插件、用户自定义方法很方便，以是，我们Vim的开拓环境包括的特性有：
浏览办法
版本掌握
代码编辑
语法高亮
浏览办法
好的浏览办法的大略衡量办法便是看你在键盘和鼠标之间的切换频率有多少，切换地越频繁也就越影响效率（实在也影响你的手部腱肌康健）。以是，我们建议初学者首先配置好浏览文件的环境，这个中要考虑的成分有：
内嵌的文件源浏览窗口。左边的文件浏览窗口是下载的插件，用来浏览文件，方便切换。
懂得如何切分窗口（以是你须要一个大显示器来更好地支持多个切分窗口），也知道切分窗口的快捷键。
通过快捷键在不同子窗口之间实现跳转，比如在上面显示图中实现三个子窗口的跳转而无需通过鼠标的点击。
版本掌握
对文件版本有严格掌握的项目，须要文件在编辑之前签出（checkout），而在文件编辑完成之后签入（checkin），通过这种办法实现团队内部文件资源的协作。由于版本掌握须要额外的软件，例如SVN、Git、Clearcase，我们在签出签入时须要在Shell命令行键入相应的命令，这又引入了额外的手续。在这里我们也建议通过Vim官网下载相应的文件版本掌握的插件，来实现版本掌握命令同Vim的绑定。
例如，我们团队在利用Clearcase版本掌握工具，通过Clearcase的插件实现了新工具栏和命令的绑定，实现了文件操作环境保持在Vim中，也无需切换环境。
代码编辑
到了代码编辑部分，是我们投入最多的阶段。在这一过程中，我们须要考虑的跟SV编辑干系的部分有：
实现FILE.svh同FILE.sv之间的自由切换。这是由于一些项目中验证职员习气将类的方法声明同方法实现分别放入到.svh和.sv两份文件中，通过快捷命令可以实现这两份文件之间的切换。
通过ctags和taglist的插件实现SV的标识符跳转。这项功能对付快速浏览SV类的方法、编辑很有帮助。
自动补全功能。通过插件实现自动补全，这减轻了编码压力和出错概率。
文本高亮和跳转。通过插件实现在数千行的代码中作下高亮标记，来实现编辑位置的跳转。
学会利用折叠。折叠对付大文本的文件会给你带来清爽的觉得。
学会利用语法的域跳转。例如实现module到endmodule、task到endtask、begin到end的快速跳转。
学会利用录制（record）和宏（macro）操作。这对付批量操作文件有明显效果，省时省力。
语法高亮
语法高亮是减少编码缺点的有效办法，由于Vim默认安装包中没有SV/OVM/UVM的语法高亮，以是用户须要自己在Vim网站高下载这些插件。
实际上，有效武装Vim的插件还有很多，有些小而美的插件在上面的先容中没有提到，但是它们却可以帮你的大忙。我相信，高效的验证职员一定有着自己习气的Vim/Emacs环境配置。不同的环境配置实际上都是朝着高效办理问题而去的，如果你乐意分享你的环境配置，欢迎与我们联系和投稿。
大家都
商业SV开拓环境DVT
DVT（Design and Verification Tools）是面向e、SystemVerilog、Verilog、VHD的集成开拓环境，它同VisualStudio、NetBeans一样拥有完善的开拓特性。DVT是在Eclipse的开放框架根本上开拓的，以是如果你已经熟习如何在Eclipse环境中建立项目、编译、运行和调试的话，那么DVT对你来讲也一定不会陌生。DVT便是来战胜设计验证编码中短缺强有力的开拓工具现状的，它包含的紧张特性有：
加快新代码开拓的速率和质量：通过完善的编辑环境。
简化调试和仿真剖析：自动进行语法检讨和OVM/UVM框架检讨，同时跟NCSim、Specman、VCS和Questa仿真器有良好接口，从而实现在DVT的窗口通过智能记录窗口来剖析仿真结果。
使得剖析繁芜源代码变得更为随意马虎：提取类的UML图、继续关系、成员变量和方法、验证框架的构造图（在未编译的情形下就可以剖析得出）、层次组成和连接、驱动和负载剖析，这些剖析都是动态的办法，而且无需仿真器的参与即可完成。
简化掩护旧有代码和可复用库：通过项目的管理办法掩护代码。
加快措辞的方法学的学习：环境中的快速链接可以直接跳转到目标类定义、方法定义，实现运用层和框架层（OVM/UVM源包）之间的跳转，方便学习。
提高为代码编辑文档的体验：自带的文档天生工具可以帮助提取文本的注释，从而天生可读性更好的HTML文档。
缩短项目进程：由于DVT本身可以同Clearcase、SVN、Git等版本掌握插件以及同毛病跟踪系统例如Bugzilla完成集成，以是对付项目而言它是一个中央化的项目履行平台。
此外，DVT的调试器是开拓环境的高等功能，它可以使得在DVT上直接调试代码，无需在仿真器上面做转换调试，这种办法降落了调试的繁芜程度。用户可以通过调试器，直接在DVT中进行：
设置断点：设置、使能、关闭断点或者条件断点。
查看变量：可以在断点停滞确当前运行栈内查看局部变量、类成员和模块旗子暗记，也可以修正变量。
表达式窗口：用户可以自定义表达式，并且不雅观察表达式的值变革。
输出窗口：不雅观察仿真输出，大概可用户敲入仿真器支持的命令来与仿真器互动。
在根本的措辞编辑和调试根本之上，DVT的验证平台语义检讨器（testbench linter）可以通过静态代码剖析创造不得当的语句、代码风格、无用语句、与OVM/UVM相悖的利用办法和性能问题。它可以通过改进验证代码的可靠性和掩护性来更好地帮忙验证职员完成验证任务。常日的编译器会检讨代码是否符合措辞规范，而报告出语法缺点，但是编译缺点不会给出代码可靠性和掩护性的报告，也不会给出建议如何使得代码与方法学保持同等性。
此外，DVT自带的文档天生器可以用来从代码中的注释自动天生准确的HTML文档。这种办法使得设计职员和验证职员只需花费更少的精力来掩护一份组织良好的设计和验证文档。或者设计验证职员也可以在原有的代码根本上通过注释办法天生一份更直不雅观的文档，文档的内容可以包括笔墨描述、继续树、设计构造、UML类图和验证框架等。
有了一件称手的兵器，我们在接下来打野升级的路上会更顺利一些。我们下一篇中将会连续方法篇，为大家推出《虚拟模型》。
验证的方法篇之四：虚拟模型
（博客链接：http://www.eetop.cn/blog/html/28/1561828-438528.html）
对付系统虚拟建模的广泛定义是它包含高抽象级的系统硬件模型，而与此同时软件开拓可以在此硬件模型根本上展开。通过这种办法，虚拟模型不但可以让软件开拓在更早期就展开，而且还可以收成软件开拓的反馈，从而交给硬件设计。
这种反馈在以往的瀑布模式开拓周期中是无法实现的，由于软件每每须要等到硬件设计制造完成往后才能展开。通过虚拟模型，硬件可以更早地收成软件反馈而对现有的设计更早地进行修正。这种硬件和软件之间更紧密的协作办法，譬如在早期软件利用虚拟模型测试性能时就可以提出是否须要硬件加速器，或者在更早期来判断硬件和软件的协同任务是否可以知足总的功耗目标。
在目前多核的移动平台上，一个不断增长的需求便是通过划分不同的任务到多核上面来取得更好的性能，而这种软件层面的估测就可以在更早的虚拟建模阶段完成。目前我们通过多项虚拟建模的技能例如协同设计、协同仿真和协同验证，来企图在更早期就可以创造设计中的毛病，使得修正这些毛病可以在相对随意马虎履行的阶段完成。通过这种将设计问题更早期暴露出来的办法来使得芯片可以完成一次流片成功的目标，和贴合市场越来越紧迫的窗口需求。
虚拟建模包括一系列的验证技能，他们有仿真（simulation）、仿照（emulation）、FPGA，而目前的现状是验证职员每每会通过稠浊这些方法来在最短韶光内确定更好的效果。在这里，我们将虚拟模型先限定于仿真（simulation），而将仿照和FPGA归类为硬件加速技能，我们会在后面的文中紧张先容硬件加速技能。
那么，虚拟建模的优点有哪些呢？
在早期可以通过软件测试来创造硬件和软件的问题：这种办法可以提前硅后软件开拓，更早暴露软件和硬件之间协作的问题或者是边界定义不清晰的问题，而在RTL阶段乃至模块定义阶段就创造和修正毛病。
软件开拓反馈从而修正硬件构造和RTL设计：软件和硬件紧密协作带来的是，软件也参与到了硬件构造定义的事情中。
减少硬件协同软件的验证事情：由于有了虚拟模型，使得硬件设计有源可寻，同时软件的早期进入也可以帮助硬件完成一些难以通过仿真完成的测试，使得系统级测试更早期可以完成。
为用户建立硅前平台模型：更早期的硅前平台模型一旦经由软件测试，可以为用户供应可开拓的平台。
硅后平台的参照模型：硅前平台模型有着更可见的内部性能、功耗和设计旗子暗记，而这些内部细节在物理芯片上都是不雅观察不到的。
截止现在，虚拟建模仍旧是一项不断完善和发展的技能，而它也正在被广泛的利用的芯片设计验证领域中。那么目前紧张的虚拟建模平台有哪些呢？
目前工业界同等推广TLM（Transaction Lelvel Models）用来建立抽象层次的模型，而TLM也已经发展到了TLM 2.0标准。紧张支持TLM2.0标准的措辞有SystemC和UVM方法学。目前紧张的EDA厂商都可以支持SystemC的仿真，我们可以将支持SystemC模型的仿真平台分为两种：
各种紧张的仿真器（simulator）：它们支持SystemC的编译和建模，而由于SystemC本身可以垂直大跨度的硬件抽象度，以是模型既可以拥有TLM端口，也可以拥有硬件旗子暗记端口。如果模型在边界上规定了旗子暗记时序，那么也可以将端口旗子暗记添加到波形窗口中进行查看，当然也可以通过断点的办法来调试SystemC模型。
专用的虚拟建模平台（virutal prototyping platforms）：这些专用平台是专门做事于虚拟建模及其仿真的，从抽象级来讲，它们的视野显著高于RTL级仿真，从开拓链来看，它们会从更早期的产品定义阶段开始。更详细地说，这些专用虚拟建模平台紧张做事的阶段包括有：构造设计和评测、许可硬件软件之间的权衡剖析、早期的性能和功耗评估、软件集成和测试、为RTL验证供应参考模型。不同的EDA厂商供应的平台有：First Encounter（Cadence）、Vista（Mentor）和Virtualizer（Synopsys）。
那么在这些平台上，虚拟模型大致建立的办法是什么样的呢？
实际上，虚拟模型的建立也类似于硬件RTL的建模，只是从抽象层次上来讲它们提高了，或者从代码量上来讲它们变少了（但不见得变大略了，这要看逻辑实现的细节程度）。由于芯片中各个子模块都会对照着不同的软件驱动库、运用库，我们须要在芯片系统级建模过程中最大限度地席卷所有子模块对应的TLM模型，这样才会供应给软件最大程度上的自由度（即可以将日后为硅后开拓的软件先在虚拟平台上测试）。
在虚拟建模平台上，可以通过可视化界面和自动智能的办法将已经准备好的模块进行集成。在集成过程中，我们须要紧张讲模块种别按照供应方分为：
自建虚拟模块（即按照自定义的硬件来对照建立的虚拟模块）。
商业第三方IP（这些虚拟模型IP也对应着硬件IP模块，由于完善的商业IP交付包同时包含多个设计验证部分，包括RTL、SystemC、验证平台等）
如下图，在虚拟模块集成过程中可以从现有库中选择IP：
如果虚拟模块须要用户自定义，那么平台工具也可以通过用户大致定义接口、内部属性来天生框架，而后等待用户去添补该完备的功能，例如下图：
同时，通过可视化窗口完成系统集成：
当通过虚拟建模平台完成集成往后，虚拟系统会完成编译建立模型，进而交付给软件组以供开拓，其余软件组的反馈也会报告给硬件设计组。
此外，由于虚拟模型可以考虑作为参考模型参与到RTL仿真中，这种SystemC同RTL的协同仿真模式包括有：
协同设计（co-design）：将SystemC模型集成到现有的设计当中，作为暂时替代设计的一部分。对此种设计的哀求是虚拟模型的边界接口该当有得当的时序来同相邻的模块完成时序的同等性。
协同验证（co-verification）：将虚拟模型作为参考模型集成在验证环境中，为此一样平常的哀求是虚拟模型通过TLM在环境中实现集成。
至此我们将虚拟建模的上风和方法大致讲完，目前越来越多的公司都已经运用该方法来尽可能地提前软件开拓韶光，并在早期反馈给硬件设计。同时，此种方法对付团队学习曲线、如何在旧有硬件设计流程中集成并有效组合、如何考虑虚拟建模在远期代价和人力额外投入的性价比、如何实现虚拟模型团队同设计验证团队的整合等等都是对现有事情办法的寻衅，这一点须要团队整体都看到它的上风并且乐意为之改变，才会将它的上风更好地发挥出来。
我们下一篇将为你带来《硬件加速》，一起来看看业界最新的硬件加速仿照科技。
验证的方法篇之五：硬件加速
我们之前先容过的动态仿真和静态检讨方法各自具有上风，然而它们都不具备的一个上风在于速率。尤其是在SoC的设计体量越来越大的时候，仿真速率成为制约验证进度的主要障碍。同时，由于仿真速率的限定，一些真实的用例也无法在RTL级仿真很快地呈现结果，这种困难在硅后软件测试创造问题反馈给硅前硬件团队时更加明显，由于常日这意味着硬件团队须要将耗时很长（相对硬件仿真的承受能力）的软件进行剖析，找到可能的问题点，拆分软件场景，进而在硬件仿真上考试测验重现问题。仿真速率的限定使得在硬件仿真方法上面无法很好地早期测试软件，而这一任务一样平常交给了其余两种方法：
虚拟模型平台（virtual prototype platform）
硬件加速（haradware acceleration）
上一篇已经谈论过虚拟模型平台，它的一项上风在于可以在硬件设计之前就用来建立硬件模型，并通过集成来天生虚拟模型平台，当然这也意味着新的事情量和技能学习须要引入进来。那么，对付硬件加速而言，它常日的流程是如何呢？一样平常须要等到硬件设计初步稳定，进而将其映射到可配置的平台上面，因此设计的数字电路部分可以通过更高的时钟频率（受限的，无法达到真实芯片频率）来仿真。这种办法比较于RTL仿真速率已经有了质的提升，稍后我们会比较速率的提升上风。
目前业界紧张的硬件加速办法分为两种，即FPGA和专用的仿照器（emulator）。实际上，专用仿照器仍旧是基于FPGA的定制产品，只不过比起商用的FGPA（Xilinx、Altera），它在硬件加速方面还有其它显著的特点：
内部可编程单元的连接网络办法不同于商用FPGA，这使得它在综合布线效率上面显著优于FPGA，而且对付内部可编程单元的利用率也高于FPGA。
外部连接网络的办法也不同于FPGA，这使得它可以通过多路复用技能实现片上存储共享而不再像FPGA一样须要定制的存储器，同时通过扩大I/O管脚数目来扩展器件之间通信带宽，以此来确保仿照器之间的通信速率不会成为瓶颈。
通过智能的内部数据采集和内置追踪存储器的帮助，这使得被映射到仿照器平台的所有逻辑单元在理论上都是可见的。这种采集办法在一开始建立平台时就可以通过定义采集旗子暗记列表来修正内部走线，同时也不会降落仿照速率。
仿照器的这些特点与FPGA可以很好地区分开来，而在实际事情中，FPGA和仿照器利用的场景也有所不同。FPGA原型验证紧张是针对付小型设计或者单独的IP，而仿照器则是用来面向更大更繁芜的SoC设计。FPGA紧张是为软件开拓供应平台，而仿照器则是为了硬件和软件协同验证和全体系统的测试。随着最近10年，仿照平台技能日趋完善和随意马虎利用的情形下，与FPGA比较，越来越多的公司开始考虑利用仿照器，这紧张是基于如下的成分：
更快的平台建立韶光
更快的编译综合时间（从RTL到仿真运行）
良好的调试条件，例如旗子暗记可追踪，波形可保存，设置断点等等
仿照器的高存储量、可裁剪同时支持多个任务供多个用户利用
通过云端来购买利用流量利用远程做事，而不再像FPGA须要一次性购买，减低前期投入本钱
随意马虎操作
以下是FPGA同仿照技能的比较：
目前业界的硬件加速标准并未达成同等，主流的三家公司实现硬件加速的详细技能也各有特点。我们在上面提到的仿照器（emulator），通过将设计逻辑映射到可编程单元的办法，紧张有Veloce（Mentor）和ZeBu（Synopsys）。
Veloce采取的技能正是我们上面提到的，通过定制的可编程单元（非常类似于FPGA），不同的内部连接网络构造，以及透明的可调式电路实现在该仿照器平台上。平台上的每一块仿照器芯片都可用来仿照一小块的设计逻辑，而全体芯片的功能则是通过集成各个仿照器芯片实现片间快速通信来实现的。
而ZeBu不一样的地方在于它直接采取FPGA，而且通过技能也将透明的可调式电路技能和其它特性实现到FPGA中，多个FPGA进一步来组成完全的芯片功能，这种办法对付用户来看，与Veloce的差异并不大。
在此之外，Cadence公司的仿真加速器（simulation accelerator）Palladium也显得分歧凡响。它作为独立的加速器平台，内部包括有数量巨大的大略处理器，而每一块处理器又可以来仿真一小块设计的逻辑部分，并且将运算结果在它们之间通报。看起来，这些处理器每一个的运算速率都要低于我们的桌面处理器，但是由于我们通过成千上万个小的处理器并行事情，这使得实际的运算结果要大大高于独立处理器的表现， 同时，这些独立的小型处理器也支持透明化的调试办法。
通过这些仿照器，我们可以主机的验证平台到仿照器的勉励场景，同时，如果我们须要设计一个USB器件，我们可能会将物理层的USB与仿照器相连，进而同电脑或者其它器件相连。这时候，我们将仿照器与真实天下的运用器件连接的办法（不同于与主机上的验证平台连接）称作是在线仿照（in-circuit emulation）。随之而来的问题是，一样平常真实天下的频率要高于仿照平台的频率，这时候我们须要为它们之间频率的差异搭建降速同步的桥接，我们称之为速率桥接（speed bridge）。它紧张的功能是通过缓存快速真个数据，进而主动降落快速真个速率，来适配两端的数据率。
如果我们要将RTL的验证平台移植到仿照平台上，我们可以通过可配置平台来仿真待验设计，同时将验证平台运行在加速平台以外的主机上，这种办法被称为联合仿真（co-simulation）。这些勉励可以由软件的验证环境从主机给入到可配置平台上面，或者由真实天下的接口给入到可配置平台。其余一方面，硬件加速的方法受到的限定是它们没有办法像RTL仿真一样透明地去不雅观察硬件旗子暗记和内部逻辑，也无法很好地去调试硬件程序（例如设置断点）。
在实际联合仿真平台中，加速因子最大的受限成分在于平台外主机的验证平台运行速率，以及它与加速平台之间通信的速率。因此，在构建一个联合加速平台环境时，我们须要考虑的是：
尽可能地将验证平台实现为可综合的，这样有助于它们也可以被移植到加速平台上，从而减少对平台外主机的依赖性。
如果仍旧有一些验证平台组件无法被移植到加速平台上，那么我们须要考虑主机与加速平台之间的通信速率如何可以变得更快，或者通信次数更少（少即是“快”）。这里，通过TLM通信办法，提高每次通信的信息量而减少它们之间须要同步的次数，也是值得采取的加速方法。
我们下篇将为大家带来关于功耗的《效能验证》。
验证的方法篇之六：效能验证
在PC时期，还少有人将处理器功耗提上验证的日程，由于大家对付处理器性能的关注多于功耗的考虑。在十多年前，大家利用2G的功能手机，“超长待机”一词逐渐被作为主打广告语进入了用户的视线，这得益于硬件本身的低功耗（性能本身不哀求太突出）和大容量的电池。
而到了智好手机时期，伴随着将桌面办公和娱乐移动化的需求，一部手机承载着以前桌面机的性能。这种哀求之下，也催生了智能机市场在过去的几年当中发达增长，由于随着软件性能对硬件的日趋增长的哀求，以及移动网络数据传输性能的不断提高，都在促进者硬件性能的层层上升。
在移动时期，硬件提升性能的办法紧张表现为以下几种办法
提升原有处理器性能、存储器空间、数据总线带宽或者采纳多核处理办法。
增加额外的协处理单元，新的功能模块（例如Video/GPU模块）。
在后端许可的情形下提高事情时钟频率。
提升工艺制程。
总体上看，随着性能的提升，能耗也会逐步提高，这在过去的PC时期还不是一个显著问题，但是到了移动真个现在，就加倍哀求硬件不但哀求性能有提升，也同时须要考虑能耗是否也可以接管。我们这篇文章紧张以移动芯片为例，来谈论目前关于性能（performance）和效能（power consumption）的权衡。
从上面这张移动硬件领域的技能缺口图上可以看出，无线通信技能被标注上了1G、2G、3G和4G。喷鼻香农定律预测出每8个月传输性能会提升一倍，同时摩尔定律也指出了每18个月晶体管的单位密度会提升一倍因此处理器的性能也会提升一倍。同样地也有对电池生产商每10年旁边能源密度提升一倍，而存储器的性能大约每12年会提升一倍。
那么从这张图不同器件的特性增长来看，就揭示了对付耗移动硬件的技能缺口，它们是：
处理器和存储器之间的带宽缺口，即处理器的性能会同存储器的带宽缺口逐步增大，进而存储性能无法知足运算性能。
效能缺口，这是由于传输和运算速率双双大幅提升，使得功耗显著提升，但由于电池技能受限，使得功耗成为了瓶颈之一。
算法繁芜度缺口，这是由于传输速率超过了运算速率的涨幅，也因此须要更多的处理器来共同完成越来越繁芜的算法。
而上面讲述的技能缺口同目前硬件提升性能的办法也大致保持逻辑吻合。我们本篇紧张就如何办理能效缺口入手，讲述目前主流的能效验证办法。
功率和能量
首先我们先引入基本的观点，能率和电能在日常器件能效谈论中常常会提起，然而它们是不同的两个术语。
功率 = 能量/韶光 （瓦特）
能量 = 功率韶光 （焦耳）
有时候，我们设法降落功率也会随之降落能耗，但这也不是绝对的，例如有些任务在高速高功率情形下可以很短完成，而且效果实际上要比在低速低功率下花费更永劫光的效率更高。又比如，如果静态功耗可以忽略的条件下，如果一个任务须要固定的时钟周期数完成，那么无论时钟快还是慢，它花费的能量是一样多的；然而，当静态功耗无法忽略的时候（例现在朝的工艺制程已大致在10纳米），反倒是时钟更快、动态功耗越高的情形下，完成这项任务更高效。以是，效能的验证和评估实际上便是对能量利用效率的优化路子。
静态功耗和动态功耗
以是从上面的例子，我们知道，如果要考虑功耗，须要考虑两部分，静态功耗和动态功耗，总的功耗表现可以描述为如下
总功耗 = 开关功耗 + 短路功耗 + 静态功耗
这里开关功耗和短路功耗构成了动态功耗的部分。
开关功耗 = C•V2 •F
C = 负载电容
V = 电压
F = 频率
短路功耗 = V • I (短路)
I（短路）为在开关怀换过程中N极和P级同时有效时发生的电路电流
静态功耗 =V • I (泄电)
而静态功耗（或泄电功耗）则是晶体管在激活或者保持状态下都会涌现的泄电造成的功耗。
节能技能
实际上移动硬件节能（省电）技能是一项全面的流程，从工艺制程、电路、封装到模块设计、SoC设计、系统和运用软件开拓等等，全体环节都须要有效利用能量。下面这张图是从芯片硬件和软件所采取的节能技能（省去工艺制程）：
同我们之前先容过的硬件设计流程类似，节能的设计流程也是从方案到履行末了到集成的。面对越来越繁芜的系统，实用的办法还是从系统设计开始，逐步分解到电路设计，先从硬件层面考虑如何去实现低功耗设计。
能效验证
我们这里紧张针对硅前设计阶段入手，进行能效验证，我们将其紧张分为两个部分：
功能验证：紧张采取PA（Power Aware）（紧张包括有UPF（Unified Power Format）或者CPF（Comment Power Format））办法，通过与仿真器结合测试。
功耗预测与优化：通过第三方功耗剖析工具，结合仿真数据（FSDB/VCD/SAIF），进行功耗预测，并且给出剖析结果。
PA（Power Aware）能效设计流程
UPF/CPF这两种功耗格式比较类似，且可以将它们的流程紧张分为四个部分：
规定功耗格式文件，指定了电源掉电、触发隔离和状态保持等行为，以及它们的掌握旗子暗记。
RTL仿照仿真（门级仿真也可以支持），除过要担保在功能同非能效验证时一样，也要进行低功耗逻辑和断电掌握功能验证，检讨状态丢失、分离和保持。
逻辑功能检讨和等价性检讨（带有UPF/CPF插入的单元）。
逻辑综合和DFT（带有UPF/CPF插入的单元）。
对付硅前验证阶段，验证职员打仗到的紧张是RTL仿照仿真，我们一样平常采纳的策略是：
进行非效能的RTL仿真（不带PA）
在普通RTL功能仿真都通过的情形下，进行PA仿真
在门级仿真阶段，如果韶光许可，可以在后期进行门级PA仿真
功耗预测与优化
一样平常我们期望尽早地获取到功耗的估测信息，而这一期望又与芯片开拓过程相悖，由于每每在流片往后的软件开拓阶段丈量出来的功耗是更准确的。但是如果须要等到流片之后才能丈量功耗，那么低功耗设计的本钱就很大了，由于一方面这使得我们试错的本钱增加，其余一方面产品能效优化迭代的周期也变长了。以是，我们希望在硅前设计阶段乃至是方案阶段（TLM虚拟模型）来估测出芯片功耗，已经剖析出较降落功耗的设计方法。这这里，我们将目光落在RTL和门级阶段，通过现有的功耗设计平台，实行早期物理感知功耗预算与调试、功耗降落剖析、电源效率回归剖析、以及利用仿真器接口对动态运用进行功耗特性剖析。
简而言之，目前这些工具都是为了查看、估计、剖析和降落功耗，通过在RTL级和布局后门级功耗数据指标和报告，为设计和验证职员供应调试和追踪功耗的方法。目前紧张的功耗预测剖析工具有PowerArtist（Ansys）、Spyglass Power（Synopsys）、PrimeTime PX（Synopsys）、Redhawk（Ansys）。而我们在实际项目中通过不同工具的比较，供应了如下的建议：
目前在硅前能效验证阶段，我们相对随意马虎做到的是去采纳PA设计流程，进行相应的RTL仿真和后端流程。在PA验证过程中，我们可以通过熟习的仿真器进行PA仿真，进而在担保原有功能实现的情形下，进一步检讨低功耗逻辑和断电掌握功能。而对付功耗预测与优化，目前有几点成分值得考虑：
工具的评估和选择：不同的工具有不同的适应场景和性能。
如何将功耗剖析与优化纳入项目流程：对付低功耗芯片设计，功耗剖析的方向值得被提上纳入项目流程的谈论日程当中。
如何量化功耗优化成果：一方面我们须要考虑如何选取得当的测试场景来仿照范例的芯片运用，其余一方面也须要选择得当的仿真韶光段作为数据剖析的来源。
将不同代芯片之间的功耗进行剖析比拟给出功耗节省建议：在不同代芯片项目中，通过功耗估测进行节电预测，而后再通过实际芯片的数据给出反馈来进一步改动估测数据，通过这种收敛办法有助于更准确的功耗节电趋势预测。
我们下节课将为大家带来《性能验证》，看一看在硅前阶段我们可以做些什么，让硬件尽可能地在早期知道自己的运算和带宽极限。
验证的方法篇之七：性能验证
在迈过了效能验证的坎往后，我们来到了性能（performance）验证部分。顾名思义，在这部分验证当中我们须要测试芯片的性能，而测试性能又离不开大量的运算或者数据传输。我们之条件到过，硅前RTL验证的瓶颈之一在于仿真速率，而且一旦到了芯片级仿真，这一成分就更进一步放大了。
由于在产品定义过程中，对付系统的运算和数据传输都有哀求，如果可以在产品实现阶段尽早地得出一些基本数据，从而为硅后测算出一些性能数据，那么这不但可以帮助提前指明硬件实际性能是否知足，在有韶光的情形下对付可以调度的硬件设计还可以做出完善性能的修正，同时，这种将性能测试提前的办法也可以使得硅前验证与硅后测试利用的性能测试用例保持同等，进而得出有帮助的性能数据。
性能验证是用来衡量一个别系在特定事情负载下它的相应能力和稳定性，同时通过性能报告也可以用来剖析和优化系统的质量标准，例如可靠性和资源利用能力。性能验证是一门实用的打算机科学工程方法，且在软件工程测试等分类较多，譬如有负载测试（load testing）、压力测试（stress testing）、浸泡测试（soak testing）、尖峰冲击测试（spike testing）、配置测试（configuration testing） 、隔断测试（isolation testing）等。
目前在硅前验证阶段，性能验证还是一个新颖的观点，一方面由于业界对这一测试还没有形成同等的定义和验收标准，其余也是由于性能验证更多地是在衡量测试指标，而与验证（判断设计是否与功能描述同等）本身的聚焦不太重合。但是，对一些性能哀求（同样对付功耗哀求）较严格的硬件设计，我们确实希望在更早期就得出一些数据，而且最好能够赶得上给设计做出反馈并且完善设计，做更早期的回馈，以此来降落开拓本钱。以是，这就哀求我们能够自己先定义出硅前性能验证的目标、环境和方法。
设定目标
目前我们紧张将性能验证紧张侧重在负载测试和压力测试上面，来完成下面的目标：
证明系统（或者子系统）的性能是否符合产品哀求。
衡量哪一部分的子系统会成为全体系统或者某些特性哀求的瓶颈。
在我们开始性能测试之前，该当首先问一问自己“为什么我们要进行性能验证？”，由于只有朝着明确的性能目标方向，才能得出下面的一些测试数据：
数据并发量（concurrency）/吞吐量（throughput）：测试数据并发量是系统整体性能的考量，由于在某一个韶光段，多个子系统会并行事情，而且共享一些网络和内存资源；测试吞吐量是就全体一条完全的数据通路，来测算出它的它的最大吞吐量或者传输速率，例如测试USB的传输速率。
相应韶光：这集中表示在，处理器访问寄存器和存储器的读写回路延迟，也可以适用于其它协处理器或者DMA（Direct Memory Access）。
实际上我们很难在性能验证操持中详细描述出测试办法和场景，而性能验证操持又该当列在硬件设计之前。在实际项目中，我们不能很好地知道软件利用硬件的场景，已经运用软件如何调度不同硬件模块，以是我们只能首先将目光着眼于单个子系统的性能测试，或者通过测试单一的数据链路找到最薄弱的节点。由于上面这种办法可以将繁芜的问题降维到可以理解可以描述测试场景的难度。
测试环境
空想地来看，如果测试环境贴近于用户实际利用的情形，我们得出的数据会更加真实故意义，然而作为硅前硬件实现阶段，我们与用户的间隔又何其远。退而求其次，我们希望可以通过和固件开拓团队互助，找到一些范例的子系统运用处景，在硬件仿真上实现来不雅观察子系统的性能。
同时为了将测试的本钱降落，我们尽可能选择原有的功能验证的环境，通过动态的环境配置或者仿真开关来实现监视系统性能的组件。这些监视性能的组件可以分为：
在线监视（online monitoring）：一样平常将一些监视器（monitor）绑定到目标模块或者总线上面，来动态监测目标的运算处理量或者数据传输速率。
线下剖析（offline analysis）：将监视到的数据首先通过仿真记录下来，通过线下的脚本剖析，绘制出性能的颠簸曲线。
验证方法
从性能验证流程来看，目前我们参照微软的性能测试方法学流程，它包括以下步骤：
构建验证环境：一样平常利用现有的功能验证环境，通过更新使其可以完成性能检测和剖析的任务。
决定性能验收标准：在测试之前首先限定反馈韶光、吞吐量、资源利用率等验收标准。一样平常而言，对付硅前测试，我们可以测出反馈韶光和吞吐量，而资源利用率是一个别系观点，较难测试。
制订操持和测试用例：须要同系统职员、固件职员一同列出主要的测试场景，同时建立可以衡量性能的表格。
配置测试环境：如果环境足够灵巧，我们乃至可以在递归测试（regression test）中开关性能检测功能，来平均衡量子系统的性能。
开拓用例和测试：开拓测试用例，提交和检测带验模块，网络性能检测数据。
剖析结果、反馈和再测试：剖析测试数据，提交性能报告，如果硬件性能与操持的性能之间有缺口须要硬件做出修正。而后在此测试，直到硬件性能符合预期，知足验收标准方可结束。
正如前面提到的，实际项目中的性能测试除了不规范和较难实现意外，也短缺明确的验收标准。这就使得不同验证职员编写的测试用例间隔真实情形运用的差别不等，而且检讨性能的标准也各不相同。目前，我们通过下面一些形式来帮助实现性能验证：
在芯片网络构造的端点处（network terminal）绑定总线协议的监测器，以此来在网络核心出检测芯片整体的通信情形，打算网络的实时吞吐量，以及单个挂接的子系统的数据传输速率。
将一些RTL仿真较为耗时的测试用例迁移到硬件加速平台，利用emulator来完成性能测试。
为测试用例供应一些宏定义用来做高密度数据传输，以此来担保有足够的数据量用来测试数据传输的饱和峰值。
我们下一篇也将是本系列的完结篇，回顾和展望将来的验证需求和发展趋势——《趋势展望》。
验证的方法篇之八（终）：趋势展望
目前紧张的验证办法包括动态仿真、形式验证和硬件加速，那么如何选择它们，已经是否可以构建一个可复用的验证平台实现这些不同验证方法的超过是接下来我们须要关心的。随着设计的尺寸和繁芜度在不断提高，即便有IP复用的办法来缩短设计韶光，更多模块之间的互动可能性也哀求更充分地去验证这些状态空间。目前仿真技能的瓶颈在于速率，随着这几年实际项目中的切身感想熏染，仿真技能除了须要EDA厂商供应加速办法以外，项目自身也须要结合实际情形使得仿真可以实现相对轻量化来担保可接管的速率。
形式验证可以穷尽考验一些设计属性。对付一个得当尺寸的IP，它只须要通过一些时钟周期就可以穷尽考验出设计属性是否知足。例如一个32位的乘法器，如果通过动态验证可能须要几年的韶光来穷举出所有可能的情形来完备验证，然而对付形式验证而言，每每几分钟到数小时的韶光就可以了。同时，形式验证伴随着设计的繁芜度提高状态空间指数增长的情形下，运行速率也急剧低落，IP是得当的形式验证尺寸。
只管在学术和工业领域，对付形式验证的算法研究非常生动，它还须要办理的问题是，利用者对付形式验证措辞的不精通。由于利用者还须要担保设计属性描述是精确反响实际设计的，同时属性描述的总和可以对等一个设计的所有功能，只有这两点知足了，才有足够信心确信形式验证的完备性。目前我们可以通过EDA厂商供应的可复用的断言库来实现高层次的属性描述，填补我们对断言描述本身的知识缺少。此外，形式验证让我们“不那么放心”的一点是，它无法像仿真一样为我们供应一个动态的行为，而验证职员又须要“眼见为实”来亲自判断设计的实际行为是否精确。以是，如果采纳形式验证，建议的一种办法为以动态仿真为赞助手段，来完成基本的功能勉励和检讨。
硬件加速的历史要更悠久，这可以回溯到1980中期到1990中后期，在RTL仿真还未推出被广泛利用之前，霸占验证市场的还是门级硬件仿照技能，随着Verilog和VHDL的措辞推出和自动逻辑综合技能的运用，RTL仿真就逐渐取代了硬件加速技能。这一技能更迭的背后，关键成分还是速率，由于那一期间的设计还不敷以繁芜到仿真器性能无法知足的情形。20年后的本日，硬件加速技能显然又有着收复失落地的趋势，三大主流工具商都供应各自的硬件加速办理方案。
硬件加速技能的速率上风还是相称明显的。动态仿真的性能均匀保持在1KHz，硬件仿照技能大致在1MHz旁边，而FPGA在10MHz旁边。无论是硬件仿照还是FPGA，都要比动态仿真技能的速率显著提高不少，通过更快速的验证技能，我们也才能够抵消日益繁芜的设计，和体量不断增大的嵌入式软件代码测试。
那么是不是硬件加速技能便是未来的主流呢？仍旧不是绝对的。目前硬件加速技能也有自己的不敷，比如：
编译韶光较长。这是由于硬件加速加速须要额外的逻辑综合和硬件映射的韶光，而综合、布局、布线和映射在动态仿真中是不须要的环节。
调试手段少且慢。只管最新的硬件加速技能可以实现记录任何旗子暗记、修正旗子暗记或者等待旗子暗记事宜等常用的仿真调试手段，然而由于技能限定，如果要添加或者修正新的旗子暗记，仍旧须要再次编译花费大量事宜。此外，由于存储的限定，我们也无法记录所有层次的旗子暗记，而只能有选择性的记录某些旗子暗记在某一段韶光内的行为。从调试流程上来看，硬件加速技能仍旧无法达到动态仿真的易调试程度。
这么看来，只管在速率上硬件加速有显著的上风，但是从调试层面，动态仿真和形式验证也有其优点。那么，实际中我们是怎么结合这些技能的呢？一样平常我们方向于以下办法：
在模块级或者IP级验证中，更多利用动态仿真和形式验证，只管即便将毛病率曲线更快更多地收敛在这一层次。
到了芯片系统级验证中，我们方向于利用动态仿真测试模块之间综合的系统任务和集成关系。
对付耗时的测试用例，例如固件启动测试、性能测试、大规模数据存储测试等我们会在系统测试阶段利用硬件加速加速来更快得到结果。
从验证平台搭建和复用的角度出发，我们也须要考虑，如何实现一个可以横跨这三种技能的可复用平台呢？通过一个统一平台，如果可以自若地在这三种技能之间实现横向超过，以及完成从模块级到子系统级再到芯片级验证的复用实现纵向复用，这将是接下来实现技能领悟和验证层次复用的方向。为谈论这一方向，我们分别以下列问题展开阐述：
不同技能之间的验证平台横向超过
不同层次之间的验证平台纵向复用
技能之间的横向超过
在办理横向超过的问题之前，我们先须要理解为什么有这样的需求？从下面这张图可以看到这三种技能之前有着共通的技能桥接，和一些核心的根本技能：
我们的核心根本技能有验证IP、覆盖率、调试和软件驱动测试，而三种技能构建于这些根本之上。例如它们都须要供应调试办法、也须要供应各自的覆盖率来完成验证。
形式验证和动态仿真之间，它们可以通过断言和X-prop技能来桥接，由于这两种验证方法都可以通过两种技能完成验证。
间于动态仿真和硬件加速之间，我们也可以通过软硬件协同验证的办法，实现这两种技能的桥接。
而对付断言VIP，我们已经知道的是，可以利用它完成形式验证，或者植入到动态仿真环境中。而一些可以综合的断言VIP，也可以被移植到硬件加速平台中连续完成验证的任务。
那么基于这些项目实际中的桥接，如何设计出可以合并的数据库和通用的验证平台就成为了关键。但对付这两点，目前三大工具商还缺少一种完全的办理方案。例如，验证的覆盖率数据库如何在三种技能中实现互通和合并？如何定义出合理的构造完成形式验证平台到动态仿真平台的复用？以及什么样的动态仿真平台才可以顺利移植到硬件加速平台上呢？这些都是还有待思考办理的问题。
层次之间的纵向复用
在不同验证层次之间的复用，我们也会遭遇到实际的痛点。例如，随机约束的仿真方法（SystemVerilog，UVM/OVM或者Specman/e）适宜于模块级和子系统级验证，而直接测试方法（C/C++）则适用于子系统级和芯片系统级的验证过程。在这里，我们看到了子系统级验证有着两种可能的验证方法，我们须要考虑是否选择个中一种，还是两折兼具？如何实现模块级随机测试到子系统级随机测试的复用？如何实现子系统级直接测试到芯片系统级的直接测试复用？又譬如通过何种办法实现从随机约束测试到直接测试的复用？由于只有完成了层次之间的纵向复用，我们验证的是韶光本钱和人力本钱才会降落，验证效率才会进一步地提高。
面临这目前这三种主流验证技能，我们须要从验证效率出发，只有通过合理地选择利用这几种技能，并且实现技能之间的横向超过和层次之间的纵向复用往后，我们才有可能在不断提速的SoC集成设计过程中也保持加速，与设计实现共同飞跃。
至此，我们关于《验证的方法篇》就结束了，到了下一个新篇章，我们将为你带来《验证的操持篇》。
（完）
