芯片验证的方法篇（下篇）（良心大作，验证必看）
本篇为作者验证系列之验证的方法篇，该验证系列还包括：
芯片验证全视
上篇：
验证的方法篇之一：动态仿真
验证的方法篇之二：静态检查
验证的方法篇之三：开发环境
验证的方法篇之四：虚拟模型
下篇：
验证的方法篇之五：硬件加速
验证的方法篇之六：效能验证
验证的方法篇之七：性能验证
验证的方法篇之八（终）：趋势展望
芯片验证的方法篇（下篇）
验证的方法篇之五：硬件加速
我们之前介绍过的动态仿真和静态检查方法各自具有优势，然而它们都不具备的一个优势在于速度。尤其是在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集成设计过程中也保持加速，与设计实现共同飞跃。
至此，我们关于《验证的方法篇》就结束了，到了下一个新篇章，我们将为你带来《验证的计划篇》。
（完）
来源：路科验证(微信订阅号ROCKER-IC) 及 EETOP BLOG