可扩展验证克服现有验证方法的局限性

-.z可扩展验证克制现有验证方法的局限性随着芯片设计规模和设计复杂度日益增加(包括软件设计和模拟设计在总设计工作中所占的比重日益增加)，功能验证的重要性也日益凸显。所谓设计规模增加，是指一块SoC上所包含的晶体管数量变得惊人的多，这就导致其中包含的门也越来越多。如今，仅一块SoC上就已经可以包含上千万个门，这无形中增大了电路出错的几率，也使验证工作变得更加复杂。而所谓设计复杂度增加，则指一块单独的芯片上包含的组件种类增多，不同种类组件的数量也变多。这里所说的组件包括高性能CPU、多个千兆I/O、嵌入式RAM、系统时钟管理组件、模拟混合信号、嵌入式软件和专用数字信号处理器(DSP)。随着这些组件的种类和数量增加，对芯片的整体功能和性能而言，各组件之间的接口就变得越发重要。此外，片上软件和模拟器件也越来越频繁地出现在芯片中，这又进一步提升了系统的复杂度，同时对传统的验证方法提出了挑战。首先，数字设计工程师们必须面对一些他们并不熟悉的模拟设计方面的问题。其次，许多硬件设计都要求固件或低级软件就绪而且可以工作后才能验证RTL的功能。这就要求固件设计师必须在硬件设计中扮演重要角色，仔细协调软、硬件之间的相互关系。这就是说，我们必须改变设计方法。用一句老话说，要么做得更好，要么就换种方法来做。想做得更好就必须研究现有方法所采用的工具及其效率，而换种方法来做则必须改变方法以获得更高的效率。这两种方式之间不存在谁对谁错，但更有效的方式则是随着时间推移，将二者中的一些元素结合起来，并在恰当的时刻应用到我们的验证方法中去。要改良现有方法，首先必须研究各种工具本身，以及它们之间的相互关系。为此，我们需要能够涵盖以下验证域的工具：软仿真、硬仿真、硬件、软件，以及模拟和数字域。此外，这些工具还必须支持所有标准和新兴的设计语言，包括VHDL、Verilog、PSL、C、SystemC，以及最新的SystemVerilog。在*种程度上说，这就是我们所说的可扩展验证(ScalableVerification)。改变现有方法意味着研究设计过程本身，并在设计的更早期开场进展验证，包括创立系统级测试平台、建立事务级模型，以及保证在系统接口创立时(而不是在设计末期)就能对其进展检查。要做到这些，需要有能够涵盖各个抽象级以及系统各个域(例如软件和硬件)的工具。不同验证工具间的可扩展性要做到以上这些，我们的方案中应包含一系列工具，这些工具结合起来能够胜任从HDL仿真到在电路仿真(in-circuitemulation)的一整套完整的任务。也就是说，采用更好的软仿真器和硬仿真器能够加速各种集成度等级的验证过程。之所以要求工具间具备可扩展性，是因为不同类型的验证在不同的性能区间上提供的是不同的方案。每一套方案都必须在许多不同的特性之间进展权衡，例如迭代时间、性能、容量、调试的可视性和验证本钱。就连HDL执行引擎也需要许多不同的方案。一些方案在模块级表现更好，另一些则在芯片级或系统级表现更好。例如，打算验证系统构造决策的设计师就不应采用HDL软件仿真器，而应采用抽象模型或事务级硬件－软件环境，因为这些方案才能提供他们需要的信息。反过来说，验证芯片设计中相对较小的子模块时，在电路仿真并不适宜，而HDL软件仿真器则能快速简单地完成任务。认清哪些工具最适合手头的验证任务，然后找到这些工具。如果做到这点，设计师就能得到最高的效率。以下是一些可供可扩展验证方法采用的技术：软件仿真：适合模块级验证，因为其运行速度很快而且调试功能强大软硬件协同仿真：允许将嵌入式软件引入验证过程，并提供了一种可用于加速处理器、存储器和总线操作的手段，还可用作验证硬件的测试平台测试平台加速：通过逐级提升验证的性能等级突破了协同仿真的性能局限。基于事务的方法使重用率更高，而对更高重用率和高级验证语言的支持则催生了生产率更高的测试平台方法。硬件仿真(在电路测试)：允许在真实系统中进展高容量和高性能的验证，让设计师确信其芯片在真实系统中能够正常工作。正式等价性检验(Formalequivalencechecking)：其容量和速度保证了设计流程晚期进展的一些改动不会影响芯片的预期表现。模拟/混合信号仿真：允许对芯片的多个域进展验证，保证验证具备最正确的准确度和性能。还有很重要的一点需要注意，那就是高性能的硬件辅助或者面向硬件的方案对于在系统级环境下实现验证的完整性至关重要。验证工具内的可扩展性一个优秀的验证方案，除了能够在不同的工具间转移之外，还应确保发挥工具本身最大的效率。因为只有这样，验证过程才能在单一环境下持续，直到确实需要改用其他方案为止。这种工具内的可扩展性可通过多种方式得到表达。例如，在进展回归测试(regressiontesting)时，很可能会有大量测试需要频繁运行，而且大多数公司都希望在一个晚上的时间内完成测试，以便在第二天早上开场其他工作之前发现并解决问题。但单独一个软件仿真器的性能不可能到达在合理时间内完成如此大量工作的程度。反之，一个很容易建立的仿真集群则可以将这些大量的工作排序，并在任何可用的机器上运行，从而使回归测试变得更加切实可行也更简单。如果回归测试集中还包含运行时间很长的测试，则就需要用到硬件仿真器。一个单独的硬件仿真器本身在仿真规模上就已经非常灵活，因为只要设计中门的数量不超过该系列硬件仿真器的最大容量限制，仿真器的容量可以轻松扩展以适应不同的设计规模。而且在必要时，还可以通过将多个硬件仿真器连接起来到达扩展容量的目的。另一个例子是正式等价性检验。等价性检验工具可以缩短一次回归测试运行的时间或降低其运行的频率，但这种工具也有其自身的限制。此类工具的构造必须实现极高的存储器效率才能实现全芯片验证和回归。在设计规模到达上百万门时，设计师不可能依靠工作站上的物理存储器来解决这一问题。同时，等价性检验也需要根据设计的复杂度调整规模。如果需要更大的处理能力，可以让多台机器同时工作，以缩短回归测试的运行时间。工具内可扩展性的另一方面对硬件仿真而言尤其重要，那就是尽管在不同的设计规模下硬件仿真器的性能根本一致，但当需要与逻辑仿真器连接时(例如在行为测试平台中)，硬件仿真器的速度性能会急剧降低到与一般的软件仿真器速度相当的程度。要解决这一问题，必须构建一系列方案，允许将更多的设计与/或测试平台映射到硬件仿真器。这些方案中还必须包含高速的事务级接口，以保证与那些必须留在工作站上的局部有效连接。这一过程中需要用到非常先进的综合技术，在设计流程的正常情况下并不要求采用这些技术，但它们却能改善硬件仿真器的性能。不同抽象等级之间的可扩展性今后，我们将不得不在设计过程的初期就开场*些方面的功能验证，而要做到这一点，就必须利用更高级的模型和事务处理器使验证更加抽象化。将验证提前到设计早期进展可带来以下好处：首先，在设计早期，模型更容易编写，允许的数据流量也更大，因此可能对设计决策有决定性的影响。另外，在这种更高的抽象级别上工作有助于提高测试平台的可重用性。对于复杂SoC而言，在RTL或门级进展所有验证耗时太长，也太困难。我们必须用更抽象的表达来描述设计，不仅对设计是如此，对测试平台亦如此。利用C,、C++和SystemC等编程语言创立此类高级原型，就可以立即验证每一个正在进展的架构或划分决策。即便是传统的硬件描述语言(HDL)，例如Verilog、VHDL或SystemVerilog，都可以在比RTL更高的级别上得到较高的效率。这些抽象模型可以通过创立系统级测试来验证。在将系统分为硬件模块和软件模块，或者提炼出设计层次之后，我们可以借助验证工具在这些模块或层次间建立接口，不必等所有模块都到达同样的抽象级别之后才开场验证，从而使每个模块能随时间的推进而有所进展。而多级抽象策略要想行得通，就必须将工艺和IP结合起来。为此，我们需要一些能够让设计师们在不同的抽象等级之间切换并将它们联系起来的模型。利用一系列事务处理器为一个设计构造理论接口，我们就可以进展分级验证(Hierarchicalverification)，因为此时我们可以将不同抽象等级上的设计描述混合起来。这些事务处理器可以组合成一个测试平台或环境，用于检查一个设计的实现是否与更高级的模型相符。这种验证策略还有一个优点，即不要求所有模型处于同一个抽象级别。因而设计团队可以将在*个特定时刻可用的任何模型组合起来，得到在一定的运行时间所必需的分辨率水平。基于事务的接口可以将抽象系统模型与设计连接起来，提供一个理想的系统级测试平台。例如，采用基于事务的仿真，设计团队就能在很高的抽象级上定义一个系统。然后我们可以将这个高级系统定义内的单个抽象级，或单个模块拿出来，采用将该事务具体化所需的IP代替它，从而得到一个更加具体的实现模型。将这个模型放回系统中原来的位置，就立即得到一个测试平台。设计团队可以立即使用这个测试平台，得到一个提供应模块的自然鼓励。这样一来，不但验证的生产率得到了提高，设计人员对设计的信心也会更饱满。改善的调试方案要支持可扩展验证方案，调试工具必须完整，即必须支持各个抽象级和各种扩展工具。其目的是加快验证过程查找问题的速度，查出问题的起因，并解决问题，将反应时间减至最短，并将验证的重复次数减少至最少。目前，设计和验证团队超过一半的时间都用于调试，因此该领域的性能改善必将极大缩短产品的上市时间。一个系统内，多抽象级和多种不同符号含义的共存会使系统级调试变得更加复杂。而调试环境的不同，例如硬件和软件环境或者数字与模拟环境的不同，则使这一问题变得更难解决。因此，设计信息不但必须对设计和验证人员开放，而且必须出现在语义正确的上下文之中。而且，由于一个系统中存在多个抽象级，所以此类信息还必须在设计人员需要的抽象级上出现。例如，在调试软件时，有关软件程序运行的所有信息都包含在硬件存储器中，而在调试过程中这些信息都是设计人员看不到的。因此，弄清一个变量的存放位置只是我们要做的第一步。同时，如果信息并未存储在缓存或存放器中，那我们还必须明确信息到底存储在哪一块存储芯片中，以及它在该芯片中的相对地址。即便这点已经明确，很多时候由于数据或地址的穿插，数据在芯片中的存储也并没有一定的逻辑顺序。为了解决这些问题，新的调试方法正在得到普及，例如断言(assertion)和检查库(checker)，但这些新方法的作用还没有得到充分发挥。业界关心的另一个问题是验证的覆盖率。许多工程师都没有意识到，满足了代码覆盖率标准的要求并不意味着系统已经得到了充分验证。要保证系统得到充分验证，还要使用功能覆盖率和断言覆盖率等其他标准来检验。自己创立一个鼓励，将其馈入执行引擎，然后分析得到的响应(见图5)，这是今天的许多工程师都会的。一般情况下，他们会将设计的*一次实现得到的波形与一个参考模型进展比拟，从中寻找差异。这是一种缓慢又有些依靠运气的调试方法，因此会有许多错误遗漏。因为这样一来，我们很容易死盯住已经发现的问题，忽略了其他有问题的地方，或者意识不到我们当前采用的测试平台根本没能暴露出新的问题。

图5所以，设计工程师必须要走出大多数现有调试方法重复、冗长和盲目的死胡同。在设计流程的晚期，等价性检验将是一种非常强大的工具。等价性检验主要用于测试一次设计实现与一个参考模型之间的差异，但它并非仅仅比拟两组仿真波形，而是通过一种更加正式的方法进展比拟。最近，另有一些测试平台组件已经成熟，可以投入使用，例如测试环境生成器、预测器和检查库(checker)。有了这些测试平台组件，我们就可以自动生成测试环境，并检查相应的结果是否合法行为。这些组件中，检查库是最成熟的一种。当然，检查库也属于断言。断言分为两种，一种叫做测试依赖断言(testdependent)，一种叫做测试独立断言(testindependent)。测试独立断言可以轻易插入一种现有的验证方法中，无需额外工具支持；而测试依赖断言，外加生成器，都需要对测试工具和方法进展额外改变。基于断言的验证如前所述，测试平台受两个相互独立的因素制约：可控性和可视性。可控性指一个测试平台通过输入鼓励激活设计中一个问题的能力，它与代码覆盖率标准之间关系十分严密。正因为如此，设计人员在采用代码覆盖率标准时必须慎重，因为该标准并未考虑验证问题的其他方面。要实现可视性，在问题出现之后，必须保证两点：一是该问题造成的设计人员并不希望的结果一定要传输到设计的主输出，二是期望结果与非期望结果之间的差异必须被检测出来。对大多数测试平台而言，承受验证的主输出数目都很少，因此许多问题出现之后甚至都没有人注意到(见图6)。而且，在验证过程的大局部时候，许多非期望的结果在主输出中都被掩盖了，而保证将这些结果传送到主输出则可能导致测试耗时过长。

图6这正是断言这一工具功能如此强大的原因之一。断言的一些好处有助于实现可视性(见图7)。首先，断言能够确定造成问题的主要原因，而不是次要的原因，因而简化并加速了调试过程。这是因为断言可以分布在整个设计中，生成虚拟主输出，这些主输出又会自动检查好的行为和坏的行为。因此，测试平台无需将这些出错的结果送到真正的主输出，这就简化了测试平台的开发。另外，采用断言之后，大量原本会被忽略的数据都能得到验证。

图7断言还可以进展数据检查，从而提高测试平台的效率。一旦一个断言设计好并插入设计中之后，它就一直保持运行。而且，许多时候，断言还会检查那些并非测试主因的局部，因此会发现一些意料之外的问题。例如，在模块验证阶段插入的断言在整个集成阶段直到系统级验证阶段都一直在履行其检查功能，因此能够提高验证覆盖率。最后，断言还能拓展测试的宽度。工程师往往会发现，与没有采用断言的情况相比，采用了基于断言的验证技术后，早期的缺陷检测率要高得多。这种效果抵消了编写与放置断言所需花费的开销，即3%的时间开销和10%的运行时开销。根据采用了断言技术的公司报告，其设计中的很大一局部缺陷都是断言发现的，而且他们的调试时间也缩短了多达80%。断言既可以嵌入设计中去，也可以独立于设计定义，放在设计中多个不同的点上。至于是内置还是外置则局部取决于是谁在编写这些断言，是设计师还是独立的验证工程师。当断言嵌入到设计内时，它们的作用主要是验证规*的实现。当断言独立于设计开发时，它们主要用于证实一个规*的解释，或者有时用于证实该定义本身。因为嵌入的断言实际上就是可执行的注释，只要能放置注释的地方都可以放置这类断言。此类断言的优点是让注释更有价值，因为它们可以主动完成一些任务。此处所说的注释包括描述预期行为、设计师所作的假设，或对预期用途所做约束的注释。通过提供各种有关设计的预期行为和原设计师目的的信息，此类注释为设计的重用提供了很好的支持。所有第三方IP都至少应包含有关接口和用途的断言。目前，断言面临的主要问题是如何对其进展仿真，但我们能做的还不只这些。断言是建立在更为根底的特性之上，而特性则可用于断言、功能覆盖率指标、正式检查库和伪随机鼓励生成的约束产生器。软仿真器和格式分析工具都可以采用特性，静态和动态验证技术由此可以开场融合到一种方法中。随着该领域标准的开展，采用特性的工具在今后几年内有望取得快速开展。本文小结现有的验证方法需