用RTL测试平台验证事务级IP模型

来验证较低抽象级别的IP模型(这就是所谓的自上向下兼容性)，反之则不行。然而事实上，在重用RTL测试平台来验证TLM级IP时所采用的正是与之相反的自下向上兼容的测试平台。

在 验证IP之前，设计工程师必须清楚这个IP是如何使用的，并应知道一个高质量的测试应包含些什么内容。也就是说，高质量的测试应该充分全面。从这个角度上 看，TLM模块必须满足这样的要求：运行于该模块上的软件应该也能运行在RTL级的模型上以及真正的系统中。只有这样，设计工程师才能肯定TLM模型和 RTL模型是匹配的。要确保这一点，有一种方法，即在TLM IP上运行RTL测试平台。

在采用RTL测试平台来验证TLM

IP时有两个主要问题需要解决，一是TLM模型和RTL模型采用的语言不同，二是这两种模型的抽象级别不同。至少有两种技术可以解决这两个问题。利用同样的技术还可以实现用TLM测试平台验证RTL模型，但这样做意义不大。

重用RTL测试平台来验证TLM模块

可实现利用RTL测试平台验证一个TLM模块的第一种技术就是将RTL模型用作一个"黄金"参考(即非常好的参考)，见图2。这时，如果RTL模型和TLM模型的功能相当，那么对这两种模型采用同样的激励就能在事务级上获得完全相同的响应。

采 用这种方法时，首先要将被仿真的RTL模型对某一早先开发好的测试平台的响应在模型接口处取出，以记录下事件序列。接着，将这些序列转换成事务和事件，并 将其与TLM接受同样的输入时获得的输出进行比较。例如，对总线信号而言，设计工程师可以开发一种基于有限状态机的工具，将总线控制信号转换成符合总线协 议的TLM读写事务。中断等类似信号也可以转换为事务级的事件。

设计工程师可以采用一种脚本语言，从这些事务和事件中开发出一个SystemC生成器或测试平台，以激活SystemC API(应用程序接口)信号。然后就可以将SystemC TLM的输出与RTL模型所驱动的输出序列相比较。

下 面我们以一个时序器模型为例，该模型连接到ARM公司的AMBA片上总线。第一步是在时序器的RTL模型上运行HDL(硬件描述语言)测试平台，然后用一 个分析工具来构成时序器接口的总线信号和中断。分析工具可由TestBuilder构成，该工具能够提取出HDL形式的信号，并将其转化为C++格式。一 旦信号变成了C++格式，其值也被有限状态机代码修改为AMBA总线事务并被记录下来。发生了变化的中断信号值也被记录下来。其中，特别是在一次读写事务 的过程中发生的中断，在这次事务之后都会被记录下来。

以下样本文件给出了被存储下来的一系列事务和事件，也即一系列读写操作 和中断操作(见列表1)。该文件通过脚本语言被转化为一个SystemC测试平台(见列表2)。例如，对于读写事务而言，脚本分别向RTL测试平台和 TLM测试平台的同样地址读、写数据，然后将TLM测试平台得到的结果与HDL的值进行比较。如果这些结果和所有的中断均能吻合，那么该TLM模型就通过 了测试。

TLM中存在的问题

然而，即使TLM是正确的，由一个中断引起的值的变 化也可能与TLM接口上的值的变化不一致。这时就必须进行人工检查。以时序器为例，设计工程师可能发现在HDL模型中，一次中断发生在10次读操作之后， 而在TLM模型中，该中断则要么过早出现，要么过晚出现。问题就在于TLM缺乏RTL模型所具备的高度精确的时序。很显然，任何检查软件都会把这种情况当 作出错，然后进行人工分析，结果却发现TLM模块事实上工作正确。

再举一例，如果在一次TLM事务中的数据读操作与RTL级的操作不匹配，原因仍然很可能是TLM缺乏精确时序，但这并不意味着TLM模型有毛病。只要TLM的中断时序不精确，而HDL模型在工作时只要不发生中断就保持连续读操作，那么时序不匹配就总是一个问题。

在 输入为非关联情况下，读、写序列不匹配的情况也可能发生。例如，假设在RTL模型中，几个写操作向寄存器写值，其中的第一个操作在10个周期后会产生一个 独特的输出X，并假设在X被记录下来之前的这10个周期中，又发生了向其他寄存器读和写的操作。而在TLM模型中，输出X可以立即被记录，这样，表面上看 来，TLM模型又出错了。

以上的每种情况出现时，都需要人工来研究和解决问题，这就使验证所需付出的代价和成本增大。在 ARM时序器一例中，用RTL测试平台验证大约需要5天人工时间。表1列出了用RTL测试平台验证其他采用了TLM的ARM功能块(ARM将其称作 PrimeCells)时所需的工作量。

有时，RTL测试平台也许并不适用于验证TLM模块。时序测试平台就是其中的一例， 该平台的测试重点是