随着集成电路设计规模和设计复杂度的不断增加，传统的功能验证(Functional Verification)方法由于存在测试集(Test Suite)过于庞大、执行时间过长等缺点，已经无法提供足够的性能来检查系统所有功能的正确性。同时，基于IP重用的系统芯片SoC(System on a Chip)设计方法学的出现，也对传统验证方法提出了新的挑战。在缺乏足够相关专业知识的情况下如何有效验证第三方提供的IP；如何对单个IP以及系统集成后的SoC进行验证并提高验证效率等，都是SoC验证工程师所面临的难题[1～2]。
　　传统的方法是设计者提供待验证元件DUV(Design Under Verification)的验证平台，输入测试向量，验证测试结果是否正确。这种方法的缺陷在于，对于不同的DUV需要开发不同的验证平台。SoC设计是一种面向集成的设计，包含模块(即IP)设计和系统集成两个部分。因此，传统的SoC验证需要开发两个验证平台：IP单独验证平台和SoC系统集成验证平台。验证平台的开发本身需要时间，不利于产品的快速面市，而且也很难保证设计的验证平台本身100%的正确。如何提高这两个验证平台的开发效率也就成了验证的难点。
　　关于验证平台的研究，目前主要集中在三个方面：提高验证元件的抽象层次^[2][3][5]；提高验证元件的可重用性[3～6]和提高验证过程的自动化实现[5～7]。提高验证元件的抽象层次，可以更早地发现设计错误，减少系统的开发时间；提高验证元件的可重用性，可以减少验证平台的开发时间；提高验证过程的自动化实现，可以加大验证过程的运行效率。以上三种方法都可以有不同程度的提高验证效率，然而其开发过程都是针对特定的DUV的。同一种DUV或其衍生系统，可以用上述方法开发。但对于不同的DUV，就需要重新设计验证平台。例如对ROM和CPU的验证，就需要设计两种不同的验证平台，对不同的系统芯片更是如此。
　　本文正是在传统方法的基础上，提出了一种基于总线的可重用验证平台结构，在传统的抽象和模块化方法的基础上，采用层次化的片上总线结构，使验证元件的开发基于特定的总线，只要总线不同，验证元件就不需要修改。同时，为了进一步提高可重用性，采用了参数化的思想。使用该方法构建的验证平台，可以同时适用于IP单独验证和SoC系统集成验证，即不仅可以在不同的IP之间实现可重用，而且在IP到SoC的集成也可以实现可重用。该验证平台极大地提高了验证平台的开发效率。对于IP单独验证，如果IP基于同一总线，验证平台开发时元件的重用率可以达到100%，如果IP不是基于同一总线，仅仅需要修改部分验证元件。该验证平台同时还具有可扩展性、自动化、可升级性和可维护性等特点。
1 基于总线的可重用验证平台结构
　　随着IP标准化工作的进行，SoC的结构趋于统一，采用层次化的片上总线结构，SoC包括处理器总线、系统总线和外设" title="外设">外设总线，所有的IP组成SoC时，都是挂接在这三条总线上^[8]的。其结构如图1所示。由图可见，存储器管理单元(CPU、MMU)、高速缓存、主存储器、仲裁器和IP分别接在处理器总线、系统总线和外设总线上，集成为SoC。
　　基于特定的总线不同的IP可以实现重用，IP可以集成为SoC，是因为采用了层次化的片上总线结构，可以根据IP的种类将其分别挂接在处理器总线、系统总线和外设总线上。基于这种思想，验证平台也可以采用层次化的片上总线结构，如图2所示。将验证平台分解成监视器、总线报告器(Bus Reporter)、驱动、系统服务等，并分别挂接在处理器总线、系统总线和外设总线上。本文介绍的验证平台是建立在VSIA IPBUS 2.0规范^[8]的基础上的。只要参与验证的模块符合VSIA 的IP设计规范，就可以直接使用该验证平台来验证。对于不符合VSIA规范的IP，在验证前需要增加一层接口来封装这个IP，这层接口实现IP与VSIA协议的转换。该验证平台在SOLARIS 8操作系统下开发，用BOURN shell脚本、RERL脚本和Verilog编写，仿真器采用Cadence公司的Verilog-XL。

　　验证模块可以根据需要加入验证平台。每次的验证过程就是相应的激励作用于验证平台的过程。验证结果由验证平台产生、检验和输出。其中，监视器、总线报告器、驱动、系统服务和激励文件的开发采用抽象和模块化原则，具体可见参考文献^[2]、^[4]中介绍的方法。
　　监视器用于检查总线上的数据传输，报告接口上关键信号的变化。验证平台提供的标准监视器模板有：处理器总线监视器模板、系统总线监视器模板和外设总线监视器模板。总线报告器用于报告总线上协议的错误和特定信号；同时也提供了相应的标准模板。监视器和总线报告器可以根据需要打开或关闭，可以通过控制参数值来实现。为了方便，验证平台在设计时将该参数放到了验证时的系统配置文件中。
　　激励系列是由Verilog和C语言编写的测试向量。严格来说，激励并不是验证平台的一部分，因为激励与要验证的元件密切相关，随验证元件的不同而不同，但激励是调用驱动来实现的。驱动就如同软件设计中调用系统API的应用程序，所以激励是进行验证不可缺少的部分。
　　为了方便操作，验证平台在设计时，将一些经常需要配置的部分设为参数，然后将这些参数放在配置文件中来设置。通过配置文件可以配置驱动、监视器和验证选项。配置文件和激励文件都由验证平台的使用者编辑。
　　验证平台的另一个特点是灵活性。利用Cadence公司的Verilog-XL仿真器，各待验证元件的模型可以是多种形式的描述。该验证平台可以进行C/C++、Verilog和VHDL协同验证，支持的模型包括C/C++的PLI、VPI或OMI模型、Verilog/VHDL行为级模型、Verilog/VHDL RTL级模型或Verilog/VHDL门级模型以及管脚模型。该验证平台还可以根据配置文件来调取同一IP的不同版本，实现版本控制。对于不同的描述，激励大都需要重写。使用该验证平台，使得同一激励文件可以应用设计的各个阶段，避免了重复编辑激励文件，从而在验证环节上节省了大量时间。
　　上述基于总线的可重用验证平台可以同时作为IP单独验证平台和SoC系统验证平台使用。验证单个IP时，为了提高验证速度，只需将该IP所对应的总线上的监视器和总线报告器保留，而将其他总线上的监视器和总线报告器关闭，以免消耗系统资源，影响验证速度。例如，验证主存储器时，只需要保留系统总线上的监视器和总线报告器，将处理器总线和外设总线上的监视器和总线报告器都关闭。验证SoC时，其系统验证平台的连接见图2。
　　监视器和总线报告器不驱动信号，仅完成对信号的监视，包括检查协议的连续性、时序和期望的响应等。从图2中可以看出，监视器和总线报告器的设计是基于特定总线的，在构成另一个SoC验证平台时，只要特定的总线不变(如其处理器总线)，若两个SoC都使用M*Core CPU时，处理器总线上对应的监视器和总线报告器就可以直接使用，因此有很高的可重用性。考虑到监视器可能会监视内部信号，因此在逻辑综合时，需要将这些要监视的内部信号保留。驱动和系统服务都是基于外设总线的，为了进一步提高可重用性，将驱动和系统服务分解成一个个子任务来实现，任务之间互相独立，当修改一个任务时不会影响其他任务，所有的任务合在一起就构成了任务库。驱动所对应的任务库是基于外设总线的。系统服务所对应的任务包括验证平台的配置、验证的自动化实现及验证工具的调用等。此时激励文件的编写就变成了调用任务库中的任务，使激励文件的编写更简单易行。
2 验证平台的数据结构
　　验证平台所涉及的文件和工具非常多，采取合理高效的目录管理有利于项目管理和设计数据的更新，方便脚本的调用和配置，从而实现验证过程的自动化。为此将验证平台分为：工具目录、整体目录(也称系列目录，Family Directory)、模块目录和工作目录四个子目录。
2.1 工具目录
　　该目录下存储验证平台运行时所需要使用的验证工具以及与整体目录的链接。该目录下主要有两个脚本文件：family_mapping和sim_env。family_mapping文件指定芯片系统数据映射路径，sim_env文件提供验证平台的入口，文件包含对Verilog-XL仿真器工具、代码覆盖率工具等调用接口，并通过shell语言的文本过滤命令sed和awk，提取目录和文件，以便构建完整的验证平台。其工作原理是：从模块目录中提取验证所需的模块文件(.v)和从模板产生测试文件(test.v)，并将这些文件名和验证时所需要的工具和相应参数全部输出到一个文件中，即验证所需要的所有元件全部在该文件中，用脚本调用该文件就可以完成验证过程。验证平台的可重用性主要体现在本目录。在该目录中，使用了参数化的思想来达到重用的目的。使用者可以通过配置参数来建立所需要的验证平台。这是该验证平台的特点之一，也是其与传统验证平台的不同之处。
2.2 整体目录
　　建立当前验证平台所需的信息存储在整体目录中，包括可重用的代码信息(如监视器和总线报告器等)、系统服务、辅助文件、内部链接等。验证平台的可升级性主要体现在这个目录中，当SoC升级或做部分修改时，其相应的验证平台就需要调整，如在SoC升级为后续衍生产品的验证中，系统服务就需要修改，而此时系统服务可以与原来有不同的实现，但必须有相同或相似的接口和参数。这样，激励文件和脚本文件就可以不用修改，从而实现修改程度最小化。
2.3 模块目录
　　该目录包括当前需要验证的设计的源代码" title="源代码">源代码及相关信息。对于集成电路来说，按照设计流程可以划分为系统级设计、RTL级设计、门级设计、布局布线设计，因此模块目录可以相应地划分为以下子目录：系统级源代码、RTL级源代码、门级源代码和布局布线级源代码等，每一个子目录中存储相应设计阶段的代码，如RTL级源代码存储在RTL级源代码目录下。需要做某个阶段的验证时，只需要将验证参数设置成该阶段，就可以调用该阶段的代码。
2.4 工作目录
　　该目录是验证工程师的操作目录，是验证平台和验证工程师的接口。在验证过程中，验证工程师编写的激励文件、运行仿真以及最后的错误分析等都在该目录下进行。对验证工程师来说，该目录是惟一可写的目录。工作目录又可以进一步分为验证配置文件、文本信息及波形文件、验证代码和验证脚本等四个子目录。验证配置文件目录存储配置文件，验证工程师配置验证平台只需在该文件中配置相应参数即可。验证代码的编写存储在验证代码目录中，对应于不同阶段的设计，验证也可以分为相应阶段的验证：系统级验证、RTL级验证、门级验证和布局布线后验证。类似地，不同阶段的验证也可以通过设置参数来实现。文本信息及波形文件目录存储验证时产生的文本文件和波形文件，用于分析验证情况和追查错误信息等。验证脚本目录用于存储验证平台的脚本，该脚本用于自动化地完成验证过程。
　　从平面结构上看，验证平台的目录是由如上所述四种类型的目录组成的。而从立体结构上看，它们之间又是有层次的，这种层次结构能比较直观地反映设计版本信息和验证阶段信息，从而有利于项目管理者推进验证进度。验证平台建立好后，模块目录和验证目录都通过链接集成在系统中。整个验证平台的系统结构如图3所示，其中，库文件目录中存放基本可重用模块，顶层目录是一个项目的根目录，基本配置文件中存储可参数化测试平台的配置信息。虽然在文件的存储结构上，模块目录和工作目录等都在同一层次上，但各目录以图3的方式链接，形成树状结构。

3 可重用性的实现与可重用性分析
3.1 可重用性的实现
　　可重用性的实现主要体现在以下几个方面：采用验证平台配置文件、采用参数化的设计思想和基于总线的验证平台结构。分述如下：
　　(1)所谓验证平台配置文件，是指用来对验证平台进行配置的文件。在验证平台中需要使用哪些模块(包括源码和验证文件等)和验证工具等，可以直接由验证平台配置文件来指定。这样做的好处是验证工程师在构建另一个新的验证环境时，只需要修改验证平台的配置文件，而不需修改其他部分，提高了验证平台的建立时间，缩短了验证周期。
　　类似于DOS操作系统中的配置文件，当验证工程师不对配置文件进行配置时，自动使用默认配置，使修改的程度最小化。因为验证平台之间许多配置是一样的，只要将这些相同的部分作为默认值，需要修改的部分就很少了。配置文件中的配置信息至少包含所使用的验证工具、验证工具的配置、需要验证的设计源码、用来验证的测试代码、验证结果的输出配置、验证时的出错处理和环境变量的配置等。由于需要配置的参数比较多，可以将上述配置文件分为几个，需要经常改动的放在一个文件，不需要经常改动的放在另一个文件。例如，可以将配置文件分成configuration和directory两个文件。configuration文件用于说明当前验证平台的构成情况；directory文件主要用于说明构成平台的模块信息。
　　同时，为了实现验证过程的快速配置，可以对上述两个配置文件提供一个模板。一方面，当验证一个设计时，只需要修改该模板中的部分变量，就可以进一步加速验证平台的建立；另一方面就使用模板为脚本提供了一个标准的接口，使验证过程的自动化实现成为可能。
　　(2)该验证平台的另一个特点是使用了参数化的设计思想，具体实现包括验证平台建立的参数化和验证过程的参数化。验证平台建立的参数化为建立验证平台提供了方便，如验证工程师可以通过配置参数很容易实现验证平台中各元件的增加和删除，也可以通过配置参数实现不同验证工具之间的切换等。验证过程的参数化是指验证工程师可以通过配置参数很容易地控制验证流程，进行各阶段的验证，从而提高验证速度。如通过配置参数实现RTL级源代码和RTL级验证代码的调用。对于验证平台中的环境变量、接口参数等需要经常使用而且又经常需要修改的变量，采用参数化的设计思想，其具体取值由验证工程师在配置文件中指定。
　　(3)基于总线的验证平台结构能够进一步提高该验证平台的可重用性。首先，在不同的IP单独验证时有很好的可重用性。如果两个不同的IP是基于同一总线的，第二个IP可以直接放在该验证平台中验证，而不需要修改驱动、系统服务、激励文件和脚本等。其次，这种基于总线的验证平台在验证SoC衍生产品时有很好的可重用性。因为这种系列产品所对应的总线是不变的，因此，监视器和总线报告器可以直接重用，如果设计得当，即使衍生产品的系统服务和驱动实现过程不一样，有同样或相似的接口和参数，激励和脚本也可以重用。
3.2 验证平台的可重用性分析
　　(1)在不同IP模块单独验证平台间可以有很高的可重用性。两个不同的IP块验证时，如果它们是基于同一总线的，验证第二块IP时，可以放在第一块IP的验证平台中直接验证。此时，是完全可重用的，而且可重用率达到100%；如果两块IP是基于不同的总线的，验证第二块IP时，只需修改总线功能模型，而对其中的激励、系统服务、驱动和监视器都不需做任何修改，五种基本元件只需修改一种，而可重用率仍可达到80%。如果将SoC中的处理器总线、系统总线和外设总线的总线功能模型全部设计好，以后的IP单独验证平台的设计就变成了仅仅是选择不同总线功能模型的过程。
　　(2)从IP模块单独验证平台到SoC系统验证平台的设计过程中具有很高的可重用性，监视器可以完全重用，但这需要在芯片逻辑综合时，将监视器所监视的内部信号保留。如果驱动的功能是产生芯片级管脚信号，驱动也可以重用。系统服务也可以被重用，两个验证自动化的过程不一定要同样地实现，但必须要有统一的接口。IP单独验证平台的激励可以完全重用于SoC系统验证平台的激励文件中。即只要设计合适，IP模块单独验证平台中的监视器、系统服务、激励可以被完全重用，驱动的可重用性则需要根据IP模块在SoC中所处的位置和所起的作用来决定，总线功能模型会被实际的总线所代替，五种基本元件中，至少有三种可被完全重用，可重用率至少可达60%。
　　(3)在不同的SoC系统验证平台中有很高的可重用性。本文所提出的验证平台结构是基于总线的。因此不同的SoC系统验证平台中的可重用性也取决于SoC本身所采用的总线。如果两个不同的SoC采用完全相同的总线，即它们具有完全相同的处理器总线、系统总线和外设总线，若设计和该设计的派生设计的验证平台，此时可达到验证平台的完全可重用，即可重用率为100%；如果两个不同的SoC采用完全不同的总线、在第二个SoC系统验证平台中则可以重用第一个SoC系统验证平台中的监视器、系统服务和激励，可重用率仍可达到60%。
4 实 验
　　实验元件选自合肥工业大学微电子设计研究所自主开发的系统芯片HGD2112和HGD3118，实验环境：Sun Solaris 8 操作系统，Pentium IV 1.7处理器，256MB内存，gcc编辑器，B shell脚本语言。该验证平台成功地验证了上述两个系统芯片。两个项目验证的实际开销和节约开销如表1所示。 由于HGD3118和HGD2112是两种不同的系统芯片，其验证平台相似性较少，但如果使用该验证平台来验证这两种系统芯片的衍生产品，其验证效率可以进一步提高。如果设计合理，验证平台的构建所占时间基本可以忽略，验证时间也仅为运行验证过程的时间。