1 芯片简介、验证计划及验证策略
1．1 芯片简介
    八通道串行通信控制器(以下称通信控制器)用于实现高级链路控制协议的高速串行通信。该芯片支持同步协议、异步协议、HDLC／SDLC等协议，可以在Intel总线模式和Motorola总线模式下使用，是为电信业务特别优化的串行通信控制器，广泛用于时分复用通信应用系统，如时分分组交换网络，局域网网关、网桥等。 
    该通信控制器的总体结构如图1所示，按照功能原理，其硬件结构可分为两个组成部分：总线接口和串行通道控制电路。总线接口包括16位数据总线(DO～D15)、9位地址总线(A0~A8)、控制输入信号、终端请求输出信号、直接内存存取(direct memory access，DMA)接口信号以及地址锁存允许(address latch enable，ALE)信号；串行通道控制电路包括8个相同的、独立的全双工串行接口(串行通道0～7)。每个通道又包括控制逻辑和接收发送FIFO。控制逻辑主要是波特率发生器(BRG)，数字锁相环(DPLL)，时隙分配电路(TSA)，协议控制电路，定时器和编解码电路等模块。同时，该通信控制器具有一个28位的可配置输入、输出全局端口(PA0-7，PB0-7，PC0-7，PDO-3)。

1．2 验证策略分析及验证计划制定
    该芯片的验证难点在于，通信控制器支持的协议多，功能复杂，各种划分方式以及功能的排列组合数量非常多。具体而言，通信控制器有8个通道，每个通道有32个8位配置寄存器，平均每个配置寄存器约有10种配置值，寄存器配置排列组合的数量更是惊人。
    针对上述难点，所采取的验证策略是，芯片的功能验证分类按数据传送协议将验证分为异步、同步、HDLC和并口四类，每一类按照总线接口又分为Intel总线和Motorola总线，再按照数据传送类型分为中断模式和DMA模式，基于该分类方法验证通信控制器的各项可配置功能，如CRC检验、奇偶校验、流量控制等。
    在验证层次上，由于组成通信控制器芯片的8个通道是独立的、相同的，故采取先在子系统级验证一个单通道的数据传送，继而再验证全芯片8个通道的数据传送的层次化验证方法，而如果每一个层次都需要构造一个测试平台，任务就非常复杂。本文采取在两个层次采用统一的验证环境的方法，从而降低了验证的复杂度，大大提高验证效率，缩短整个芯片的设计周期。开始验证之前首先需要制定一个完整的验证计划。验证计划的制定要针对设计中可能出现的问题，并涵盖设计要实现的所有功能。通信控制器需要验证各种数据传输操作和一些其他功能。表1列出了该通信控制器的部分验证计划，完整的验证计划远比表1庞大，限于篇幅在此不一一给出。

2 验证方案
2．1 采用总线功能模型构造验证平台
    总线功能模型(BFM)是近年在测试平台中广泛采用的一种能提高验证重用效率的激励生成方法。总线功能模型的作用是通过封装低层总线的时序，向高层提供一个调用接口。总线功能模型的构建有状态机和任务库两种方式。通信控制器的验证采用了任务库的方式来进行总线功能模型设计。采用模块的封装方式把内部操作的细节封装起来，通过“模块名，任务名”的方式复用模块，从而建立结构化的testbench。基于总线功能模型的验证环境如图2所示。

    验证环境的下层是BFM和通信控制器逻辑电路组成的物理层。在这一层，BFM与通信控制器的引脚连接，根据总线协议驱动总线信号，同时将这种驱动行为抽象成能够被上层调用的任务(task)。上层是testcase组成的测试层，testcase根据所验证的功能产生测试数据，通过调用下层提供的任务，将产生的测试数据激励输入到被测电路中并监测数据处理结果。可以看出，BFM通过对总线信号的时序进行抽象和封装，使测试环境有了层次化的结构特点。这种层次化的特点能提高测试环境的开发效率和可重用性，从而满足验证通信控制器的如下要求。
    首先，验证环境层次化的结构保证了在各个层次的验证模块开发可以同时进行，提高开发效率。BFM将通信控制器测试环境的开发强度和复杂程度分散到了物理层和测试层两个不同的抽象层。在物理层，BFM专注于实现Intel总线或者Motorola总线的各个时序操作；在测试层，testcase专注于针对通信控制器待验证的功能来设计测试向量。上层的testease和下层的BFM在定义了任务接口后，物理层和测试层的测试模块可以进行同时并行开发。其次，由于testease和BFM处于两个不同层次，所以可以在各自的层次上实现复用。处于上层的testcase，可以在后仿真阶段直接复用；而处于下层的BFM不仅可以复用在后仿真阶段，在引脚接口信号通信协议相类似的项目开发中亦可重用。

   验证平台总线功能模型中一个cpu写周期的

    在对某个设备的寄存器进行读操作时，譬如，向地址为ADDR的状态寄存器写入DATA数据，在testcase里调用该任务可以写成：

2．2 功能覆盖率
    功能验证的另一个关键问题是验证工作到什么程度，如何保证验证的充分性。对于通信控制器芯片，更关心的是功能覆盖率。功能覆盖率是衡量设计的原始要求实现程度的指标。
    通信控制器功能实现主要体现在寄存器的配置组合上。前面提到，所采取的验证策略是在单通道下分别在Intel总线和：Motorola总线接口按照数据传送协议为划分标准，将验证分为异步、同步和HDLC三大类，然后再按照数据传送类型，在中断方式和DMA方式下验证各个功能。最后再测试全通道的数据收发。通信控制器的每一个功能均有相应的testcase，配置寄存器的每一位都保证有翻转。按照验证计划，验证该通信控制器开发的testcase共计225个，通信控制器的全部功能均被覆盖。
    图3~6示例了几个testcase的仿真波形图。图3的testcase用来验证通信控制器Intel总线接口异步协议DMA传送模式下的数据传送，DWT(DMArequest transmit)是DMA传送请求信号，wrl和wr2是内部信号，当FIFO从数据总线上每成功读取8bit数据时，wrl或者wr2信号跳变一次，结果显示该testcase验证通过。图4是Motorola总线接口异步协议中断传送模式下数据传送的一个testcase，图5是Intel总线接口HDLC协议中断传送模式下数据传送的一个testease。与图3的分析相类似，波形显示这两个testcase验证通过。图6是验证28个全局并口发送数据的testease，波形显示四个并口先后发送数据55、66、77和F，该testease验证通过。

2．3 错误状态的验证
    对错误状态的验证是一个很重要的环节。在testease中，加入错误状态激励，观察输出结果是否符合预期。一些错误状态比较容易实现，如某个配置项赋定义以外的值，只需在配置文件相应行上填入错误状态配置值即可。再如很短的时间内发生了同一通道的两次配置(即配置覆盖)，这只需在配置文件中的同一配置时刻参数段加入相同通道的又一次配置即可。另外一些错误状态可以根据通信协议自行设定，如发送端和接收端配置的数据帧头同步字符不一致，接收时钟和发送时钟不同步等。
    图7是一个错误状态验证的testcase波形图。该testease是验证通信控制器在Intel总线接口，同步协议的中断方式传送模式下数据传送。发送端的同步帧设置为80，接收端的同步帧设置为8l。按照同步协议，同步帧不一样，接收端的数据不能写入FIFO。如所预期，wrl和wr2未发生跳变，表明发送数据没有被接收。

2．4 后仿真与样片测试
    在实际电路中，信号的跳变不是瞬间完成的，而是具有一定的时延。功能验证主要是验证电路的逻辑功能，信号的跳变是瞬间完成的，因此只能在功能上证明设计的正确性，而无法证明在实际电路中逻辑功能依然正确。后仿真是对版图提取了寄生参数以后考虑了互联延迟进行的仿真。验证在引入实际时延之后系统功能是否正确。
    构建后仿真环境的思想与构建前仿真的思想基本相同。在功能验证过程使用结构化和逐层抽象的方法来设计验证环境，因此在后仿真的过程中可以复用前仿真的环境，测试用例也可以直接复用到后仿真的过程中。图8是后仿真的一个波形。

    采用上面介绍的验证方案，作者成功地对八通道多协议串行通信控制器芯片进行了功能验证，该芯片已成功流片并进行了样片测试。将功能验证时各testcase芯片每个管脚的输入以及相应的输出转化为测试码输入测试机，验证对于相同的输入，芯片的实际输出与功能验证时的输出是否相符。测试码按照测试机的要求有一定的格式给出了一行测试码。芯片目前也通过了样片测试并已经实际应用。

3 结语
    大规模集成电路的验证是一项非常复杂的任务，使用总线功能模型构建可复用的验证平台能够提高集成电路的验证效率，缩短产品开发周期。本文采用总线功能模型实现了一款八通道多协议串行通信控制器芯片的功能验证，相信这种方法对相关领域的设计验证具有一定的参考价值。