应对百万门级系统级芯片验证挑战的可扩展解决方案

功能验证是电子设计人员目前面临的主要挑战，无论是设计团队还是验证团队，都将超过50%的时间用在纠错上，因此这一领域的技术进展将对缩短产品上市时间产生重大影响。本文探讨基于断言的技术和改进的纠错方法，以及为什么它们能够以及如何应对设计团队面临的重大挑战，其目的是提高设计生产力、改进设计质量、加快产品上市时间以及增加投资回报(ROI)。

目前的设计和验证方法面临的问题是验证工作必须屈从于设计。出于几项相关原因，现状必须加以改变，特别是我们正在面对一个巨 大和复杂的电子系统。功能性错误是造成设计重复修改的首要原因。用于查找这些错误的功能验证流程是设计流中目前面临的最大瓶颈。一般而言，验证工作在所有 设计活动中一般至少占有50%的份额。然而，验证技术的发展步伐已经远远落后于设计和制造能力，验证鸿沟在进一步扩大(图1)。这一验证鸿沟是限制设计人 员充分发挥其生产力和设计能力的因素。为了弥合这一验证鸿沟，验证必须成为整体设计方法的一个内在组成部分。

整个设计和验证流必须实现结构化，其基础不仅是如何有利于设计工程师，而且还要考虑如何有利于验证工程师，这对设计分工、模块大小、设计规则以及其它许多我们目前想当然的事情都提出了新的要求。

在成功开展系统验证方面面临的另一挑战仍然是测试基准。随着设计规模的扩大，验证复杂性正以指数级速度提高。尽管仿真能力总 是伴随设计规模不断提高的，但测试基准的复杂性则不然。其中部分原因是设计规模对设计的可观察性和可控制性所产生的戏剧性效果，它增加了需要运行测试的次 数，而且这些测试的持续时间可能延长，如果哪个地方出了差错，那么查找和发现原因的难度就会大大增加。

为了解决验证鸿沟和测试基准问题，我们需要采用可扩展验证解决方案，一方面它基于断言的技术，另一方面，它覆盖了验证中的 多种抽象层次以及整个流程各个阶段的验证工具，功能验证策略必须在每个设计层次以及开发流程的每个阶段将验证目标对准整个系统――其中包括数字逻辑、嵌入 式软件以及混合信号内容。

功能验证危机

功能验证的重要性日益提高，其根本原因就是设计规模和复杂性的不断增长，其中包括设计中的软件和模拟电路比例日益提高。规模 的扩大指的是数量巨大的晶体管以及系统级芯片上的门数。《国际半导体技术线路图》预测，系统级芯片到2006年将包含10亿个晶体管。一片系统级芯片可能 包含数千万门，那么出错的可能性以及验证任务的复杂程度相应也会增加。

复杂性提高意味着更多性能多样性，在单个芯片上实现更多的性能。元器件的多样性包括高性能RISC CPU、数千兆位高速I/O、块RAM、系统时钟管理、模拟混合信号、嵌入式软件、专用数字信号处理器(DSP)等。因此，这些元器件之间的接口对确保整 体功能和性能的重要性就变得日趋重要。

片上软件和模拟器件的不断增加不仅使系统复杂性日益加剧，而且也向传统操作方式发出了挑战。数字工程师必须遭遇并不熟悉的 模拟事项。许多硬件设计都需要通过固件和低层次软件来验证RTL功能性。这要求固件设计人员在硬件设计中发挥重要作用，并对硬件和软件之间的相互影响作出详细解释。

我们对Collett国际研究公司2001-2003年间的研究数据进行了考察，结果显示：2001年在所有故障和失败 中，47%的故障与逻辑或功能错误相关。然而，在前10位故障原因中，只有一项属于接口问题：混合信号接口，在整个芯片故障中只占4%。反观2003年数 据，逻辑和功能故障的比例已经攀升到67%，并且出现了另外三种故障范畴。模拟故障在芯片故障中占35%的份额，排名第二。混合信号接口故障所占比例则从 4%升至21%，硬件/软件接口故障比例则占13%。

除了复杂性问题，我们必须解决原有系统和知识产权的重用问题，因为超过50%的设计和测试平台都在重复使用，因此，任何有 意义的解决方案都必须支持所有主要语言――包括Verilog、VHDL、C++以及SystemC――这样它才能在所有抽象层次上工作。开放标准确保旧 有设计和测试平台得到重复使用，可以根据其绝对属性选择验证工具，而并不是因为它们适合某家供应商的工具环境。此外，由于可观察和可控制难度伴随设计复杂 性提高，纠错方法必须能够克服测试基准的复杂性。例如，设计规模扩大一倍，可观察性将减半，可控制性也将减半，那么验证难度大约提高4倍。

如上所述，为了应对日益庞大的设计规模、复杂性和性能问题，验证方法必须在不同工具和设计层级之间实现可扩展。它必须在不同验证域之间实现扩展，能够在模拟、协同验证、仿真以及模数仿真之间实现通信。它不必局限于动态空间，但必须在静态空间中实现自动移动。

例如，如果大型设计需要在门层次上开展大量修改工作，那么等效性检查就是一项必须的要求。最后，只有采用更好的测试基准方法，才能够创建更为有效的、更为充分的测试。

各工具之间的可扩展性

必备的解决方案应包含一套工具，它们能够协同工作形成一个从HDL模拟到电路内仿真的完整路径。这意味着我们需要更好的模拟 器和仿真器，才能在所有集成层次上加速验证流程。工具之间的可扩展性也是必需的，因为不同验证类型在不同的性能范围提供不同的解决方案(图2)。每套解决 方案都会在许多不同属性之间交替使用，比如反复时间、性能、能力、纠错可见性以及成本。

甚至连HDL执行引擎也需要一整套解决方案。有些在块层次上表现良好，有些则在芯片或系统层次上表现更好。例如，设计人员需 要使用高水平验证工具对系统级DSP算法开展验证，HDL软件仿真器显然无法完成这项工作。反过来说，在线仿真在芯片设计中并非是验证相对较小子模块的合 适解决方案，而HDL软件仿真器则可能迅速轻松地完成同一任务。认识到哪些工具是处理手边验证任务的最优选择，继而获得这些工具，将有助于设计人员实现最 佳生产力。以下举例介绍在设计的数字验证过程中可以使用的各种技术。软件和模拟混合信号验证也存在类似连续体。[!--empirenews.page--]

软件模拟是模块级验证的理想选择，因为其周转速度非常迅速，纠错能力较强。硬件/软件协同验证能够将嵌入式软件带入验证流程之中，为加速处理器、记忆体以及总线运算提供途径。它也可以作为测试平台开展硬件验证。

基于处理程序的协同建模提供了大量多样化解决方案，使系统验证成为可能。协同建模适用于在高级、抽象测试平台与载入仿真器的 整个芯片的RTL实施之间建立链接。在线仿真在真实系统中提供高能力和高性能验证。仿真为设计人员带来自信，确保他们的芯片将在实际系统中正确发挥功能。

形式验证(等效性检查)的能力和速度能够确保在设计流后续阶段作出的修改不会改变其意图行为。有必要指出的是，高性能、硬件协助或软件导向解决方案对在系统级环境中实现验证完整性具有关键性作用。

各抽象层次之间的可扩展性

我们非常有必要推动某些方面的功能验证工作向前发展，使其成为设计流程初步阶段的一部分。为了实现这一点，我们必须利用更高层次模型和处理程序(图3)使验证工作变得更为抽象。

在设计流中前移验证的好处在于：处于这个阶段的模型的编写速度较快，具有较大生产能力，因此可以通过建设性方式影响设计决策。抽象工作可以加速验证进行，它能够剔除无关信息，缩短开发时间，加快纠错进程，并使得测试平台更易重复使用。

就复杂的系统级芯片而言，如果所有事情都在RTL或门层次上完成则太过费时和困难，我们在这儿绝对有必要在设计中使用更为抽象的表示方法。这并不仅仅是针对设计的，也同样有益于测试平台。

这种多层次抽象战略要想行之有效，不仅需要必要的工具支持，知识产权(IP)因素也同等重要。如果设计人员无法通过模型在各 个抽象层次之间切换并建立联系的话，那么多抽象模拟就无用武之地。多抽象解决方案将技术与知识产权组合在一起。针对设计的主要接口使用一系列处理程序时， 分层次验证才变得可能。它允许在各种抽象层次上混合各种设计说明。处理程序可以组合为一个测试平台或环境，用于检查某项实施是否符合高层次模型。

本策略的优势是它无需在一个抽象层次上包含所有模型。这种灵活性允许设计团队混合并匹配在规定时间内所能获得的一切，提供相对于执行时间的必要层次解析。

基于处理程序的接口可以将所有抽象系统模型链接至设计，提供一个理想的系统层次测试平台。例如，运用基于处理程序的模拟，某 团队可以在高抽象层次上作出系统定义。然后，它们将在高层次系统定义中提取某个层次或某个模块，运用处理程序投入工作所必需的知识产权，替代它们进入更为 详细的实施模型中。

他们可以在系统原位置处将模型作为即时测试平台运行。该团队就可以立即将现有测试平台投入实际使用，从而向该模块提供自然的刺激。其结果是，验证生产力提高，设计信心提高。

抽象层次

系统级验证所必需的可扩展解决方案应在整个电子系统中支持抽象：模块、子系统、完整芯片以及系统层次。

模块层次：在模块层次上，设计人员的关注重点是功能和时序的细节情况，这样他们就能够保证这些模块符合技术规范，不存在明显 问题。其目标是尽可能多地查找错误，因为这在设计流程中是查找这些错误的最廉价和最快速阶段。模拟和数字交互作用在模块层次上进行验证。功能和代码得到全 面演练，验证移交应考虑在这一阶段进行。由于HDL仿真技术易于使用且具纠错能力，因而成为理想的工具。

模拟/混合信号模 块：系统级芯片设计的能力在不断提升，模拟和混合信号元器件不断加入其中，因此要求模拟环境能够具备与数字逻辑相同的、必需的验证功能。与模拟HDL行为 模拟以及模拟原始模块的Spice模拟顺利实现接口，允许数字和模拟元器件的模拟工作实现同步，并能够在相同的纠错环境中查看。

子系统层次：所有模块均已验证后，随后进行模块集成，涉及对各模块组或整个芯片进行集成。在子系统阶段，模块间通信、控 制、时序和协议对功能而言具有重要意义；因此，检查协议或应用断言以验证总线处理程序的工具就能发挥作用。硬件断言或仿真可以运用HDL、C或 SystemC 以及Verisity等其它高层次测试平台语言布署在这一阶段。

系统级芯片层次：系统级芯片层次验证涉及各模块与后端流程的其余部分进一步集成，其中包括设计的物理实现。在设计人员将较小模块集成进入越来越大模块的过程中，需要模拟的内容日益增多，测试时间日益延长，并且需要开展更多模拟来验证设计。

这对多种验证方法提出了要求，比如芯片和系统功能测试。它还要求验证布图、时钟树或DFT插入会否引入意外更改。等效性检查工具可以验证整个大规模设计，并在每次修改设计后迅速纠错，无需再运行众多漫长的模拟。

除了等效性检查之外，我们还可能在这一流程中使用硬件加速仿真器和多CPU并行仿真，以确保更改设计期间没有造成任何破坏。 多CPU并行仿真将会缩短测试时间，获得非常高的吞吐能力。就较长时间测试而言，出于验证大规模芯片设计的能力考虑，硬件仿真是我们的首选方法。硬件加速 仿真器和多CPU并行仿真是互为补充的解决方案，可以在不同的环境中得到有效使用。

绝大多数系统级芯片器件都包含必须验证的嵌入式软件，其中包括应用代码、实时操作系统(RTOS)、器件驱动程序、硬件诊断以及启动ROM代码。功能仍然重要，但吞吐能力以及其它系统级事宜可能也需要获得验证。运行大量软件通常意味着长时间模拟作业。

硬件/软件协同仿真解决方案提供降低总体负担的途径，同时也提供高效能纠错和分析环境。即便就较长运行时间而言，该设计可能也需要部分或全部移入硬件解决方案之中，但应该保留相同或相当的纠错环境，这样就可以最大限度减少上述执行环境中的迁移。

改进的纠错解决方案

为支持可扩展验证解决方案，纠错工具必须实现集成，在各个抽象层次上保持前后一致，在各个可扩展性工具之间保持一致。其目标 是加快速度发现错误、跟踪捕获故障原因、修复故障，并最大限度缩短反馈时间，将反复回路减少到最低限度。目前，无论是设计团队还是验证团队，都将超过 50%的时间用在纠错上，因此这一领域的改进可能对缩短产品上市时间产生重大影响。[!--empirenews.page--]

在系统层次上，由于抽象层次混杂，系统内部存在的不同语义，因此纠错工作变得更加复杂。在异类环境，比如硬件和软件或数字 和模拟环境中，挑战就会更为严峻。因此，信息不仅必须可用，而且必须在正确的语义背景下可用。同样，利用多层次抽象，信息也必须在必需的抽象层次上可用。

例如，对软件纠错时，有关软件程序执行的所有信息都包含在硬件记忆体中，但没有任何东西是随时可用的。了解变量放置在何处 正是解决方案的发端。它还必须确定信息保存在哪个芯片之中以及芯片中的相对位置，假定它并非缓存或寄存器。在许多情况下，即使在这种时候，数据还可能因为 数据或地址交叉原因而未按逻辑排序。因此，获得变量值就可能非常复杂。

为了化解这些挑战，新的纠错方法正在不断推广。例如断言或检查器，尽管其用途并未得到完全理解。另一个容易引起混淆的问题 则涉及覆盖率问题。许多工程师并未认识到，满足代码覆盖率标准并不意味着系统已经得到适当验证。同样，我们还必须使用功能覆盖率或断言覆盖率等其它标准来 确认该设计已经得到完全验证。

今天，绝大多数工程师都在创建激励源，并将其馈送进入执行引擎之中，这样他们就可以对产生的响应进行分析(图4)。在许多 情况下，他们对照参照模型对该设计的某项实施的波形进行比较，寻找不同之处。这是一种单调乏味且毫无把握的纠错途径，也正是众多错误不被发现的原因所在。 我们很容易将注意力集中在手边的问题，同时错过这样一个事实，即有些地方已经出错，或目前的测试平台无法反映新的问题。

设计人员必须摆脱当前的绝大多数纠错方法，因为就本质而言它们都是单调的、重复的且不可能行得通。在设计流程的稍后阶段，等效性检查可能是一项非常强大的工具。等效性检查可用于对照参考模型测试实施情况，但它采用形式验证的方法，而不是试图通过模拟比较两套波形。

最近，其它一些测试平台组件已经臻于成熟达到可用程度，比如生成器、预测器和检查器等。它们允许自动生成测试预案，并对照期 望行为检查响应成果。其中最成熟的当属检查器，也即断言。现有两种类型断言，即依赖测试内容的断言和不依赖测试内容的断言。依赖测试内容可以轻松插入现有 验证方法中，无需其它工具支持；不依赖测试内容的断言则与生成器联系，需要其它工具并改进验证方法。

故事并不止于此，因为目前还有一些尚未精确定义的测试平台组件，比如功能覆盖率、测试计划以及验证管理等。尽管这种测试平 台转换尚需几年时间才能完成，但一旦完成，人们梦寐以求的可执行计划规范就将实现，不过其方式已经迥异于业界最初的预测。它不会用于自动执行设计流程，但 将应用于自动执行验证流程。

基于断言的验证

如前所述，测试平台受到两大独立因素的制约：可控制性和可观察性。可控制性可等同于激励源插入后测试平台激活设计中存在问题的能力。它与代码覆盖率存在非常密切的关系，也正是我们在运用代码覆盖率时必须小心谨慎的原因所在，因为它并未考虑测试平台的其它方面因素。

问题的另一半则是可观察性。故障一旦出现，两件事情必须发生。首先是这一故障所产生的效应必须传播至主要输出，随后故障必须 被发现。对大多数测试平台来说，接受验证的主要输出的数量非常少，因此我们会对许多问题视而不见。这正是断言之所以强大的原因所在。断言对可观察性造成积 极影响，提供多项好处。它们能够明确除错的主要原因――而非次要或第三位原因――纠错工作变得更为轻松和快速。这是因为它们能够分散在整个设计之中，产生 实际的主要输出，后者则自动检查验证对象的行为好坏。

这样，测试平台就不必再将这些错误效应传播至实际的主要输出，使得测试平台的开发变得更加容易。另外，我们还可以对大量数 据进行验证，否则的话它们将被忽略。断言还开展数据检查，使得测试平台更加有效。某项断言一旦设计完成并被置入设计中，那么它就总是处在运行状态。在许多 情况下，断言检查的东西并非测试的主要内容，因此它们将会发现非预期故障。例如，在模块测试阶段插入的断言在集成阶段乃至系统层次测试中都会执行其检查功 能，这样就可以提供更为广阔的验证覆盖面。

最后，断言使得测试的范围更为宽广。运用基于断言的验证技术的工程师经常发现，其检错速度远远超过非断言技术。这样就可以 抵消编写和放置断言造成的总体开销――约占3%总开销时间以及10%总运行开销时间。运用断言的公司报告称，在其所有程序错误中，大部分是通过断言来发现 的，其纠错时间也缩短了80%之多。

断言可以嵌入设计之中，或者其规定内容可以独立于设计，并附加在设计中的各个点。是内部还是外部则部分取决于谁在创建这一 断言，比方说创建人员是设计人员还是独立的验证工程师。如果它们被嵌入设计之中，则主要验证技术规范的实施。如果属于外部开发，则将验证技术规范的解释， 或在某些情况下对技术规范本身进行验证。因为嵌入式断言实际上都是可执行的注释，因此它们可能放置在任何可以放置注释的地方。

好处是注解现在变得更有价值，因为它们在发挥作用。注解包括期望行为的说明、设计人员作出的假设或针对期望用途作出的限制。它支持再利用，它提供有关设计的预期行为的所有各类信息，提供原设计人员的意图。至少所有的第三方知识产权IP就应该内建接口上和用途方面的断言。

目前，人们对断言的主要兴趣是如何进行模拟断言，但这并非断言的所有功能。断言的基础是一些名为属性的更为基础的东西。属性 可以用于断言、功能覆盖标准、形式检查器以及用于伪随机刺激生成的约束生成器。属性既可为模拟器也可为形式分析工具所用，它能够将静态和动态验证技术融入 一种方法中。随着这一领域中标准的来临，在今后数年中，运用属性的工具预计将会迅速增长。

本文小结

设计团队需要运用那些能够在设计复杂性和多层次抽象之间扩展的工具改进现有方法。可扩展解决方案能够帮助工程师开展他们目前能够开展的工作，而且在相同时间范围内只会变得更好、更快且效率更高。它使得验证工具对用户更为友好，并能够在设计过程中推入更多测试向量。[!--empirenews.page--]

任何有效的系统验证策略都必须提出这样的前提条件，即系统实际上指的是整套系统，它包含的远非数字逻辑那么局限。换而言之， 一套有意义的解决方案必须能够解决数模信号混合问题，必须能够提供为软件、RTOS的验证运行所必须依赖的环境，并将其联系在一套统一的解决方案之中。

新的测试平台组件正在进入今天的验证方法之中，断言的使用可能对质量和速度产生戏剧性的影响，因为验证工作可以利用断言来 开展。此外，某些更新的测试平台组件正在出现。所有这些新的组件都将受到属性的驱动，既而操控和利用属性。这是未来的发展方向，现在开始已经变得异常光 明。这种自动化、基于属性的验证方法将推动验证性能的提高，这也是缩短验证鸿沟的必要条件。这事实上相当于10年之前设计路径曾经享受过的综合的好处。验 证综合还在发展之中，并将从根本上改变探讨和处理验证问题的方式。