對系統單晶片（SoC）設計而言，能儘早在設計流程中得到可執行的平台模組是很重要的[3]。目前的作法是根據硬體描述語言平台模組的接腳（pin connection），這種方式受限於三個主要的問題：

在處理層級將系統單晶片平台模組化可以解決以上這些限制。處理層模組（TLM）是一種模擬數位系統的高階處理方式，其內部詳細的訊號傳輸方式與功能單元或通訊架構的詳細建構分隔開來。訊號處理的需求藉由呼叫包覆低階訊息交換細節的通道模組功能介面來達成。訊號處理層介面則專注在資料轉換的功能性，而非它的架構。

隨著SystemC 2.0的出現，它使得在暫存器轉換層（RTL）之上，利用完美定義與標準模式來模擬系統模組的方式成為可能。SystemC是一種C++類別資料庫，用來立即建造準確時脈週期的模組、硬體架構、系統單晶片的軟體與介面。較早的SystemC版本為設計架構的合成引進模組單元、輸出入埠與訊號，以及利用程序來指定同時發生的行為。SystemC 2.0 為訊號傳輸與同步的廣義模組加入一組新的特殊功能；這些功能是通道（channels）、介面（interfaces）與事件（events）。

通道是用來作為訊號傳輸與同步的包容物，建立一個或多個介面，一個介面表示在通道中所建立的一組存取方式，但介面本身不提供建構方式。介面方式呼叫（IMC）定義通道上模組單元間的訊號傳輸，通道連接模組單元的輸出入埠，而模組可藉由輸出入埠存取通道。事件是一種有彈性、低階同步的基礎，用來構成其它形式的同步行為。藉由等待與動態感應相關聯（所組合而成）的事件，具有暫時改變程序感應（起動狀態）的能力。

SystemC 2.0能夠創造使用者所定義的通道與介面，使用者定義通道能被用來建立成為具有存取其它通道架構的模組。相較之下，基礎通道沒有可觀察的架構，以及沒有能力存取其它的通道。SpecC 定義類似的架構[1]，但私有語言缺乏SystemC／C++的物件導向方式，例如運算子溢載（overflow），與不支援訊號接腳層（pin-level）模擬。

SystemC 2.0 可以在訊號處理層建立高效能平台模組。高效能是因為模組容易發展且易於使用，時序與非時序功能模組，以及模擬低階模組的整合變得容易，因此在設計發展過程的初期就能夠產生可執行平台模組。

TLM模組可快速地執行

相較於訊號接腳層平台模組，模擬的加速來自於抽象概念的適當使用，而不是藉由使用C++或SystemC。抽象概念的適當應用表示摘取造成設計複雜化及降低模擬速度等不相關的訊息，同時保留相關訊息資料。在我們的例子當中，我們藉由使用抽象介面增加模擬速度，利用IMC結構，而非操作多數的訊號接腳。另外藉由使用區塊介面方式的動態感應，也可以避免多餘的處理程序活動，進而增快模擬的速度，

為了在系統背景下藉由附加偵錯裝置在以SystemC 覆蓋的主控處理器頂層，偵錯軟體利用使用介面建立的直接介面達成這個目的。這樣的設定不需要複雜的硬體／軟體協同驗證設定。

先前提到的一些問題，已經從其他地方獲得解決了。相較於訊號接腳基礎介面的方式，訊號處理層的抽象模組有較快的模擬速度，它同時也加速建立模組的過程[3]。ClassMate[4] 提供建立模組時所需類別的C++環境。其中所討論到的測試輸入組以類似平行的方式執行，卻並不能確保與時脈準確同步。而在硬體描述語言的環境下，模組模擬能夠與時脈準確同步且同相。但因為是屬於訊號接腳層的模組，它的內容資料詳盡且模擬速度很慢。最重要的是，發展詳細複雜的模組很花時間，以及用來偵錯硬體描述語言內容的軟體非常地複雜。

訊號處理層匯流排模組

訊號處理層模組乃用於模擬模組與匯流排間資料的傳遞。在這種抽象層級下，只描述傳輸資料的重要部份，排除其餘不相關的細節。這些細節資料將於稍後描述訊號接腳層傳輸時再來補充說明。抽象描述也因此加速模擬速度，並且仍舊是時脈準確同步。

典型地，匯流排建立許多主從介面間的訊息傳遞。匯流排從主控端（master）傳送資料到受控端，也從受控端傳送資料到主控端。主控端觸發資料傳遞的開始。主控端可以對受控端點讀／寫資料。利用地址資料可以明確地指定受控端的位置為何。當一個主控端取得匯流排的存取權，其餘使用匯流排的需求就會進入排序。為了緊接而來的使用需求，主控端點可以發出“鎖定”訊號以保留匯流排的使用權。在此註明，這些特性會應用在這篇論文所描述的簡易匯流排測試裝置。

主控端的讀或寫呼叫將啟動資料傳輸的開始。呼叫參數為傳遞資料與目標地址。匯流排依照請求地址選擇受控端點，將讀／寫呼叫傳送給它。受控端可能需要數個時脈來完成這個工作；每一個時脈匯流排都需要檢查呼叫狀態，直到匯流排能夠“示意”到主控端所發的需求訊息已經結束。同時，匯流排將新到的使用需求放置到排序序列當中。

當數個主控端發出匯流排使用需求時，仲裁裝置將選擇一個需求，而將其它的需求置放到排序序列當中。使用需求依照它們的優先順序來執行，也就是有最高優先權的需求最先被執行。每一個主控端有它自己唯一的優先順序。

訊號處理層功能呼叫描述了模組與匯流排間的介面。主控介面（master interface）定義了主控端與匯流排間的資料傳遞，而受控介面（slave interface）則定義受控端與匯流排間的資料傳遞。

簡易匯流排的建立

所謂的簡易匯流排，是建立成為階層式（hierarchical）SystemC的通道。受控端與仲裁者也建立成為階層式（hierarchical）SystemC通道。主控端有接腳可以連接到匯流排介面。匯流排以受控多重接腳連接受控端點，詳見(圖二)。

《圖一　訊號接腳與介面符號》

我們使用特殊的符號代表訊號接腳與介面，如同(圖一)所示，主控端M連接到匯流排。接腳符號包含兩個箭頭，分別指向左，右，而介面符號則有回饋箭頭。訊號傳輸開始於主控端（右箭頭）藉由訊號接腳連接到匯流排介面，從事功能呼叫。控制訊號以回饋箭頭及主控端接腳的左箭頭返回主控端。

《圖二　簡易匯流排圖式》

每一個主控端包含一個於特定時間區隔內在指定地址讀／寫一些資料，而發出匯流排使用需求的程序。匯流排包含一個重新發出這些需求的處理程序。以這個例子來說，它假設主控端在時脈的上升邊緣發出匯流排使用需求，而匯流排處理這些需求在時脈的下降邊緣。

區塊的讀／寫（Blocking Read/Write）

區塊讀／寫功能傳遞在匯流排上區塊間的數據資料。只有當資料傳遞完成時，功能呼叫才會結束。一旦主控端發出使用需求，只要使用需求狀態表示不允許，功能呼叫將被阻擋下來。對線程處理程序來說（也就是，從線程處理程序中呼叫這個功能的主控端也如此運作），執行動作會以“wait( )”宣告來暫緩。方法處理程序的執行無法暫緩，因為“waits”並不被允許。功能呼叫必須立即結束，這與區塊讀／寫介面規格相反。然而，藉由利用“next_trigger( )”功能呼叫[6]的動態感應功能，有可能獲得類似的行為結果。

匯流排處理程序在時脈落下的邊緣啟動。從堆積在排序列裏未處理的使用需求中選擇最適合的需求來執行。選擇與使用需求訊號傳遞的地址相對應的受控端，與建立受控端介面呼叫。這種讀／寫呼叫會立即結束。匯流排處理程序會檢查功能呼叫的結果。如果回應狀態沒有問題，它會結束這個使用需求，不然它就會將主控端的使用需求狀態設定為等待（WAIT），這樣它就必須在接下來的每一個匯流排活動中檢查受控端的狀態。只有在受控端的狀態回應沒有問題的情況下，時匯流排處理程序才能結束目前的使用需求。如果它是最後一筆需要處理的資料項目，主控端需求結束，以及匯流排處理程序將為主控端區塊功能產生一個事件訊息。如果有更多的資料項目要被傳送，主控端需求會以稍微修正的資料地址區間再次被排序。

非阻隔讀／寫（Non-blocking read/write）

當主控端發出非阻隔讀／寫功能呼叫時，功能呼叫將在匯流排需求表填入後立即結束。主控端則必需等待直到需求狀態，也就是，呼叫狀態變為沒問題或有錯誤發生。這項檢查發生在每一次上升時脈邊緣（靜態感應列）觸動主控端處理程序時。

這種讀（或寫）使用需求在下降時脈邊緣由匯流排處理程序執行。被指定位置的受控端可能需要數個時脈週期來完成這個功能呼叫。在這段期間，匯流排不接受任何使用需求，但是必須一直等到功能呼叫結束。因此在每一次被觸動時，它必須檢查受控端讀／寫活動的狀態。這與主控端處理程序相類似，只有現在它考慮到訊號處理層對受控端的呼叫。

直接讀／寫

當主控端在上升時脈邊緣發出直接讀／寫功能呼叫時，匯流排處理程序便會直接執行這個呼叫。選擇地址資料對應到的受控端，以及呼叫相對的直接受控介面功能。這個功能也立即執行活動，因此可以產生記憶體資料馬上讀／寫的結果；受控端的等待訊號則被忽略。所以，在不需要複雜的硬體／軟體協同驗證（HW/SW co-simulation）來設定的情況下，使軟體偵錯器在SystemC 覆蓋的處理器模組（主控）頂層上動作並不困難。

受控端讀／寫介面

當受控端是沒有等待狀態時，完整的受控端功能性乃建立在介面功能的本身。受控端可能需要零個或多個時脈週期來執行一個讀或寫的介面呼叫。對零“等待時脈週期”而言，受控介面功能立即回覆沒問題的狀態。對一個或多個“等待時脈週期”而言，引發受控端功能呼叫的匯流排方式必須等待直到受控端狀態回應沒問題。這就像發生在主控處理程序中，非阻隔主控介面的功能呼叫。這裏也一樣藉由利用動態感應列機制，在數個“等待時脈週期”之後通知匯流排操作已經完成來達到加速的目的。

仲裁者

所有主控端都能夠彼此獨立，而發出使用需求呼叫。所有接收到的使用需求呼叫都被置於排序列當中。如果匯流排準備要執行一個使用需求呼叫，最佳的選擇會來自於排序列當中。如果排序列中只有一個使用需求，那這將是唯一的選擇。對兩個或更多個使用需求來說，就需要仲裁裝置。每一個使用需求都有一個優先順序的識別號碼。這個號碼愈低，優先順序愈高。擁有最高優先權的使用需求呼叫，會最先從排序列中被選擇出來。

使用需求可以是爆發性的讀／寫活動，在這裏，眾多資料項目將被傳遞。一旦這樣的使用需求被選擇，第一筆資料項目將被處理，以及使用需求將被放置回排序列當中，直到完整的資料項目組傳遞完成。同時，如果有其它較高優先順序的使用需求呼叫在排序列之中，這個使用需求將被選取，造成爆發式資料傳遞的中斷。

如果排序列中包含一個有鎖定設定的使用需求呼叫，這個使用需求只會在前一個被處理的使用需求有相同優先權時才會被選取。以這種方式，一個使用需求能夠比擁有較高優先順序的使用需求享有優先使用匯流排的等級。

實驗結果

為了說明匯流排與其介面正確的操作行為，如同圖二所示，產生一組測試資料。三種不同形式的主控端連接於匯流排，以及兩種形式的記憶體也被連接作為受控端。仲裁裝置同時也被連接。在特定的時間內，每一個主控端針對讀寫資料發出匯流排使用需求呼叫。第一個主控端利用非阻隔介面功能讀寫單筆資料；第二個主控端利用非阻隔介面功能的鎖定模式讀寫資料串；第三個主控端利用區塊介面功能移動整個區塊的資料。而在受控端的記憶體，一個受控端需要一個時脈週期完成操作，而另外一個受控端能夠在時脈為零點時就完成操作。主控端這樣的設定方式，將使匯流排平均有大約百分之八十的時間都被佔據使用。有時候，使用需求會在同一個時間發出，而仲裁器會選擇一個最適合的使用需求呼叫。這樣的設定結果顯示在表一的第一行。

測試資料（testbench）（最佳化編譯（-O3））

在107的模擬時脈週期下執行不同處理程序。可以測量出所花的時間與計算出每秒的模擬週期數目。然而，執行時所用的CPU時脈速率，會影響到測試的結果。在這個例子裏是利用1 GHz CPU的Linux機器來執行測試的工作。

藉由增加多個主控端與多個受控端來改變設定，不會降低多少模擬執行的速度。將主控端的數目加倍，以及／或是增加受控端的數量，降低少於百分之二十的模擬速度。

簡易匯流排的建立是利用有動態感應列的線程處理程序。其它架構會是利用有動態感應列的方法處理程序。與線程處理程序相比較，方法處理程序有較快的模擬速度，因為在處理程序切換時管理的模擬核心較少。然而，建立方法處理程序比建立線程處理程序稍微複雜一點。為了簡化起見，這個例子裏只有使用線程處理程序。

結論

今日，在設計流程初期缺乏可執行平台模組，正成為系統單晶片設計中最大的障礙。利用SystemC的高效能模擬可及早獲得可執行平台模組，而這些模組?對是易於使用的。抽象的適當運用使TLM平台模組加快執行速度，主要的關鍵在於抽象介面的使用、避免掉多餘的處理程序活動，以及運用IMC結構。

（作者任職於新思科技德國分公司）

〈參考資料

[1] G. D‥omer and P. Gajski. System Design: A Practical Guide with SpecC. Kluwer Academic Publishers, 2001.

[2] L. Guerra, J. Fitzner, D. Talukdar, C. Schl‥ager, B. Tabbara, and V. Zivojnovic. Cycle and phase accurate dsp modeling and integration for hw/sw co-verification. Design Automation Conference, pages 964-969, 1999.

[3] M. Kawarabayashi, J.-Q. Lu, K. Goto, and P.W. Fung. System level design methodology for system on a chip. NEC Research & Development, 41（3）:248-252, July 2000.

[4] H. Kurokawa, H. Ikegami, H. Ryu, K. Nitta, and T. Kawatsu. C++ based system simulator for pre-verification of system-on-a-chip devices. NEC Research & Development, 41（3）:258-263, July 2000.

[5] K. Svarstad, N. Ben-Freduj, G. Nicolescu, and A. A. Jerraya. A higher level system communication model for object-oriented specification and design of embedded systems. In Proceedings of the Asia and South Pacific Design Automation Conference, Yokohama, Japan, Feb. 2001. IEEE.

[6] SystemC 2.0 functional specification and source code. available at: www.systemc.org.〉