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

在系统级芯片设计中，设计验证是一项十分重要的工作。传统的验证方法虽然比较简单，但对设计工程师要求很高，而且验证时间过长。本文介绍开放式设计和验证语言SystemC，通过该语言可实现RTL测试平台的复用，降低验证成本，缩短验证时间。

由于缺乏可靠的结构评估方法和软、硬件协同验证方法，系统结构设计工程师在设计系统级芯片(SoC)时，工作受到了一定的阻碍。值得庆幸的是，SystemC这种标准的用C++开发的资源开放式设计和验证语言，为研究不同的系统结构，进行算法评估，软、硬件任务划分和软件开发提供了有效的方法。

SystemC之所以能实现这些功能，原因就在于它简化了事务级模型(transaction level model, TLM) 的开发。与寄存器传输级(RTL)模型比较而言，TLM属于系统硬件组件在更高级别上的抽象。RTL模型中包含了比TLM模型更多的细节信息(如单独的时钟周期等)，而TLM则在结构级的组件上交换数据或执行事件。简言之，TLM所针对的应用是开发和验证那些依赖于硬件的系统软件部分。

TLM优于RTL模型的地方包括：

1. TLM比RTL更容易开发，需要消耗的人工时间也较少，并且仿真速度也比RTL模型快1万到10万倍；

2. TLM仿真所需耗费的时间只在秒级和分钟级，而RTL则需耗费几小时甚至几天的时间。因此，在一个TLM级的IP模块上可以真正运行软件，而RTL IP则速度过慢，即使在一个指令级仿真器中也无法执行代码。同时，SoC的设计方法学要求将过去设计的知识产权(IP)在更高的抽象级别上表现出来，从这个角度来看，TLM也是很有用的。

如果工程师们能够利用现有的RTL测试平台来验证TLM，那么还能进一步缩短TLM的验证时间。事实上，SoC设计验证时间占据了整个产品开发过程的60％到70％，而且也是一次性工程成本中的重要组成部分。所谓一次性工程成本，包括开发测试平台所需的人工时间加上所有其他验证工具所需的时间。

此外，如果验证一个基于TLM的IP模块时所采用的测试平台也曾用来验证过该模块的RTL模型，那么设计工程师们也就更容易对该模块产生信心。这种信心又会促进TLM在设计流程中的应用，从而帮助缩短早期SoC设计和其后的 RTL设计之间的差距。今后，在重新利用RTL测试平台来验证TLM模块这个领域内，研究重点将放在如何使该过程全面自动执行，以及如何将自动检错功能包含进来。

有几种工具可用来缩短验证HDL模型所需的时间，其中包括Verisity Design公司的Specman Elite、Design Systems公司的开放式源码程序TestBuilder以及Synopsys公司的VERA。然而就像开放式SystemC验证库最初所经历的一样，针对SystemC设计的验证工具也才刚刚起步，还需要一段时间才能成熟，这也使RTL测试平台的重用问题更加引人瞩目。

传统的验证方法

        在不同的HDL专用工具间可能会存在差异，但除此以外，传统的设计验证方法无非都是将设计与一个激励生成器和检测器连接起来达到验证的目的。其中，激励生成器用于启动线程，向设计中写入信号，而检测器则用于验证系统的响应。此外，在激励生成器实现文件的顶部所声明的事件结构用于综合不同的线程(见图1)。

这种验证方法的好处在于：开发与验证所用的是同一种语言，因此学习过程较为简单；小型的专用测试程序较易编写；并且无需额外的验证工具，这也降低了成本。而且，测试平台开发成功之后，尽管比较简单，仍然可以用作真实系统软件的例子，让嵌入式软件设计工程师在起步时从中获益。这种验证方法的缺点在于，要编写这种测试平台使其能够作为最终软件的基础，需要设计工程师全面了解整个系统的工作原理。

想要为较重要的IP模块开发出详尽的测试平台必须付出大量的努力、时间和金钱，而且，即便如此，也很难知道开发出的测试平台是否能够全面地测试一个模块。采用硬件验证工具(如Specman、 TestBuilder和 VERA)可以使部分验证过程自动执行，但并不意味着设计工程师可以少作努力，设计成本也依然高昂。

还有一种验证方法，即编写一种叫做集成测试平台的软件，以实现在整个系统中检测IP。这种方法要求所有的IP模型均为可用，但它有一个好处，那就是IP可以在全系统的上下文环境下进行验证，从而保证了模块能够确实按照设计的要求工作。

这些技术在开发类似TLM的IP模型时都是必须的。但如果采用验证RTL时所使用的测试平台来验证TLM模块，那么还能进一步节省验证时间。这种测试平台的“复用”通常发生在设计流程的RTL到布线阶段。

一般而言，某一抽象级别上的测试平台可以用来验证较低抽象级别的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模块。时序测试平台就是其中的一例，该平台的测试重点是时序条件，而非功能性。但这类测试平台却能用来校正时序的TLM。此外，那些测试通信协议(包括总线协议和握手协议)的测试平台也不适用于测试TLM模型。因为协议测试这类操作对于TLM而言级别太低，TLM无法对读、写操作的协议建模。另外，那些结果中会产生“don't care”状态的测试平台也不适用于测试TLM。

总之，这种重用RTL测试平台的方法保证了TLM模块在给定一个输入时，能够得到与RTL模型相同的输出。如果在验证RTL模型时所用的输入已经非常全面，那么只要一个SystemC TLM能够产生与RTL模型同样的输出，那么我们就可以认为二者具备同样的功能。而且，虽然并非所有RTL测试平台均适用于TLM，但大多数都可以在 TLM上重用，因此开发成本也降到了最低。

关于该方法的缺点，此前已有论述，那就是TLM模型和RTL模型之间可能出现的时序失配，出现这种情况时需要一定的人工工作量。此外，脚本及其他用于将 RTL信号转化为事务的软件，在用于具备非标准接口的IP模型时，都应作出相应改动。值得庆幸的是，事实上 SoC设计中的大多数接口都是标准的总线类型。

另一种可供选择的方法

重用RTL 测试平台来验证TLM模块的另一种技术，就是采用一种允许混合语言仿真的工具，对SystemC模型和HDL模型进行协同仿真。该方法最主要的优势就在于，它无需首先在RTL模型上运行激励，然后再用脚本将结果转化为SystemC测试平台。然而，采用协同仿真来实现向更高抽象级别转化的做法也并非毫无价值。

协同仿真采用了一种叫做包装(wrapper)的SystemC模块，该模块可以将总线信号转换为TLM读写事务。而中断等其他系统信号则可以通过SystemC信号与TLM模块直接相连。但这时会产生一个问题，因为大多数RTL测试平台都考虑了时序因素，因而它们就希望TLM模块能够在一个给定的时间内对输入信号作出响应，否则就宣告测试失败。所以我们要么必须修改RTL测试平台，使其忽略时序因素，要么必须修改 TLM和RTL接口，将二者调整为具备相同的时序因素。

RTL和TLM的协同仿真除了能够验证TLM模块以外，还能胜任几项 其他的任务。例如，SystemC TLM就能用作验证RTL模型的测试平台。但由于SystemC测试平台缺乏RTL模型的时序精度，所以它只能设计来检查事件的功能是否完成，而不能用来检查事件的时序。

另外，RTL和TLM协同仿真还能用于测试整个SoC平台的嵌入式软件，即使并非所有的TLM模块都已就绪。设计工程师可以采用这种方法来编写嵌入式软件中需要硬件时序信息的那部分。但由于仿真RTL需要很长时间，所以此项技术存在局限性。但随着代码长度向短小精炼发展，该技术的应用价值也越来越高。