功能验证逐渐向更高抽象层转移

在设计流程中功能验证经常会引发问题。半数以上的芯片在初次流片时以失败告终，而其中70%的问题归因于功能验证。仿真器供应商的解决方案是告诫用户进行更多的仿真，建立更大规模的仿真库，并使用模拟方法。通过分析以往验证的关键环节，我们得知，这些解决方案并不能真正的解决问题。

图1: 设计与验证各方面

最近，验证产能获得了极大的提高，特别是在测试平台开发方面，能够更快更方便的进行新测试的开发。由于能够积极回应设计更改(没有大的变动)，验证产能提高后还能减少对已有测试的维护时间。

但是，验证产能的提高也加重了超负荷运行的仿真器的负担。现在厂商可以生成数以千计的向量集，但却没有时间或资源来运行这些向量。因此，仿真器供应商们试图确定“最佳”的向量集，而不同向量集的差别在于所提供的覆盖率。

设计在不断发生变化，而如今的验证技术已经过时。随着SystemC等新语言的推出，特别是事务级建模的出现，设计师们可以在更高的抽象层上进行思考和工作。IP使用的增加也使设计师们更加注重系统级效应、模块的交互以及系统架构。验证必须反映这些设计方法的变化，而这就要求下文所述的三大独立技术的融合和成熟。

建立验证统一体

我们应该将验证视为一个与设计流程平行的完整统一体，而不是单独一项功能。在这个统一体中，每项任务执行系统某方面的验证，例如功能、架构、性能、时序和实现。

让我们先看一下图1所示的简化设计流程。在该设计流程的顶部是系统设计和算法开发。大多数公司以书面形式完成这项工作，而小公司可能用UML、Matlab或具备所需抽象级的类似语言进行建模。但此时没有考虑软硬件之间的分割和算法实现问题。

假设这一层上的所有对象都有模型，那么设计师希望能够验证算法是否正确，以及模块间的交互是否能够在主要输出上产生期望的功能。系统仿真器并不是什么新鲜事物，但今天功能验证因为不合适的模型而必须在流程的后期阶段执行。

设计过程的下一阶段是通过确定哪些功能分别由硬件和软件实现，来设定解决方案的基本架构。这其中需要选择将使用的大部分IP，特别是平台和基本的操作系统，从而相当准确的预测系统性能。

行业标准taxonomy2将其定义为抽象行为模型，它描述了一个组件的功能和时序，但没有对其实现作出解释。这种模型的接口实际上是令牌传送，但包含实际数据，并能在上面执行正确的功能。

业界常把这些模型称为“事务处理”，因为它能够核查负载系数、拥塞、资源利用以及其它系统因素。虽然目前已经出现了抽象的硬/软件协同仿真，但由于缺少模型，很少有人能在现阶段进行性能验证，一般都要推迟到流程的后期阶段。

在硬件方面，设计过程考虑了微架构决策，如要使用的并行数量、管线和资源共享等。这些决定影响到面积、功耗、延迟以及解决方案的吞吐量。

一旦在精确的抽象行为模型中加入实现细节，就产生了RTL模型。大多数公司从这里开始验证过程，包括系统级功能验证、性能验证和实现验证。这些模型包含了有关验证类型性能等冗余细节，从而造成浪费。

诸如SystemC这类语言的推出使行为模型的开发成为可能，并为功能验证的性能加入了更高的抽象层。但是，如果业界接受并使用这种抽象进行功能验证，那么还需要进行其它一些改变。

为了避免验证效率的低下，我们必须理解图1的每个阶段。我们无需了解验证架构如何实现，也不用按每个时钟验证行为。RTL实现的验证不需要详细的时序。成功的验证会把这些问题区分开来，并依靠其它工具来确保各阶段所作假设的正确性并进行简化。

抽象层向上提升

新推出的SystemC和SystemVerilog工具定位于两个抽象层。第一个是自顶向下的系统级工具，它们分析算法和架构，然后实施优化。这些工具的使用目标是图1所示的系统设计和分割阶段。

最近推出的许多工具都能够对PrimeXsys4和OMAP5等预置平台进行快速仿真，能够处理用户创建的模块。这些以处理器模型为核心的系统，在典型奔腾平台上的运行速度可以达到数MIPS。

在这些模型的基础上，就可以借助从架构或分割选择中获得的相当准确的信息来执行大量的功能验证。但是，我们无法获悉这些模型是否在RTL级得到了正确实现。而这也正是大多数此类系统基于可用IP模块的原因。

第二种进行抽象方法是将自底向上的过程延续到更为抽象的设计描述层，此时的微架构细节插入了一个综合工具，而不是在描述中定义。这就是图1所示的行为层。微架构细节表明了一种算法是如何被实现的。例如，实现乘法操作有多种方法，从单循环到需要多时钟的反复“移位和加”操作指令。

可以建立允许数据流经多操作符的管线，并且通过资源共享和调度避免冲突。接受RTL设计并产生仿真模型的现有工具并不维护执行细节，但却能将速度提高5倍或7倍以上。由业界人士所做的实验已经表明，全事务级模型的运行速度比等效的RTL模型快100到1000倍。

解决方案的关键

当设计规模达到千万门级时，测试向量运行的次数只占可能设计行为的一小部分。回归组件的范围扩展到了数百至数千个向量集，运行时间为数天至数周，即使在仿真库上。如果上述这些在每次修改后都要运行，那么开发后期阶段的修改代价实在是太过昂贵了。

如果想要解决上述验证危机，那么必须结合使用以下三种关键技术：

1. 忽略实现细节的高层仿真技术，可用于所需功能的高效仿真并进行性能评估。

2.确保一个具体实现在功能上与高层次模型相匹配的技术。

3.定义并检查设计的临时属性是否满足规范的有效技术。

这三种技术目前正在兴起，许多高层仿真技术也已投入实际使用，虽然应用范围还不是很广。Accellera定义了断言，网上也即将提供工具支持。序列等价验证(Sequential equivalence checking)是业界的最新技术，序列差异见图2。

图2的顶部定义了系统行为，但没有时钟驱动。换句话，它不能用上升沿CLK来表示，只有这样图2左边的解决方案才可行。图2右边所示的解决方案同样有效，它具有非常大的灵活性，允许使用更快的全局时钟或更少的硅片面积。

然而，证明这两种方案在功能上等效相当困难。由于不知道控制触发器的起始状态，因此很难知道什么时候操作开始或输出有效。如果想证明这两种解决方案在功能上等效，那么必须解决这些差异。

图2: 序列差异

在简单的例子中定位问题是一件容易的事情，但是如果改用复杂的处理器管线，并使用仿真去发现所有可能的行为，那么不仅耗时，而且极可能出错。为了进行完整的验证，可以使用2-power(输入位数量+状态位数量)向量。虽然不需要所有的向量，但确保高概率功能等效的向量数量非常大，这也解释了为什么大多数工程师一旦发现系统工作后就不愿意对微架构作大幅度修改。

组合等价性验证的关键是发现每个设计中相应的状态存储器，虽然不同设计可能采用不同的状态编码或者状态存储器很难被发现。而在序列等价性验证中，设计可以根据相互的关系重新定时，这也意味着有些状态可能只出现在建模的时刻。

图2右边所示的设计在寄存器中存储中间值。其它设计不会这样做，最多可能会在第一个加法器的输出端产生临时的信号值。

序列等价性验证器需要识别两个设计中的对应值，然后确定该功能会在已定义的时间点之间出现。这叫做“同步点”。只有两个设计具有相似性，才可能简化比较点的识别。

预测未来

未来方案成功的关键是使用正确的数据点和长期有效趋势。当在门级设计中实现过程进行更改时，在验证之前会进行测试以避免对系统其余部分的影响。

答案并不是运行完整的测试套件。组合等价性验证可以解决这个问题，并使验证向更高的抽象层转移。当功能验证集中于RTL级时，就可以创建时间更长、更具鲁棒性的测试。

同样，序列等价性验证可以排除大多数RTL级功能验证的必要性。随着PSL和SystemVerilog的标准化和广泛化，临时断言正变得越来越先进，这意味着确保实现模型时序符合规范的解决方案正在出现。高层仿真器(比运行在RTL级的现有模拟器速度更快)已证明它们能够提供大量的功能验证。

这三种向更高抽象层转变所必需的技术目前已经各就其位并逐渐走向成熟。在不久的将来，我们有望看到验证方法的长足进步，不仅能够支持更大规模和更复杂的设计，还能够积极影响设计流程的改善。

许多设计师很难建立和使用行为模型，因为他们无法针对RTL设计展开等价性验证。不管是否采用行为综合工具，序列等价性验证都将提高设计师的信心。值得庆幸的是，这些性能和品质上的改善有望继续下去，直到下一个障碍出现在流程中，其中包括管理设计中必要的一些并行层面。

作者: Brian Bailey

功能验证咨询师