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

不同抽象等级之间的可扩展性

今后，我们将不得不在设计过程的初期就开始某些方面的功能验证，而要做到这一点，就必须利用更高级的模型和事务处理器使验证更加抽象化。将验证提前到设计早期进行可带来以下好处：

首先，在设计早期，模型更容易编写，允许的数据流量也更大，因此可能对设计决策有决定性的影响。另外，在这种更高的抽象级别上工作有助于提高测试平台的可重用性。对于复杂SoC而言，在RTL或门级进行所有验证耗时太长，也太困难。我们必须用更抽象的表达来描述设计，不仅对设计是如此，对测试平台亦如此。

利用C,、C++和SystemC等编程语言创建此类高级原型，就可以立即验证每一个正在进行的架构或划分决策。即便是传统的硬件描述语言(HDL)，例如Verilog、VHDL或 SystemVerilog，都可以在比RTL更高的级别上得到较高的效率。这些抽象模型可以通过创建系统级测试来验证。在将系统分为硬件模块和软件模块，或者提炼出设计层次之后，我们可以借助验证工具在这些模块或层次间建立接口，不必等所有模块都达到同样的抽象级别之后才开始验证，从而使每个模块能随时间的推进而有所进展。

而多级抽象策略要想行得通，就必须将工艺和IP结合起来。为此，我们需要一些能够让设计师们在不同的抽象等级之间切换并将它们联系起来的模型。

利用一系列事务处理器为一个设计构造理论接口，我们就可以进行分级验证(Hierarchical verification)，因为此时我们可以将不同抽象等级上的设计描述混合起来。这些事务处理器可以组合成一个测试平台或环境，用于检查一个设计的实现是否与更高级的模型相符。

这种验证策略还有一个优点，即不要求所有模型处于同一个抽象级别。因而设计团队可以将在某个特定时刻可用的任何模型组合起来，得到在一定的运行时间所必需的分辨率水平。

基于事务的接口可以将抽象系统模型与设计连接起来，提供一个理想的系统级测试平台。例如，采用基于事务的仿真，设计团队就能在很高的抽象级上定义一个系统。然后我们可以将这个高级系统定义内的单个抽象级，或单个模块拿出来，采用将该事务具体化所需的IP代替它，从而得到一个更加具体的实现模型。将这个模型放回系统中原来的位置，就立即得到一个测试平台。设计团队可以立即使用这个测试平台，得到一个提供给模块的自然激励。这样一来，不但验证的生产率得到了提高，设计人员对设计的信心也会更饱满。

改善的调试方案

要支持可扩展验证方案，调试工具必须完整，即必须支持各个抽象级和各种扩展工具。其目的是加快验证过程查找问题的速度，查出问题的起因，并解决问题，将反馈时间减至最短，并将验证的重复次数减少至最少。目前，设计和验证团队超过一半的时间都用于调试，因此该领域的性能改善必将极大缩短产品的上市时间。

一个系统内，多抽象级和多种不同符号含义的共存会使系统级调试变得更加复杂。而调试环境的不同，例如硬件和软件环境或者数字与模拟环境的不同，则使这一问题变得更难解决。因此，设计信息不但必须对设计和验证人员开放，而且必须出现在语义正确的上下文之中。而且，由于一个系统中存在多个抽象级，所以此类信息还必须在设计人员需要的抽象级上出现。

例如，在调试软件时，有关软件程序运行的所有信息都包含在硬件存储器中，而在调试过程中这些信息都是设计人员看不到的。因此，弄清一个变量的存放位置只是我们要做的第一步。

同时，如果信息并未存储在缓存或寄存器中，那我们还必须明确信息到底存储在哪一块存储芯片中，以及它在该芯片中的相对地址。即便这点已经明确，很多时候由于数据或地址的交叉，数据在芯片中的存储也并没有一定的逻辑顺序。

为了解决这些问题，新的调试方法正在得到普及，例如断言(assertion)和检查库(checker)，但这些新方法的作用还没有得到充分发挥。业界关心的另一个问题是验证的覆盖率。许多工程师都没有意识到，满足了代码覆盖率标准的要求并不意味着系统已经得到了充分验证。要保证系统得到充分验证，还要使用功能覆盖率和断言覆盖率等其他标准来检验。