下面是對圖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是進行這種分析的理想模型。設計工程師們應該更加深入地研究事務處理級 建模的細節，并利用事務處理級建模從高效率協同仿真和高產出的分析與調試中獲得最大好處。