消息驱动测试平台可以改善测试覆盖率

传统的测试平台实现只能按顺序设置工作参数，无法动态响应被测设备的要求。因此这种测试方法会遗漏软件和硬件之间的某些复杂时序交互。随着FPGA功能的逐渐强大，软件和FPGA之间的交互信息量也在不断增加。本文讨论的以消息驱动的测试平台能够模拟FPGA实际运行环境对FPGA进行仿真测试。该方法除了能为测试平台所要求的物理接口模型建模外，还能对控制FPGA的部分软件进行建模。因此允许人们在测试平台和FPGA之间建立动态交互渠道，从而改善FPGA的测试覆盖率。

测试平台应该真实反映FPGA在实际硬件环境中的工作状况。以前也经常出现仿真通过了但在实际在线使用时FPGA出故障的情况。

有时很容易找出故障原因，有时则很难。一旦找到问题的症结我们会扪心自问："为什么不早点发现这个问题呢？"很多时候这些问 题发生在软件和硬件之间的灰色区域。在仿真FPGA时我们应该在何处下手呢？如果我们忽略软件是如果使用FPGA的，那么我们以后肯定能找出问题的原因。 因此不受硬件的约束、积极吸收一些软件功能才是明智不举。这样做有以下一些优点：

1. 由于覆盖了一部分硬件与软件之间的灰色区域，测试覆盖率可以得到改善。

2. 能够更好地理解软硬件的交互以前二者之间的交互时序。

3. 能够部分验证FPGA的控制算法。

我们如何设计这种测试平台呢？

在FPGA和处理器系统中，软件设置好FPGA寄存器后就可以与FPGA进行交互通信了。这种测试平台可以同时满足这二种情况。不过后者令人更有兴趣，也更难一些。让我们考虑一下如图1所示的系统，它的FPGA内部有一个处理器接口和二个UART。

FPGA内部的这些模块通过内部总线连接在一起。为了控制UART，外部微处理器需要通过处理器接口和FPGA内部总线访问 UART内部的寄存器。波特率、奇偶校验等UART参数必须由软件先行初始化设置。在工作期间，软件在访问数据寄存器之前必须查询UART状态寄存器或等 待中断，否则数据寄存器的内容可能是无效的。

测试平台部分由三个测试模块组成，其中有二个测试模块与UART接口，另一个与FPGA处理器接口相接。必须配置好测试模块，以确保UART测试模块的工作参数和UART工作参数相同。

为了仿真通过UART给UART测试模块发送数据的工作过程，需要二次循环。每次循环都要检查UART的状态寄存器，当状态 寄存器指示允许写入时再向发送数据寄存器写入数据。这二次循环需要在处理器测试模块中完成，因为只有一个VHDL进程可以驱动FPGA处理器接口信号。

这种方法对简单案例很有效，但随着处理器测试模块中测试模块的增多，这种方法将变得越来越复杂。另外，因为需要比较从FPGA UART发送到UART测试模块的数据，仍然需要在模块之间建立一定的通信机制。

由于已经对硬件和部分软件作了建模，因此可以研究一下软件在系统中是如何工作的，从而帮助我们作出正确的比较结果。

首先我们需要构筑能够匹配FPGA功能的软件，以便我们拥有能够管理每个FPGA模块的软件任务。该软件任务可以作为这种模 块的设备驱动器。参考高级操作系统提供的功能，软件任务之间的通信可以通过消息管道和信号机实现。在VHDL中可以使用相同的结构。软件任务类似于 VHDL进程。虽然不象C等高级语言那样方便，但还是可以创建消息队列的。利用信号可以很简单地构建信号机，然后依靠接收进程等待这一信号的变化。至此我 们就具备了用VHDL创建软件驱动器的所有条件。

那么这样一种测试平台的结构是怎样的呢？图2是测试平台内部消息流程的一个简单例子。

命令是由命令解析器从脚本文件中读取的。以命令解析器为目的的命令在本地得到处理，而其它消息发送到相应的模块。脚本命令被 转换成标准消息格式。这种消息格式一般由一条记录组成，该记录包含消息目的地、消息源、消息类型和数据阵列指针等字段。消息送到目的地后再进行进一步处 理。

目标模块不断查询消息队列是否有输入消息。当有消息到达时，它会检查消息类型并决定如何处理该消息。一般用case语句区 分不同的命令。在每个case语句中，可以立即执行命令(比如希望用一些数据填充某些RAM的情形)，也可以通过激发被某个进程监视的脉冲信号触发并启动 这个进程。

值得注意的是我们可以从测试平台中的任何模块向其它任何模块发送消息。因为有这样的反馈路径，因此能够构建查询循环。图3 给出了UART测试模块的结构。

模块被分成三大部分：物理接口、软件接口和本地数据存储模块。

物理接口用来管理与FP