建模、驗證與調試需要統(tǒng)一標準的符號和框架，以便使架構師和設計工程師能夠協(xié)同進行復雜SoC的開發(fā)。事務處理級模型(TLM)是進行這種分析的理想模型，在片上系統(tǒng)(SoC)設計中使用事務處理級建模，可讓設計從高效率協(xié)同仿真和高產(chǎn)出的分析與調試中受益。

下面是對圖2所示的事務處理進行建模的一個簡單代碼段。這個類的旨在于將事務處理數(shù)據(jù)記錄到作為trans_db instance dump_file類的事務處理數(shù)據(jù)庫中。輸出被顯示在圖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

為實現(xiàn)記錄，類必須封裝事務處理追蹤和記錄API，使數(shù)據(jù)庫記錄細節(jié)對用戶而言不可見。API必須是開放的，以便在工程師和供應商等人之間培養(yǎng)出一種公共增 值文化。在創(chuàng)建、生成和記錄事務處理時，它也必須經(jīng)受得起跨語言應用的檢驗，從而給設計工程師一個高價值工具。而且它必須簡單、基本，但是要足夠寬泛以便 覆蓋事務處理記錄的基本要素。為獲得某些(特定建模語言)具體功能，可以另外在封裝之上再建立API。

程序員們開發(fā)出了一種被為“開放的 事務處理接口(OTI)”的API。這是在Novas公司的FSDB writer層之上構建的一層。該API用C語言編寫以獲得高可便攜性。事實上前面列出的那些類都是OpenVera事務處理類函數(shù)庫的一部分。它們構成 了對OTI的封裝并且利用DirectC與OpenVera接口。用戶可以從任何地方利用DirectC編碼直接調用OTI。但總的來說，提供一個將建模 語言的接口要求隱藏起來的OTI封裝是一個好主意，這樣用戶就可以專注于建模而忽略數(shù)據(jù)庫記錄的細節(jié)。

與OTI相似的APIs可以很容易 地使設計工程師能夠采用能與C語言接口的語言來開發(fā)并記錄事務處理數(shù)據(jù)。這包括其它流行的硬件驗證語言，例如e語言。事實上，通過恰當?shù)姆庋b系統(tǒng)任務以及 軟件C/C++代碼，API也可以在硬件描述語言中使用以直接將事務處理數(shù)據(jù)從實現(xiàn)中卸載出去。圖4是一個帶有所有這些模塊的系統(tǒng)。

SystemVerilog(3.1a版)(www.systemverilog.org) 是新型的設計建模與測試臺語言。它目前沒有如SystemC里的內置事務處理類別，但是它存在的目的就是將Verilo電路和寄存器數(shù)據(jù)抽象化并封裝至更 有意義的分組數(shù)據(jù)中。這使得我們有必要看看如何才能建模然后記錄事務處理數(shù)據(jù)。事實上，可以采用多種方法在SystemVerilog實現(xiàn)這一點：a)等 待增添內置類的標準化努力。這也許會最終發(fā)生，不過SystemVerilog今天就可以達到這一目的。因此何必還要等待概念產(chǎn)生然后再期待供應商去支持 它呢？b)創(chuàng)建你自己的事務處理類和方法(任務和功能)，然后也許再將其作為一個可分享的函數(shù)庫捐贈給業(yè)界。c)透過直接編程接口(DPI)或編程語言接 口來與SystemC集成。d)在建模過程中調用“系統(tǒng)任務”在恰當?shù)牡胤酵瓿伞?/p>

我們認為選項(d)是設計工程師的一個很好的出發(fā)點。它囊括了眾多的接口要求并且以一種簡單、直接而且相當彈性的方式完成任務。設計工程師們可以透過編程語言接口，或者最好透過直接編程接口(DPI)來調用SystemVerilog “任務”或C/C++例行程序。就像DirectC一樣，DPI這種機制是被設計用于簡單地與用C或C++語言編寫的外部無時序模塊進行接口。

因此這就產(chǎn)生了兩個問題。事務處理對象是什么？設計工程師們該怎樣創(chuàng)建/生成/記錄事務處理并開發(fā)API？同樣，我們的答案就是API工具，如圖3所示的OTI。它可隱藏執(zhí)行細節(jié)并且為事務處理記錄提供一個健全而完整的基礎。

需要更多的自動化

到目前為止所討論的事務處理記錄是相當有用、高效的。可是實際上它仍然是人工的，更確切地說，用戶必須執(zhí)行事務處理建模并求助于數(shù)據(jù)庫記錄。隨著標準越來越成熟以及工具供應商聯(lián)合起來，業(yè)界構可以開發(fā)額外的自動化生成和記錄工具。例如，用戶已經(jīng)可以在Vera RVM中(同樣的，在e語言中)用事務處理類生成事務處理。因此，即將到來的自動化將在創(chuàng)建時使用這些回叫工具，這樣用戶就用不著擔心為事務處理分開建模了。他們可以擴展所提供的基本類，并自動獲得所需的記錄功能。

另外，我們發(fā)現(xiàn)SoC通常含有許多模塊，包括專利IP，用于設計與驗證的建模語言也相當?shù)亩?如圖3所示)。因此，一個完整的SoC就形成一個難以破解的數(shù) 據(jù)集合。在這種情況下，如果工程師采用某種方法將事務處理從可獲得的數(shù)據(jù)里提取出來，從而更好地理解系統(tǒng)運行的話就再好不過了。建模、驗證與調試需要統(tǒng)一 標準的符號和框架，以便架構師和設計工程師合力進行復雜SoC的設計與開發(fā)。TLM是進行這種分析的理想模型。設計工程師們應該更加深入地研究事務處理級 建模的細節(jié)，并利用事務處理級建模從高效率協(xié)同仿真和高產(chǎn)出的分析與調試中獲得最大好處。