下面是对图2所示的事务处理进行建模的一个简单代码段。这个类的旨在于将事务处理数据记录到作为trans_db instance dump_file类的事务处理数据库中。输出被显示在图3最右部分。

// Inside program or some other OpenVera context

trans_db dump_file;

trans_stream stream1;

trans_type mem_read;

trans_handle h1;

// open a database file

dump_file=new("test");

// create the memory stream under the test.duv.bus scope

stream1=new(dump_file, "test.duv.bus", "memory");

// create the read transaction type in the memory stream

mem_read=new(stream1, "Read");

// define 2 attributes in the read transaction type

mem_read.create_attr("Addr", INTEGER_DT);

mem_read.create_attr("Data", INTEGER_DT);

delay(10);

// begin a memory read transaction at 10

h1=mem_read.begin_now();

h1.log_integer_attr("Addr", 170);

h1.log_integer_attr("Data", 123);

delay(20);

// end h1 transaction at 20

h1.end_now();

// close the database file

dump_file.close();

当 然，正如前面针对SCV所提到的，另一个有用的类是trans_relation，它负责不同事务处理之间的关系。下面的代码段显示出当 trans_relation为单向时，类是被怎样运用的。一个分析与可视化工具也可以具备预先定义的关系以便获得对分析和显示的特定表示。

trans_relation r1;

trans_relation r2;

trans_handle h1;

trans_handle h2;

r1=new(f, "parent");

r2=new(f, "child");

...h1.add_relation(r1, h2); // h2 is the parent of h1

h2.add_relation(r2, h1); // h1 is the child of h2

    为实现记录，类必须封装事务处理追踪和记录API，使数据库记录细节对用户而言不可见。API必须是开放的，以便在工程师和供应商等人之间培养出一种公共增 值文化。在创建、生成和记录事务处理时，它也必须经受得起跨语言应用的检验，从而给设计工程师一个高价值工具。而且它必须简单、基本，但是要足够宽泛以便 覆盖事务处理记录的基本要素。为获得某些(特定建模语言)具体功能，可以另外在封装之上再建立API。

    程序员们开发出了一种被为“开放的 事务处理接口(OTI)”的API。这是在Novas公司的FSDB writer层之上构建的一层。该API用C语言编写以获得高可便携性。事实上前面列出的那些类都是OpenVera事务处理类函数库的一部分。它们构成 了对OTI的封装并且利用DirectC与OpenVera接口。用户可以从任何地方利用DirectC编码直接调用OTI。但总的来说，提供一个将建模 语言的接口要求隐藏起来的OTI封装是一个好主意，这样用户就可以专注于建模而忽略数据库记录的细节。

与OTI相似的APIs可以很容易 地使设计工程师能够采用能与C语言接口的语言来开发并记录事务处理数据。这包括其它流行的硬件验证语言，例如e语言。事实上，通过恰当的封装系统任务以及 软件C/C++代码，API也可以在硬件描述语言中使用以直接将事务处理数据从实现中卸载出去。图4是一个带有所有这些模块的系统。

     SystemVerilog(3.1a版)(www.systemverilog.org) 是新型的设计建模与测试台语言。它目前没有如SystemC里的内置事务处理类别，但是它存在的目的就是将Verilo电路和寄存器数据抽象化并封装至更 有意义的分组数据中。这使得我们有必要看看如何才能建模然后记录事务处理数据。事实上，可以采用多种方法在SystemVerilog实现这一点：a)等 待增添内置类的标准化努力。这也许会最终发生，不过SystemVerilog今天就可以达到这一目的。因此何必还要等待概念产生然后再期待供应商去支持 它呢？b)创建你自己的事务处理类和方法(任务和功能)，然后也许再将其作为一个可分享的函数库捐赠给业界。c)透过直接编程接口(DPI)或编程语言接 口来与SystemC集成。d)在建模过程中调用“系统任务”在恰当的地方完成。

    我们认为选项(d)是设计工程师的一个很好的出发点。它囊括了众多的接口要求并且以一种简单、直接而且相当弹性的方式完成任务。设计工程师们可以透过编程语言接口，或者最好透过直接编程接口(DPI)来调用SystemVerilog “任务”或C/C++例行程序。就像DirectC一样，DPI这种机制是被设计用于简单地与用C或C++语言编写的外部无时序模块进行接口。

    因此这就产生了两个问题。事务处理对象是什么？设计工程师们该怎样创建/生成/记录事务处理并开发API？同样，我们的答案就是API工具，如图3所示的OTI。它可隐藏执行细节并且为事务处理记录提供一个健全而完整的基础。

需要更多的自动化

    到目前为止所讨论的事务处理记录是相当有用、高效的。可是实际上它仍然是人工的，更确切地说，用户必须执行事务处理建模并求助于数据库记录。随着标准越来越成熟以及工具供应商联合起来，业界构可以开发额外的自动化生成和记录工具。例如，用户已经可以在Vera RVM中(同样的，在e语言中)用事务处理类生成事务处理。因此，即将到来的自动化将在创建时使用这些回叫工具，这样用户就用不着担心为事务处理分开建模了。他们可以扩展所提供的基本类，并自动获得所需的记录功能。

    另外，我们发现SoC通常含有许多模块，包括专利IP，用于设计与验证的建模语言也相当的多(如图3所示)。因此，一个完整的SoC就形成一个难以破解的数 据集合。在这种情况下，如果工程师采用某种方法将事务处理从可获得的数据里提取出来，从而更好地理解系统运行的话就再好不过了。建模、验证与调试需要统一 标准的符号和框架，以便架构师和设计工程师合力进行复杂SoC的设计与开发。TLM是进行这种分析的理想模型。设计工程师们应该更加深入地研究事务处理级 建模的细节，并利用事务处理级建模从高效率协同仿真和高产出的分析与调试中获得最大好处。