验证复杂的SoC设计要耗费极大的成本和时间。据证实，验证一个设计所需的时间会随着设计大小的增加而成倍增加。在过去的几年中，出现了很多的技术和工具，使验证工程师可以用它们来处理这类问题。但是，这些技术中很多基于动态仿真，并依靠电路操作来发现设计问题，因此设计者仍面临为设计创建激励的问题。
设计者可以使用运行在处理器上的固件作为验证仿真激励的一部分，这也是目前通常采用的方法——使用全功能处理器模型。与在HDL中编写激励相比，固件作为激励速度更快，并且更容易创建。在一个全功能处理器模型上执行代码的缺点是模型运行较慢，因此只有少量软件会使用这个技术执行。很多固件执行由取指令操作和内存读写周期组成，验证价值很低。在逻辑仿真器中屏蔽这些低价值操作，而继续执行寄存器和内存映射I/O周期，可以在最低限度减少验证覆盖率的同时，显著提高执行速度。
在仿真环境中能够更快速地执行代码主要有两个好处。首先，快速仿真意味着功能验证仿真可以使用更多的代码。诊断程序、驱动程序、固件以及某些情况下部分应用程序代码都可用于验证问题。其次，因为仿真运行速度加快，因此能够执行更多的验证。很多设计者会选择运行附加测试，而不是运行较少的CPU仿真时间。大多数验证都受到能够用于运行仿真的CPU时间的限制。如果固件用来作为验证的一部分，它将对设计起推动作用。这个激励将是切合实际的，它通过典型的操作使设计得到测试。为设计创建激励的挑战之一是如何估算出典型的设计操作，并将其在测试平台上编码。使用实际的软件可为验证工程师排除这个问题。但是，运行作为测试平台的代码不可能提供大量激励，特别是不能覆盖大部分验证空间。因此，设计者需要使用其它的技术提供额外激励，以遍历设计的所有边界情况。
设计者使用传统的直接测试和其它验证技术能够增加用固件作激励源的情况。内存分区可用于过滤仿真过程中不必要的总线周期，从而提高性能。本文将介绍一个设计实例，使用作为激励的代码和基于断言的验证，通过该实例来描述使用传统验证技术无法发现的设计错误。
解决验证挑战
目前，电子工程师面临的验证挑战不断加剧。为了更好地阐明这些挑战，本文中介绍了一个简单的实例。该实例是一个在250×250像素矩阵上显示RGB数值的图形输出设备。它包括一个映射到处理器的寄存器接口。相关寄存器有：“行”—包含待描绘像素行地址信息的一个8位寄存器：“列”—包含待描绘像素列地址信息的一个8位寄存器：“像素”：——包含待描绘像素RGB值的一个8位寄存器：“大小”——包含待描绘像素矩形大小的一个8位寄存器(其中1表示写入单个像素，2表示描绘一个2×2的正方形，以此类推最大值为16)：“状态”——能够读取和返回设备状态信息的一个8位寄存器。
使用直接测试
验证此样本设备的第一步是测试所有行和列是否正确定址。要测试所有大小的像素是否能够被写入，还要测试不同颜色值的代表样点。典型的像素组合也要被测试，如从右上方像素立刻变换为左下方像素。使用类似的方法可测试所有角对组合。还应该测试各种组合中有序和无序增减的行地址和列地址。所有这些测试可以通过编写和编译一个运行在全功能处理器模型上的简单程序来完成，或者使用一个产生总线周期和BFM的简单测试平台。另外还要考虑测试那些可能影响设计的异常条件。测试时可将行地址或列地址设置为一个大于249的值，或是定义一个大小超过硬件支持的像素。
这些都是在接口级完成的明显测试，在内部结构进行的类似验证测试和在接口级实现的验证策略是很类似的。显然，要测试整个验证空间，即使只是一个设计模块的接口，也不可能像前述的样本设备一样简单。可能的操作是250行×250列×224色×16大小，或16.7×1016.所有操作的组合数是这个数值的平方，或大于1034.这里真正的挑战是创建那些能够揭露设计问题的组合，并将这些问题标识为需要立刻关注的区方面。
使用断言揭露早期问题
由于对设计驱动了激励，因此断言可以及早发现问题。要添加的断言包括不能超过249(行地址和列地址的最大可能值)的行地址和列地址，以及不能超过16的大小字段。确定断言并采用HDL覆盖分析后，需要对设计驱动激励。这可以通过约束随机测试实现。约束随机测试产生反馈到测试平台的设备处理事务，表明被识别的测试点已被覆盖。如果设计空间非常大，约束随机测试就不能包含测试点没有覆盖的边界条件。这种测试不用创建使用HDL覆盖工具达到100%覆盖的激励。但是，在设计中遍历所有状态并覆盖所有条件并不能保证设备被完全验证。
软件代码作为激励
对于一个超过1034个组合的验证空间来说，让实际的设备操作执行所有必需组合是不太可能的。应当把重点放在设备会运行的那些操作上，对那些理论上可能不会使用的操作要减少花费时间。最简单快捷的方法是找到可驱动设备的现有代码。这可能是诊断代码，驱动程序代码或应用程序级算法。每个这样的代码均提供了不同的验证级别，并揭露了不同类型的问题，因此，应当尝试获得和使用所有类型的代码。
对于新的设计，代码很可能不存在，但对于下一代产品的设计，一些代码常常可以得到。如果这些代码存在，设计的激励在几乎不耗费精力或成本的情况下就可以得到。如果代码不存在，但合作方愿意在设计周期前期创建代码，那么也可以轻松地创建激励。最后，如果验证团队需要创建代码，通过编写C代码来为设计创建复杂多样的激励比使用任何其它语言都更容易。
假设显示
使用假设显示，需要运行描绘各种测试模式和色彩组合的诊断代码以确保连接。也可以运行驱动程序代码，它可以连接至一个简单的画图应用程序，该应用程序可使用一些代表样本的像素将驱动程序调整至适当位置。最后，采用最终使用这个设备的应用程序，并画出几幅图像。每种类型的代码会以不同的方式运用设计，从而能发现利用其他方法时不容易检测到的问题。
硬件/软件协同验证
很多硬件和验证工程师(甚至在某些方面软件工程师)认为，运行应用程序的任何部分不会加快设计验证。毕竟，如果针对设备测试驱动程序，并针对驱动程序测试了应用程序，就无需进行进一步验证。但是这些工程师不会考虑在尚未系统地测试所有软件的情况下发布产品，也不会接受在未经系统测试的情况下发布要去tapeou的硬件设计。系统级协同验证测试全部的可选组件，包括硬件、软件、或两者的组合，从而揭露在分离情况下不会被发现的问题。
软件覆盖范围
运行软件提供了一个切合实际的激励，但它不可能为验证空间提供足够宽的覆盖范围。软件通常是一遍一遍地重复只具有些微差别的相似操作。因此，这种方法应当结合其它现有验证技术一起使用。同时，运行大量的软件通常不会改善验证效果。在不牺牲验证结果的情况下，通过对软件进行少量修改，能够缩短较长的代码操作。例如，在上述显示设备实例中，向所有位置写数据的诊断程序能够被缩短为只写前3行和最后3行。这样做不会减少覆盖范围，却能使测试速度加快45倍。
划分内存系统
将代码作为设计激励运行时，无疑会令人增加对设计被全面验证的总体信心。并且，在大多数情况下，它能暴露其它验证方法遗漏的设计缺陷。但是，在逻辑仿真中运行代码是非常慢的。逻辑仿真器通常以10Hz到100Hz的速度执行操作。在这样的性能水平条件下，只有少量的代码能够运行。
以执行代码时产生的电路行为为例，连续的九条ARM指令会产生15个总线周期。在这15个总线周期中，只有2个和硬件操作有关。剩余的13个只支持代码的执行，不会对测试的设备产生任何影响。当然，基于处理器高速缓存和缓冲区的设定，并非所有的这些总线周期都能获得处理器上的外部信号。但是，即使总线周期不通过外部驱动，它们也需要由整个电路的仿真器来处理的时钟。降低仿真性能的不是总线周期的电路行为，而是设计中附加的时钟驱动。
把处理器的内存系统分割为I/O空间、代码空间和数据空间时，可分隔这些总线周期，只将I/O周期加入到逻辑仿真中。通过过滤逻辑仿真器中的代码和数据周期，他们能够在不占用仿真时间的情况下得到处理。这使得仿真速度加快。尽管全功能处理器模型执行所有的总线周期和指令，但逻辑仿真只在总线周期处于某一特定范围内时才会进行。这样，逻辑仿真只关注专门针对被验证设备的总线周期。不参与逻辑仿真的分区内存可以描述为已被软件图像预先初始化的“超级高速缓存”。这种“超级高速缓存”足够大，能容纳全部的软件图像和所有数据，并提供无限的快速访问。能够放置在普通高速缓存中而不影响设计操作的内存，都可以安全地放置在这个“超级高速缓存”中。直接由硬件访问的内存区域是不可缓存的，且必须建模为硬件仿真的一部分，以向硬件提供访问这些内存区域的权限。
增强的性能
回到假设显示模块，使用AMBA总线周期驱动寄存器输入和读取寄存器输出。结果，诊断和驱动程序代码的仿真时间减少了10倍以上，小型画图程序的仿真时间减少了30倍。程序所作的计算不只是将像素复制到屏幕上。它将像素和以前的图像进行比较，只有当数值变化时才写入像素和地址。当软件的复杂性增加时，性能因素也随着提高。仿真吞吐量的增加是由于不需要运行与总线周期相关的时钟。如果软件完成更大的计算量，性能提高会更大。
