在对某个设备的寄存器进行读操作时，譬如，向地址为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 结语
    大规模集成电路的验证是一项非常复杂的任务，使用总线功能模型构建可复用的验证平台能够提高集成电路的验证效率，缩短产品开发周期。本文采用总线功能模型实现了一款八通道多协议串行通信控制器芯片的功能验证，相信这种方法对相关领域的设计验证具有一定的参考价值。