摘要：本文以一个整合了ARM核和多DSP核等IP的多媒体处理SOC芯片的验证项目为背景，介绍了项目中所采用的以覆盖率为目标，以随机验证为基础，自底向上的验证方法。文中结合了项目中的典型案例，针对SOC设计的特点，着重分析了如何建立带有完备的自检测功能的SOC验证环境和如何确立SOC验证功能点，即验证重点这两个随机验证工作中的难点。
1. 引言
随着应用环境越来越复杂，对成本和性能的要求越来越高，SOC设计已经成为IC设计的一个趋势。SOC设计一般包括一个或多个处理器系统(处理器及其外设)、存储器、互连总线、高速接口模块（如千兆以太网，RapidIO, PCI-Express等）。SOC设计实际上集成了以往的一块板级系统，千万门以上的设计非常多见，如何验证如此复杂的系统，是摆在设计者面前的一个问题。此外，SOC系统设计中绝大多数的任务就是整合现有的IP，因此主要问题就在IP之间复杂的接口上，而不是IP设计本身。如果没有一套快速有效的验证方法，验证将成为严重制约SOC产品开发的瓶颈。
文中需要验证的设计是一个带有多个DSP核和ARM核的典型SOC系统，芯片对外提供以太网接口和音频接口。ARM完成系统的配置和管理，DSP实现多媒体处理运算，通过多个DSP核可以完成大容量数据的处理，从而降低单信道成本。这种结构现在广泛用于音频、视频处理方面，具有灵活、高效等优势。
第二节概述了验证的方法，着重介绍以覆盖率为目标的随机验证的思路；第三节介绍如何将上述思路贯彻到SOC的设计中，并以几个项目中遇到的典型缺陷为例，着重分析验证重点（即验证功能点）的确立和自检测验证环境的建立这两个难点；最后一节总结全文，并给出几点结论。
2. 验证方法介绍
实际中，我们采用以覆盖率为目标的验证方法。在这个项目中，覆盖率为目标的验证思路得到了很好的贯彻。产品开发初始阶段，我们就定义好覆盖率，在随后的开发的每一个环节，覆盖率都被作为我们验证进程的衡量指标。到最后项目结束，覆盖率达到100％。下面着重阐述验证方法的几个重要方面。
2.1验证目标
覆盖率是我们的验证目标。所谓覆盖率包括两方面，代码覆盖率和功能点覆盖率。代码覆盖率比较简单，现在大部分的仿真器都支持自动统计代码覆盖率。而对于功能点覆盖率，则需要设计者或者验证者确定，有很大的人为因素。如何确立合理的功能点，即如何抓住验证的重点，是验证的关键。一般来说，验证者需要根据产品需求书和设计说明书，抽象出产品的特性，再细化为具体的验证功能点。这一过程也需要设计者的参与，因为设计者可以从设计角度给出一些验证重点的建设性意见。对于SOC设计，由于其结构的相似性，有许多相似的验证重点，下一节对其做了一些总结。
2.2验证流程
确立验证目标后，我们采用自底向上的验证流程。设计中重用的IP一般会提供相应的验证环境，主要的功能点覆盖率和代码覆盖率需要在IP的验证环境中达到。对于全新的设计，设计者需要建立子模块验证环境，来达到覆盖率的目标。而在系统级验证环境中，每个模块的输入激励的可控性受到很大的局限，因此覆盖的重点主要集中在IP之间的互连上。
2.3 随机验证
在以覆盖率为目标的验证方法中，随机验证是一个很重要的方面。测试功能点实际上最终被具体为某些参数范围。例如，数据包传输系统中，数据包的长度，各个字段的可能值等都可以被作为测试功能点；设计内部的状态，端口的变化等也可以被用作测试点。在写测试实例时，需要尽量随机化这些参数，从而产生随机的测试矢量。这些随机矢量被作为待测芯片的激励。而随机化的结果，可以被环境记录下来，用来分析功能覆盖率。
随机验证需要验证环境的支持。一般来说，支持随机验证的环境有以下一些特点：
1) 完备的带有自检测功能的验证环境：环境需要自动对待测电路的正确行为进行预测，如果实际的行为和预测的行为不一致，环境需要指出错误。
2) 灵活的随机激励产生机制：随机激励需要具有随机性、稳定性和可重现性。随机性保证了激励产生具有良好的分布，经过多次重复，可以覆盖到所有可能的值；稳定性保证了不同的平台，仿真器等不会导致随机结果的变化；可重现性保证如果发现错误，可以很容易再现错误。
3) 随机结果记录机制：随机结果覆盖过的值，需要记录下来，以用作覆盖率的分析。
2.4 直接测试
随机测试是测试的主要手段，而直接测试作为辅助手段，也是必不可少的。在测试的最后阶段，覆盖率分析后，可以采用直接测试弥补少量随机测试很难覆盖的测试漏洞，这样的效率往往会比较高。另外，在验证环境不够稳定，或者少数测试情况环境很难支持自检测时，也往往需要采用直接测试。另外，直接测试也可以和随机测试相结合，某些测试参数固定，而另一些随机，这种直接随机测试的方法，在验证中使用的也比较多。
3. 验证重点和典型案例分析
SOC设计具有很多共性，例如一般都是通过多个IP整合构建，一般都有处理器、存储器、寄存器等等。由于这些设计上的共性，在验证上也有很多共同的验证重点，本节结合项目中的具体例子，分析一些典型的SOC验证重点。
3.1IP 之间的接口
比较大的SOC设计都包含多个IP，由于有些IP功能非常复杂和产品开发的市场压力，在系统级验证上很难覆盖到IP所有的功能。在有限的时间内，主要精力需要放在IP之间的互连接口上（当然，前提是IP提供者已经对IP进行了完备的测试）。在确定验证功能点时，需要考虑这一点。验证功能点可以包括端口所有支持的操作类型、端口信号的可能输入以及它们的翻转等。
一般来说，导致IP之间接口的缺陷的原因有以下几种情况:
1) 互连的IP设计者 双方对接口协议理解不一致或者协议的某些部分定义尚不明确；
2) 互连的IP支持接口协议的不同子集；.
3) 集成者对于IP接口理解失误,从而导致集成错误；
4) 有些IP之间整合时需要加入粘连逻辑做接口转换，错误往往发生在这些粘连逻辑上。
从上面可以看出，SOC设计IP接口缺陷发生的主要原因是对接口理解失误导致的。因此，将IP尽可能的统一到简单、通用的接口上可以大幅度的降低接口缺陷发生的概率。
下面分析一个项目中遇到的典型缺陷的例子：
项目中使用了一个带有AHB接口的以太网MAC的IP和一个AHB到AHB桥接器IP，他们都是预先验证过的IP，之间通过多层AHB交换总线相连。如图1所示。
MAC AHB接口的HLOCK输出并不完全符合AHB接口协议，但是这在访问其他外设（如带有AHB接口的DPRAM）时，并没有问题。但是，当从MAC发出的带有LOCK的一组传输想通过AHB2AHB桥接器时，却会导致输出端在NONSEQ传输和SEQ传输之间插入若干个IDLE控制，这是严重的接口协议的错误。
从上面的例子可以看出，预先验证过的IP在互连时可能会有问题。为了抓到上面的问题，需要在接口上做一致性检测，保证每个接口对协议的理解相同，并且严格遵守；同时，由于问题可能只出现在某两个特定的IP之间，因此需要保证每两个IP之间的数据通道被验证过；还需要关注每个接口信号的翻转，在上述例子中，如果不关注HLOCK信号的翻转，问题可能不会被发现。
3.2交换互连总线验证
在复杂的SOC中，交换互连总线可以作为独立的模块用作为各个IP之间的互连。交换互连总线往往包括输入逻辑、地址译码、总线仲裁和输出逻辑几部分，可以完成数据流交换、地址分配、共享资源的优先级确定等功能。其作为IP之间的接口模块，是数据流的必经通道，因此也是验证的重点。
项目中，由于主要的IP是基于AHB总线的，我们采用的交换互连总线是ARM提供的参考设计，同时需要在此参考设计的基础上定制端口优先级逻辑和地址译码逻辑。为了充分验证这块修改过的交换连接总线，我们建立了基于Specman e和AHB eVC的一个全随机的验证环境，如图2所示。
交换互连总线的每个接口（主接口和从接口）都接有AHB 的eVC。AHB eVC可以产生随机激励，同时对每个接口进行一致性检测。在输入和输出接口之间有记分板（scoreboard）保证输入输出数据的一致性。由于环境简单，并且激励产生灵活，可以做大量的随机测试，从而保证所有关心的接口组合情况都被测试到。实践证明，这种测试方法非常有效，不仅抓到设计改动的问题，而且还暴露出参考设计中的一些潜在的问题。
3.3处理器建模和验证重点
处理器是SOC系统的核心，一般完成控制、配置和计算等功能。处理器的验证可以包括以下几个方面：1） 处理器RTL代码的正确性。处理器作为IP，有自身的模块验证环境，RTL代码的正确性需要在这一环境中得到验证；
2） 软硬件协同仿真。采用处理器的行为级模型，验证处理器能否和软件协同完成系统中的工作，并能做系统的性能评估；
3） 处理器的系统级仿真。需要在系统级仿真环境中建立处理器的端口功能模型。采用高级语言（SystemC或 Specman e等）实现，但不实现内部逻辑。测试者可以通过配置，模拟处理器的各种端口操作。通过这种方式可以模拟处理器在实际系统和其他外设的互动（对寄存器和存储器的读写、中断的响应等），从而测试处理器在系统中能否工作。
上述的处理器RTL代码、行为模型和端口模型从模拟精度上来说，是逐渐降低的。在作系统级验证时，为了减少复杂度，同时主要的关注重点是在端口行为上，我们采用了处理器的端口功能模型。下面具体讨论处理器系统级验证的两个重要方面。
3.3.1中断的接受和响应
中断是处理器验证的重点之一。验证时需要考虑中断的不同触发类型：电平触发、沿触发和脉冲触发等等。验证中断时需要考虑两个方面：外设的中断是否能被处理器正确的检测到；处理器能够及时的清除中断。对于有多个中断的情况，还需要考虑中断是否同时发生，中断之间的优先级等等。
项目中遇到的典型中断缺陷是中断发生设备和中断接受设备对中断的理解不同，例如，一个认为是电平触发，另一个认为是上升沿触发；还有就是中断不能被正常清除，或者清除一个中断会阻止其他中断被检测到等等。
3.3.2处理器对地址空间的操作
不同处理器有不同的地址空间分配，同一个物理单元(存储器或寄存器)也可以被不同的处理器以不同的地址访问，这里也存在处理器竞争，这些都是验证的重点。
验证需要覆盖到不同地址段的边界，每个地址段需要覆盖所有的处理器支持的操作。同时，如果不同处理器的地址分配不同，每个处理器的地址段边界都需要覆盖到，这样才能保证所有处理器的地址分配正确。如果同一个地址能被多个处理器访问，还需要验证处理器之间的竞争问题。
一个典型的设计缺陷如图3所示。
处理器（如ARM） 通过交换总线访问外设（如DMA），片选信号（CS）由交换总线译码产生，设计时为DMA预分配了32k的地址（片选信号CS由Addr[31:15]译码产生）。实际上，DMA的地址空间仅有4K（即只有12位地址输入），这样DMA的任意一个地址单元，对ARM来说，都有8种可以访问的地址（Addr[14:12]可以为任意值），这不是设计者所期望的。
3.4 存储器的验证方法和重点
在复杂的SOC设计中，存储器的规模一般也很大，如何快速有效的实现验证环境对存储器的自检测，并且确定存储器的验证重点，是SOC验证者需要解决的问题。
一个比较有效的存储器自检测模型是离散存储器模型（Sparse Memory）。验证环境通过在每次读写存储器时，记录并且比较存储器的值，保证两次读写同一个物理单元时数据的一致性。如果存储器提供后门方式，也可以通过将每次正常读写时得到的值和后门方式得到的值比较做自检测。
存储器有很多类型，如内置存储、外置存储、ROM、RAM、Flash、单口、双口、多口等等。存储器的验证需要覆盖到以下几个方面：
1）存储器的地址边界：包括多块存储器的边界、同一块存储器的行边界、列边界、组（bank）边界等等；
2） 存储器的操作：需要测试存储器在各个地址段的所有支持的操作，如果存储器支持并发（burst），需要测试并发操作跨越上述边界的情况；
3） 为了连接存储器到某个通用的接口上（如AHB），需要有转换逻辑（Memory Wrapper），这也是验证的重点，需要验证转换后接口的各种操作；
4） 对于双口或多口的存储器，需要验证端口之间的竞争问题，如从不同的端口同时读写同一个物理单元等。
3.5 寄存器的验证方法和重点
寄存器是硬件和软件的常用接口，一般分为以下几种：
1) 可读写的寄存器：供软件配置，硬件根据配置工作于不同模式；
2) 只读寄存器：反映硬件的状态，供软件查询；
3) 只写寄存器：供软件触发某些硬件动作，如中断清零等。
寄存器的自检测通过在环境中建立“影子”寄存器完成。每一个硬件寄存器，都有与之对应的“影子”寄存器。其初始值和硬件寄存器上电后的初始值相同，并且根据环境的变化（寄存器的读写，硬件状态的改变等等），“影子”寄存器及时更新，因此影子“寄存器”可以随时跟踪实际硬件的变化。验证环境自动比较影子寄存器和硬件寄存器的读回值，这样可以检测可读寄存器的正确性。对于只写寄存器，需要在写操作后检查相应的状态来验证结果。
SOC设计中寄存器的验证重点有以下几点：
1） 上电后寄存器的默认值是否符合设计文档定义；
2） 寄存器的读写操作；
3） 可写寄存器和只读状态寄存器值的翻转。
对于IP的寄存器，上述的验证点可能在IP自带的验证环境中达到，在系统级仿真中，可能只验证IP的基本功能和寄存器的默认值。
3.6 性能验证
IP有自己的性能指标，但是由IP整合后的系统的性能指标是否满足产品需求说明书上定义的性能需求还需要做系统级仿真才能得到。一般来说，系统的性能不仅取决于硬件的结构，还和系统操作类型有关，例如，共享的资源被多个源点同时访问时，系统性能可能会受到影响。
下面以ARM访问存储器的延时为例，说明SOC性能验证的方法。图4给出ARM访问存储器的示意图。
验证环境自动收集ARM处理器通过交换总线访问存储器的端到端延时。在做性能验证时，需要确定ARM的AHB接口操作的类型和典型的应用（ARM处理器操作存储器时，有无其他外设与之竞争等等）。在系统级验证时，需要仿真这些典型应用，这样得到的性能指标才与实际值比较接近。
4. 结论
1） 实践表明，在SOC验证中采用自底向上的验证流程、随机验证的手段和以覆盖率作为验证目标是非常有效的。问题的关键是如何建立适应随机验证的验证环境和如何确立覆盖率的重点。
2） 适应随机验证的关键是验证环境需要有完备的自检测功能。自检测模块一般包括：IP接口的协议检测（包括时序检测，非法状态检测等）、IP接口之间的记分板模型、IP的功能参考模型等等。建立验证环境时，需要灵活采用上述模块，以保证环境具有完备的自检测功能。
3） SOC的大部分设计是通过整合现有IP完成，因此验证的重点是在IP之间的连接上。验证的功能点需要覆盖到IP接口所有的操作和信号的变化。如果能够将IP连接接口统一到同一个比较成熟而且定义明确的接口上，可以降低错误发生的概率。
4） 典型的SOC设计包括处理器、互连总线、外设、存储器、对外接口IP等元件组成，还有作为软硬件接口的大量寄存器。针对这些元件，本文讨论了验证方法和验证的重点，并且分析项目中遇到的典型缺陷。
5） 覆盖率作为衡量验证进程的重要参数，贯穿了验证工作的始终。在项目的每个阶段点，我们需要检查我们已达到的覆盖率，并且要检查覆盖功能点目标是否合适，是否满足设计要求。这样，不仅明确了验证工作的目标，而且验证的进程也有了衡量的标准，这两点对大规模的SOC设计的验证工作都很重要。
参考文献
1． Agere Systems Inc.、 多媒体网关产品需求说明书、2004
2． Agere Systems Inc.、 多媒体网关设计说明书、2004
3． Agere Systems Inc.、 多媒体网关测试环境说明书、2004
4． Agere Systems Inc.、 多媒体网关测试计划书、2004
5． Agere Systems Inc.、 多媒体网关测试覆盖功能点说明书、2004
6． Verisity Design Inc.、 e language reference、 1998
7． Verisity Design Inc.、e Reuse Methodology、 2002
8． Verisity Design Inc.、 Verification Adviser、1998
9． Verisity Design Inc.、 Online help、 1998
10. Verisity Design Inc.、 AHB eVC User Guide, 2000
11. ARM Inc.、 AMBA specification （Rev 2.0）、 1998
12. ARM Inc.、 Multi-layer AHB overview、 2001
作者简介刘劲松，2003年获清华大学硕士学位，2003年8月至今在杰尔系统上海有限公司从事芯片设计验证工作。先后参与研发通信SDH/SONET 传输适配芯片、DDR2控制器IP、DDR2和FCRAM物理层接口IP、多媒体网关SOC芯片和1394b物理层芯片。
林涛， 2001年获复旦大学电子工程硕士学位，2001年7月至今在杰尔系统上海有限公司工作，先后参与研发SDH/SONET传输、Packet Over SDH/SONET、多媒体网关等领域的芯片。