如何利用软件作为激励来加速SoC系统级验证？

硬件/软件协同验证

　　很多硬件和验证工程师（甚至在某些方面软件工程师）认为，运行应用程序的任何部分不会加快设计验证。毕竟，如果针对设备测试驱动程序，并针对驱动程序测试了应用程序，就无需进行进一步验证。但是这些工程师不会考虑在尚未系统地测试所有软件的情况下发布产品，也不会接受在未经系统测试的情况下发布要去tapeou的硬件设计。系统级协同验证测试全部的可选组件，包括硬件、软件、或两者的组合，从而揭露在分离情况下不会被发现的问题。

软件覆盖范围

　　运行软件提供了一个切合实际的激励，但它不可能为验证空间提供足够宽的覆盖范围。软件通常是一遍一遍地重复只具有些微差别的相似操作。因此，这种方法应当结合其它现有验证技术一起使用。同时，运行大量的软件通常不会改善验证效果。在不牺牲验证结果的情况下，通过对软件进行少量修改，能够缩短较长的代码操作。例如，在上述显示设备实例中，向所有位置写数据的诊断程序能够被缩短为只写前3行和最后3行。这样做不会减少覆盖范围，却能使测试速度加快45倍。

划分内存系统

　　将代码作为设计激励运行时，无疑会令人增加对设计被全面验证的总体信心。并且，在大多数情况下，它能暴露其它验证方法遗漏的设计缺陷。但是，在逻辑仿真中运行代码是非常慢的。逻辑仿真器通常以10Hz到100Hz的速度执行操作。在这样的性能水平条件下，只有少量的代码能够运行。

　　以执行代码时产生的电路行为为例，连续的九条ARM指令会产生15个总线周期。在这15个总线周期中，只有2个和硬件操作有关。剩余的13个只支持代码的执行，不会对测试的设备产生任何影响。当然，基于处理器高速缓存和缓冲区的设定，并非所有的这些总线周期都能获得处理器上的外部信号。但是，即使总线周期不通过外部驱动，它们也需要由整个电路的仿真器来处理的时钟。降低仿真性能的不是总线周期的电路行为，而是设计中附加的时钟驱动。

　　把处理器的内存系统分割为I/O空间、代码空间和数据空间时，可分隔这些总线周期，只将I/O周期加入到逻辑仿真中。通过过滤逻辑仿真器中的代码和数据周期，他们能够在不占用仿真时间的情况下得到处理。这使得仿真速度加快。尽管全功能处理器模型执行所有的总线周期和指令，但逻辑仿真只在总线周期处于某一特定范围内时才会进行。这样，逻辑仿真只关注专门针对被验证设备的总线周期。不参与逻辑仿真的分区内存可以描述为已被软件图像预先初始化的“超级高速缓存”。这种“超级高速缓存”足够大，能容纳全部的软件图像和所有数据，并提供无限的快速访问。能够放置在普通高速缓存中而不影响设计操作的内存，都可以安全地放置在这个“超级高速缓存”中。直接由硬件访问的内存区域是不可缓存的，且必须建模为硬件仿真的一部分，以向硬件提供访问这些内存区域的权限。

增强的性能

　　回到假设显示模块，使用AMBA总线周期驱动寄存器输入和读取寄存器输出。结果，诊断和驱动程序代码的仿真时间减少了10倍以上，小型画图程序的仿真时间减少了30倍。程序所作的计算不只是将像素复制到屏幕上。它将像素和以前的图像进行比较，只有当数值变化时才写入像素和地址。当软件的复杂性增加时，性能因素也随着提高。仿真吞吐量的增加是由于不需要运行与总线周期相关的时钟。如果软件完成更大的计算量，性能提高会更大。

使用附加的设计模块

　　这篇文章描述了单个设计模块激励的代码应用程序。因为代码和数据空间的内存没有被建模为硬件的一部分，因此可以在完成全部设计之前，在一个单独的设计模块上运行这种类型的测试。它不需要设计完整的内存子系统并作为仿真的一部分运行。当运行一些模块级测试时，有必要将附加的硬件组件和I/O数据流建模为仿真运行的一部分。使用相同的过滤技术，可以把给定内存区域的内存处理事务传送给任意的C函数。这可以通过建立一个基于地址范围的回调函数实现。这样，没有建模为HDL的软件需要的组件能够用简单的C函数替代。同样，对I/O端口的读写可以通过基本的C函数连接到主机文件和I/O系统。对于包含很多硬件设计的系统级仿真，也可以使用相同的方法。对于这种情况，硬件模块被替代的越少，在逻辑仿真器中出现的行为就会更多。

结语

　　本文介绍了一种使用软件作为激励以加速系统级验证的方法。使用的激励是切合实际的，并易于快速创建。对设计执行此激励可及早揭露问题，否则，这些问题可能要等到创建虚拟原型后才会被发现。提高性能的关键在于过滤出与硬件操作无关的代码和数据引用，并在分区内存存储中处理。这种方法能使验证工程师解决日益增长的功能验证挑战。Questa验证平台可以自动把固件输入到测试平台，加速取指令操作与内存引用执行，并提供源代码级的调试环境。