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

芯片验证的策略篇（作者良心大作，验证必看）本文分六个部分：验证的策略篇之一：设计的流程验证的策略篇之二：验证的层次验证的策略篇之三：验证的透明度验证的策略篇之四：激励的原则验证的策略篇之五：检查的方法验证的策略篇之六：集成的环境验证的策略篇之一：设计的流程我们在上一章芯片芯片验证全视中给出过芯片产品开发的流程图，而在描述中我们将开发流程分为了两条主线：芯片功能的细分不同人员的任务分配即是说不同人员需要在硅前的不同阶段实现和测试芯片的模块功能。

如果我们从另外一个角度看，芯片的开发即是将抽象级别逐次降低的过程，从一开始的抽象自然语言描述到硬件的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模型作为参考模型集成到验证环境中，省去了额外开发参考模型的时间软件开发人员也可以在TLM集成后的虚拟系统上面开发软件，而当芯片真正出片以后，只需要做一些基于实际硬件的软件移植，这将大大提前软件开发的起点TLM建模有这么多的优点，然而在真正考虑施行ESL系统集成流程上面，我们也需要考虑到一些实际的问题：TLM建模对于系统人员而言有更高的技能要求。

这不但需要他们掌握SystemC开发，同时也需要他们有硬件描述的基础。

在此之上，他们的工作量将会同时包括功能描述文档和TLM模型，并且TLM需要准确翻译功能描述文档，确保一致性。

对于从传统流程迈向ESL流程而言，我们可能需要做一些妥协，引入专门的虚拟建模（virtual prototyping）团队来协助系统人员翻译功能描述文档，而他们的共同产出也将最终作为一致的参考标准。

尽管已经有了可以被综合的SystemC的子集和代码规范，目前这种方式仍然没有得到业界的青睐。

不过，在某一个硬件模块没有就位，或者想加快仿真速度的时候，我们甚至可以临时将原先的硬件设计用TLM模型替换。

这一点的前提是，系统的仿真行为保持不变，而且TLM 模型接口上的时序可以满足HDL仿真的要求。

当TLM模型被验证环境复用时，就需要TLM与验证环境之间保持标准接口（TLM interface），这样方便TLM模型的插拔。

当TLM 用于软件开发时，这就要求TLM被尽早集成到一起作为整体系统为软件开发所用。

因为软件开发环节中针对某一个功能模块的软件开发仍然是建立在整个芯片系统（至少是子系统之上）的。

所以TLM模型之间也需要有标准接口可以更快速地实现系统集成。

目前我们常见的设计流程仍然是瀑布开发时，或者类ESL开发。

这里类ESL开发指的是开发流程并没有完全遵循上述流程，而是在一些地方引入了TLM建模。

例如下面这张图，由于系统人员的技能限制，项目开发需要额外引入虚拟建模团队。

此外，由于地域上的限制，虚拟建模团队主要服务的对象是软件开发一侧，而他们与硬件设计、验证团队的沟通较少。

这种类ESL的开发可能有多种组合，但我们需要警惕的是，在方便软件开发早期进入项目时，TLM模型是否会同系统定义保持绝对的一致性，从而为硬件和软件方提供文本和代码参考。

从图上来看，这种类ESL的方式是存在风险的，因为虚拟建模团队从系统定义到TLM模型的过程就存在二次翻译，如果翻译不准确，存在疏漏，那么可以想象基于TLM模型的软件开发不会那么容易被移植到真正的硬件系统上面，因为硬件本身也是二次翻译。

所以，理想的合作边界应该如下图一样。

虚拟建模首先需要和系统定义保持原义的一致性，而硬件和软件则可以将TLM模型视为功能描述的一致性翻译，然后各自在TLM模型上进行开发。

下篇文章我们将会探讨《验证的层次》，以及在各个层次上面的验证方法。

验证的策略篇之二：验证的层次从系统定义阶段开始，我们就会将芯片系统划分为子系统，进而又为每个子系统划分为不同的功能模块，直到划分为复杂度合适的模块。

而到了设计阶段，我们又会按照自底向上的方式开始做硬件设计和集成。

从定义阶段到设计阶段再到后端部分，我们整个硅前的流程都是将芯片按照层次划分的，一般我们称之为芯片系统级（chip level/system level）、子系统级（sub-system level）和模块级（module level/unit level），这种层次划分的方式对于芯片的好处有哪些呢？便于拆解功能模块，实现人员的并行工作协同，这一点是从项目执行效率出发的。

对于系统定义而言，这是从主要的功能、性能要求量化为系统不同模块定义的方法。

从设计和验证角度出发，合适的复杂度模块也有助于估计合适的工作量和人员分配。

设计最终是通过模块化来集成的，而验证的环境在模块化以后，也可以方便在更高级的验证环境中复用。

对于后端，在进行了合理的区域划分后，模块和SoC可以并行进行后续的物理设计流程，在每个设计阶段再合成进行相关电源设计、时序分析等设计项检查。