芯片验证策略六部曲.PDF

芯片验证策略六部曲 验证的策略篇之一：设计的流程 通过芯片产品开发的流程图，而在描述中我们将开发流程分为了两条主线： 芯片功能的细分 不同人员的任务分配 即是说不同人员需要在硅前的不同阶段实现和测试芯片的模块功能。 如果我们从另外一个角度看，芯片的开发即是将抽象级别逐次降低的过程， 从一开始的抽象自然语言描述到硬件的 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 模型可以帮助在系统级别 完成模型搭建和虚拟系统集成，甚至帮助测算系统的性能，这对于系统框架师而 言会有更多的信心来给出合理的结构配置。 正由于可以在早期做出性能评估 （而且快速、发生在芯片结构的定义阶段）， 框架师可以及时地做出资源调整来满足用户的需求。否则，尽管芯片可能是低缺 陷率的，但如果它的执行速度不够快、功耗又过高，那么也仍然无法满足客户的 要求。 过度设计的结构就跟给一只袜子缀上水钻一样不差但也没有必要。客户给的 报价摆在那里，你的设计越过度，不但意味着成本的增长，也意外着更高的复杂 度和风险。