芯片验证的策略篇(作者良心大作,验证必看)

芯片验证的策略篇（作者良心大作，验证必看）

本文分六个部分：

验证的策略篇之一：设计的流程验证的策略篇之二：验证的层次验证的策略篇之三：验证的透明度验证的策略篇之四：激励的原则验证的策略篇之五：检查的方法验证的策略篇之六：集成的环境验证的策略篇之一：设计的流程

我们在上一章芯片芯片验证全视中给出过芯片产品开发

的流程图，而在描述中我们将开发流程分为了两条主线：芯片功能的细分不同人员的任务分配即是说不同人员需要在

硅前的不同阶段实现和测试芯片的模块功能。

如果我们从另外一个角度看，芯片的开发即是将抽象级别逐次降低的过程，从一开始的抽象自然语言描述到硬件的HDL 语言描述再到最后的门级网表。而在我们已经介绍过RTL

设计和门级网表以后，这里需要引入一个目前更高抽象级的描述TLM（事务级模型，transaction level models）。

TLM一般会在早期用于构建硬件的行为，侧重于它的功能描述，不需要在意时序。同时各个TLM模型也会被集成为一个系统，用来评估系统的整体性能和模块之间的交互。同时TLM模型在早期的设计和验证中，如果足够准确的话，甚至可以替代验证人员的参考模型，一方面为硬件设计提供了可以参考的设计（来源于系统描述侧），一方面也加速了验证

（无需再构建参考模型，而且TLM模型足够准确反映硬件

描述）。

TLM模型的需求和ESL开发早期的芯片开发模式是遵循先

从系统结构设计、到芯片设计制造、再到上层软件开发的。但随着产品开发的压力，一方面我们需要让系统人员、硬件人员和软件人员都保持着充沛的工作量，同时对于一个芯片项目而言，我们也希望硬件人员和软件人员可以尽可能的同时进行开发。这听起来怎么可能？毕竟芯片还没有制造出来，没有开发板怎么去构建软件呢？在这里我们系统结构人员

会在早期构建一个高抽象级的系统，同时该系统必须具备该有的基本功能和各模块的接口保持信息交互，通过将功能描述变成可运行的系统，让硬件人员和软件人员可以在早期就利用该系统进行硬件参照和软件开发。这种可以为复杂系统建立模型，让多个流程分支并行开发的方式被称作ESL（电子系统级，electronic system-level）开发。

传统的系统设计流程传统的系统设流程是瀑布形式（waterfall）开发的，这种顺序开发的方式存在明显的边界：时间边界：不同的开发子过程之间是保持顺序执行的，几乎没有可以交叠的空间来缩短整体的项目交付时间。组织边界：不同的开发小组之间的交流是计划是发生在前一个过程结束，后一个过程开始的，这也引入了额外的沟通成本。

ESL系统设计流程为了模糊或者融合这种边界，ESL开发流

程通过建立虚拟原型（virtual prototype），又或者称之为TLM 模型来使得整个参与到系统开发的小组做并行开发。之所以可以有这种魔力，是因为TLM模型不再是一种无法被硬件开发和软件开发利用的抽象描述，而是一种更早期开发的软件模型。所以在ESL开发的协助下，更多的自开发流程可以更早跟随系统设计一块进行开发，那么从整体上来看这种方式有助于缩短芯片开发的时间。

除此之外，在前期产品定义的阶段有相对可量化的模型，更有助于早期验证产品的功能、性能是否满足客户要求，也能减轻一些低配置性能的风险和降低过多设计的成本。这是为什么呢？有以下几点：在早期定义产品的时候，市场部会将客户对于产品特性收集回来，而交由系统框架师来定义芯片结构。这中间会存在一些问题，例如系统框架师无法深入到局部功能更无从列举出所有的用例来判断功能是否满足，而对于性能测试方面也只能通过一些表格化数据做出静态估计。这时候，TLM模型可以帮助在系统级别完成模型搭建和虚拟系统集成，甚至帮助测算系统的性能，这对于系统框架师而言会有更多的信心来给出合理的结构配置。正由于可以在早期做出性能评估（而且快速、发生在芯片结构的定义阶段），框架师可以及时地做出资源调整来满足用户的需求。否则，尽管芯片可能是低缺陷率的，但如果它的执行速度不够快、功耗又过高，那么也仍然无法满足客户的要求。过度

设计的结构就跟给一只袜子缀上水钻一样不差但也没有必要。客户给的报价摆在那里，你的设计越过度，不但意味着成本的增长，也意外着更高的复杂度和风险。ESL和TLM 对系统模型的要求使得需要有一门语言可以：纵深多个抽象级别来进行模型描述标准开放的语言高效的仿真性能和调

试接口被主流仿真工具支持本身包含TLM事务级传输的接口这样的一本语言即是我们接下来介绍的SystemC。SystemC介绍SystemC是可以满足TLM模型开发的一种语言。严格来讲，它本身不是一种语言，而是建立在C++之上的一种类库（class library）。SystemC语言可以用来描述系统级别的硬件行为，而这一点恰是其它语言无法满足的。SystemC从2006年被IEEE收入IEEE 1666标准，它本身也易于学习，对于有C++/Java基础和硬件设计概念的人使用起来都不需要太多的学习成本。SystemC语言介绍不在本章的重点，所以我们略去它的更多的语言特性介绍。

语言的抽象级比较而不同的硬件领域使用到的建模语言都

有它们各自适合的抽象级，下图就指出了各个语言擅长的抽象级领域。从左至右，VHDL和Verilog主要用作RTL仿真和数字电路的综合，它们也用来在早期搭建一些验证平台。对于SystemVerilog/Vera/e是用来做功能验证语言的，这其中也包括了它们的随机约束重要特性。同时我们也可以发现SystemVerilog本身可以用来描述硬件做RTL仿真和门级综

合。在此之上，SystemC关注的地方要更偏向于系统层，它在结构层面上可以做更高抽象级的描述，而本身也无法去描述电路的综合网表，但它能够以自己为平台为上层的软件开发做准备。而Matlab和其它语言被用在了数字信号处理上面用来描述和验证算法。

传统的系统集成视角我们前面已经提到，传统的瀑布开发模型无法让硬件人员和软件人员在系统结构定义早期就进入。对于硬件的设计人员和验证人员而言他们都需要等待系统

定义完成之后将功能描述文档分别做出自己的翻译来建立

可综合模型和参考模型。软件人员只有在硬件流片以后才会真正开始进行软件开发，尽管目前的FPGA有着比硬件更快的仿真优势，但无论从时间段（硬件设计的后期）还是从速度（相比软件模型）而言，仍然不是理想的软件开发平台。我们可以认为FPGA等硬件加速工具对于硅后系统测试有积极意义，但是对于更上层的软件层开发的帮助则并没有那么明显。ESL系统集成视角新型的ESL系统开发方式会在系统定义阶段就建立TLM模型，这一模型的建立会对系统人员、硬件设计人员、验证人员和软件开发人员都有显著帮助：系统人员在TLM模型集成系统上会更容易评估系统性能硬件设计人员会同时利用功能描述文档和TLM模型更准确地翻译为可综合的RTL设计验证人员甚至可以直接将TLM模型作为参考模型集成到验证环境中，省去了额外开发