前言

當面臨複雜的專案時，硬體與韌體兩方面的人才必須從一開始的規格制定，一直到產品的實際推出期間密切合作，在整個開發過程中，雙方面都必須要有一個方法來驗證所開發的內容，雖然在硬體巨集功能方面可以使用RTL模擬來獨立進行除錯，不過面臨的問題還是在韌體方面，因為它只有在硬體完成時才能進行精確的測試。

但等待硬體的完成會對專案的進程帶來時間的浪費，原因是這兩個部份無法同時進行作業，另一個硬體與韌體RTL協同模擬所面臨的問題則是有關速度的效能。

韌體的測試有時代表了必須產生用來驗證演算法中特定情況的測試序列碼，要在模擬中找出單一演算法中的一個錯誤可能會非常耗時，同時當韌體的複雜度越來越高，再加上它本身採用演算法的特性，RTL模擬的不足就越來越明顯。

問題描述

對於這些傳統的問題，解決的方法只能靠軟體模擬器，完全針對韌體開發設計，它們能夠用來進行演算法的除錯，但在硬體的精確度上卻非常低，原因在於它並沒有導入時間的概念，也沒有考慮到硬體同時運作的情況，雖然演算法中的巨集錯誤能夠被偵測，但卻有相當大部份的錯誤無法被發現，造成錯誤的偽驗證碼。

就算採用獨立的韌體與硬體驗證可以進一步產生一些在兩個部份合併測試時才會出現的錯誤，但還是會面臨當問題發生時，到底哪一方面才是出錯來源的困擾，甚至在最糟的情況下還可能造成需要重新設計的情況，代價可謂不低。

在目前的系統設計中，通常缺乏成熟並且定義明確的系統化設計方法，可行的第一個有效改善步驟是採用以RTL開發為基礎的傳統設計方式，搭配上適合軟體開發，使用SystemC以及TLM標準的高效率軟體模擬器。

透過這樣的方式，將可以架構出相當接近硬體規格的SoC模擬環境，同時也可以節省大量的模擬時間。

SystemC/TLM介紹

SystemC主要來自於使用C++語言架構系統軟硬體部件模型的想法，在1999年9月第一次公開推出，同時並將掌控權交給OSCI(Open SystemC Initiative)，這代表了SystemC程式庫可以免費使用，同時直接由網際網路下載(www.systemc.org)。

《圖一 SystemC的發展歷史》

架構介紹

SystemC程式庫主要由實現以下功能的C++類別組成：

硬體部件以模組方式表示，模組(module)可以包含一系列相互或與其他外部模組同步的程序(process)，要與外部模組溝通，程序可以使用模組連接埠(port)，每個連接埠都連結到一個介面(interface)，並在介面上進行一系列存取方法(access method)的宣告，所提供的存取方法則依通道(channel)的型態而定。

SystemC的模擬可以在單處理器電腦上執行，為了要管理並行運作的同時性、程序同步以及時間的模擬，SystemC整合了類似於VHDL中所使用的排程器(scheduler)。

《圖二 SystemC架構》

抽象層

SystemC擁有以RTL層級描述硬體模型的能力，因此，和傳統的VHDL模擬比較，用來模擬一項工作的電腦處理器資訊量基本上大致相同，事實上SystemC並沒有提供能夠強化效能的技巧，因此處理器指令的數量必須要降低。

為了達到這個目的，唯一的解決方案就是捨棄包含在RTL層的部份資訊，抽象的程度越高，模擬的速度就越快。

《圖三 抽象層》

而在設計時程上，Vasishta表示，eASIC的解決方案僅需4周就能完成工程樣品，之後的驗證和修改也十分的容易和便利，最快2個月就能完成一個設計時程。

在RTL模型描述中，通常會使用一個時脈來進行同步，每一個暫存器、每個匯流排以及每個位元都以單一時脈週期的方式描述。

為了簡化這個模型，SystemC提供了

SystemC設計工程師可以依本身的需求來描述系統，同時在同一個設計中自由混用不同程度的抽象層。

交換層級模型的建立(TLM)

由於一個系統可以用許多不同的方式來建立模型，因此需要定義一些模型建立標準，其中的一項標準為交換層級模型(TLM, Transaction Level Model)，它建議了一個將模組以層級結構方式安排，並在功能與RTL模型間建立抽象層，並在同時維持高模擬效能的通用方式，由於具有這些特點，TLM標準相當適合用來測試嵌入式軟體。

《圖四 TLM交換》

TLM的概念是將每個硬體模型的功能和與其他週邊模型的通訊分離。

當模組處理完內部工作並希望將結果與其他模組溝通時，就必須進行一個交換動作，交換動作的型態則由通道介面中所宣告的一系列方法中選擇。

這些交換動作的實現在通道內進行，這代表了：

交換動作並不一定要有資料的傳輸，中斷也可以以TLM交換動作來加以模擬。

通常模組的功能或介面應該要：

TLM的效能

RTL層級的許多資訊在TLM抽象層並不會被採用，例如匯流排交換動作所使用的週期數並未進行模擬，但另一方面，交換動作所需耗費的大略時間則會加以導入，也就是說，只有對模組同步有用的資訊才會被保留，因此可以節省大量的處理器指令。通常變數所使用的資料型態為C++本身所原有，以便能夠盡可能地接近電腦處理器的架構。

雖然在模擬速度上的改善很難量化，但在效能表現上則可以比使用RTL模擬更接近序列模擬的結果。

TLM的進一步改善

在整個TLM系統模型建立完成後，將單一模組或通道的實現交給更低階層，例如在交換動作發生時觀察RTL信號的行為表現，或者在系統的精確位置測試硬體實現的相關動作將會有所幫助。

TLM架構的模組化特性讓整個改善動作變得更加簡單，所有的硬體模型都擁有獨立於週邊模型以及相關通道的內部功能。

這代表了單一硬體模組中的功能可以全部重新定義，並重新整合到整個系統中而不會影響其他功能，相同的情況也可以在通道上實現，它們也能夠在不影響模組實現的情況下重新定義。

《圖五 TLM通道的改善》

設計方法

如前面所描述，在傳統的設計流程中，韌體團隊在RTL硬體完成前，基本上無法進行程式碼的開發。

為了加速韌體開發的速度，在軟硬體功能分割確定後，第一個目標就是要知道哪些功能必須在SystemC/TLM模擬器中建立模型。

硬體架構的分析應該要在進行任何RTL開發前提供模組的硬體規格，當架構的規格符合雙方團隊的要求後，就能夠同時進行開發工作：

由於TLM模型的描述要比RTL設計快上許多，因此SystemC設計工程師可以相當快速地完成TLM模型，同時硬體團隊也能夠繼續使用RTL模擬來進行除錯。在設計時程的初期，應該要進行韌體驅動程式的開發以便驗證RTL週邊以及SystemC週邊模型，接著再進行真正的韌體開發。

選擇適當的模型建立層級

現在讓我們考慮使用SystemC軟體模擬器進行通用系統化單晶片開發的情況，系統包含由硬體週邊環繞的可程式處理器組成，由於模擬器的目的是測試嵌入式軟體，因此所有的硬體模型在設計時必須保留韌體測試的功能，TLM標準提供了硬體模組模型建立的主要原則，並為抽象層留下彈性自由空間。

如果能夠降低硬體模型執行一項工作的交換動作數量，那麼模型就能夠提供更佳的模擬速度，但從另一個角度來看，如果細節被抽象得太過分，那麼就可能會遺漏某些關鍵步驟。

SystemC設計工程師的責任是以韌體開發工程師的角度決定有用與無用的功能，高效率的TLM模型必須：

SystemC設計工程師應該要先閱讀模組的規格以便萃取出對韌體有用的巨集功能，相當明顯地，最終系統的驗證也必須以FPGA或硬體模擬平台為基礎。以韌體要求開始並在新韌體介入發生時結束來進行巨集功能的安排，因此，每個巨集功能都能夠以下列的交換動作程序來總結：

硬體週邊在對韌體要求進行回應前可能需要與其他硬體模型進行一些交換動作。

案例研究

這個通用案例研究包含了以C語言進行編程的處理器，處理器與C/C++語言相容的事實相當重要，因為它將可以簡化在SystemC(C++)環境中測試韌體的整合動作。

處理器由兩個硬體週邊環繞，分別為執行：

韌體團隊必須進行微處理器的編程，兩個硬體模組的RTL功能會在專用的硬體規格中描述。

韌體的功能與限制必須要事先確認，以便能夠為硬體模組選擇模型建立的層級，同時也必須考慮到這個介面卡會由外部接收資料並將它寫入記憶體中：

《圖六 系統化單晶片案例力研究》

模擬環境

我們的目標是進行前述系統化單晶片的模擬：

SystemC程式庫並無法與任意能夠進行C/C++程式碼除錯的其他軟體相容，因此必須使用相容的開發環境進行編譯，這些程式庫可以簡單地以免費的gcc Linux套件進行編譯。

SystemC程式庫必須搭配選用的開發軟體進行編譯，其他軟體可能無法進行這項工作，不過我們可以使用gnu C++輕鬆地進行編譯。

基本架構

依TLM原則，應該要有：

要進行系統化單晶片模型的除錯，我們必須先定義測試的方法。

《圖七 系統化單晶片模型》

微處理器模型

微處理器的模組與其他不同，原因是它的功能是以韌體原始碼的方式來加以實現。

相當明顯地，微處理器是一個包含許多內部組件的複雜元件：

所有的組件都與外部振盪器同步，內嵌軟體首先以C/C++語言編寫，接著經過轉換/編譯與連結轉化成為CPU可以了解的組合語言碼，組合語言碼會被下載到CPU能夠存取的記憶體當中。

TLM描述

大部份的系統化單晶片設計專案都會使用已經在市場上流行已久的微控制器元件而不會重新設計新的架構，由於微處理器模組的高複雜度，因此進行控制器的模擬相當耗時，整合微處理器的TLM模型而非RTL模型將可以大幅改善模擬的效能。

對於這個低成本的案例事實上還有進一步改善的方法，通常會在以SystemC概念為基礎的昂貴商業工具中採用，以下我們將提出以TLM建立微處理器模型的簡化方法。

微處理器的通訊是以模型內的通道來加以實現，在這裡有兩個，所有的可用交換動作會依韌體需求以及所連接硬體模組的功能列在相對應的連接埠介面上，例如一個簡單的例子是以下的記憶體模型。

我們觀察程式計數器(PC, Program Counter)的動作，它定義了兩個CPU的巨集功能：

這些功能可以使用兩個內部的並行運作程序來建立模型：

兩個程序間的同步可以使用內部事件達成。

當啟動主程序模組時，它會呼叫以韌體原始碼實現的主功能，透過這樣的方式，真正的主程式原始碼會由MAIN主程序部份執行。

而中斷程序則與由硬體週邊所產生的中斷同步，依中斷來源的不同，它會呼叫韌體原始碼中適當的ISR函數，讓實際常式原始碼在INTERRUPT中斷程序部份執行，透過這樣的安排，就能夠在加入其他程序時輕鬆管理中斷的優先次序。

《圖八 微處理器模型》

軔體的整合

硬體暫存器和傳統的韌體變數不同，它們被韌體用來與硬體週邊溝通，當硬體暫存器被賦予一個數值時，韌體與硬體週邊都必須指到相同的位址。

要建立這樣的模型，我們使用了C++的參照(reference)功能，在初始化過程中，每個硬體模型都會收到在韌體原始碼中所宣告暫存器變數的參照位址。

當硬體暫存器被韌體指定一個新的數值時，它有可能會對硬體週邊產生中斷要求，由於中斷動作在TLM中以交換動作做為模型，因此必須呼叫適當的通道。

基本上有兩種可能性：

在這兩種情況中，韌體原始碼必須包含專門針對模擬目的編寫的特殊程式碼。

記憶體模型

在記憶體方面，這個例子中所使用的是一個FLASH元件，請參考圖九。由於它的通訊協定要比傳統的RAM記憶體複雜，因此我們將討論如何依韌體的需求選擇適當的抽象層級。

例如以目前的韌體限制，FLASH記憶體只用來作為資料寫入，要進行資料FLASH記憶體的寫入，就必須以特定順序的寫入序列碼來進行：

在RTL資料流程中，我們可以看到發送這些序列碼時所有FLASH匯流排信號的變化，在輸出入匯流排上，我門可看到以紅色標示的兩個命令週期，以及之後元件進行記憶體資料寫入時的忙碌時間。

《圖九 RTL中的Flash資料寫入流程》

TLM描述

在這裡我們擁有兩個模組，一個稱為MICRO，用來實現韌體CPU，另一個稱為FLASH，用來實現FLASH記憶體功能，兩個模組間的通訊可以透過將所有匯流排交換動作重新分組的通道進行，每個模組也有都擁有存取通道的專用介面。

當微處理器(MICRO)已經準備好在模擬時間T0對FLASH送出命令時，整個模擬程序就進入了交換動作階段，依韌體要求的不同，FLASH交換動作的實現可以通過以下步驟進行最佳化：

韌體程序暫停直到整個命令已經由FLASH處理完成：一個MICRO交換動作加上一個FLASH交換動作

模擬時間T0：MICRO交換動作取得命令型態、目標位址以及所要寫入資料等參數

模擬時間T2：FLASH在工作完成後通知韌體

韌體程序暫停直到命令完全送到FLASH：一個MICRO交換動作加上一個FLASH交換動作

模擬時間T0：MICRO交換動作取得命令型態、目標位址以及所要寫入資料等參數

模擬時間T1：韌體程序重新啟動

模擬時間T2：FLASH在工作完成後通知韌體

韌體程序可以在兩個命令週期間持續進行：二個MICRO交換動作加上一個FLASH交換動作

模擬時間T0：第一個MICRO交換動作取得第一個命令位元組、目標位址以及所要寫入資料等參數

模擬時間(T1+ tfw)：第二個MICRO交換動作取得第二個命令位元組參數

模擬時間(T2+ tfw)：FLASH在工作完成後通知韌體

由於兩種不同通訊方式的交換動作數量不同，因此模型的效能也有所不同：

依所選用解決方案的不同，MICRO與FLASH間的介面宣告也會不同，通道可以進一步改善來貼近RTL描述，但兩個介面還會保持一樣，修改的只有通道的內部實現方式。

同時更進一步，FLASH的功能必須依FLASH介面的交換動作來加以實現，如果通道經過改善，將不會影響FLASH的功能。

《圖十 FLASH記憶體模型》

通訊協定模型

通訊協定模型是內部系統化單晶片組件與外部間的溝通橋樑，也就是測試內嵌軟體的入口，通用的通訊協定介面可以將外部送入的資料轉換成系統化單晶片內部組件能夠了解的信號序列，並以相反的動作進行輸出。

TLM描述

首先我們必須區分內部硬體模型與外部間通訊。

在內部通訊上我們擁有兩個模組，一個是實現韌體CPU的MICRO，另一個則是實現通訊協定功能的PROTOCOL，兩個模組間的通訊透過一個通道進行，並將韌體所需的匯流排交換動作重新分組，如果需要簡化的範例可以參考記憶體模型部份。

外部系統化單晶片模組的通訊則對應到測試平台的輸入，基本上並沒有清楚定義的方法來進行測試，不過我們可以簡單地區分為兩種形式：

《圖十一 內部通訊的通訊協定》

靜態測試平台

SystemC模擬由SystemC主函數執行，稱為sc_main，接著通過以下列四個步驟進行的典型模擬：

由sc_main程式離開

模擬可以先行啟動一段預先設定的時間，或者直到所有的系統化單晶片模組結束執行動作。

所有觸發動作的產生與結果的檢查可以嵌入到：

不管是哪一種情況，在執行過程中使用者都無法介入，如果韌體開發工程師希望執行新的測試以便對內嵌軟體進行除錯，那麼他就必須修改測試碼然後再進行新的模擬動作。

《圖十二 靜態測試平台》

動態測試平台

如果韌體開發工程師可以在執行時直接進行新的測試而不需要重新啟動SystemC模擬，那麼整個模擬環境將會更有彈性。

由於SystemC模擬都在sc_main開始與結束，因此我們必須在獨立於SystemC模擬外使用額外的執行緒(thread)進行測試平台公用程式(utility)的執行：

基本上測試平台公用程式是一個GUI圖形化使用者介面，為韌體開發工程師提供所有有用的測試，資料經過共用記憶體進行交換，而執行緒間的同步則由作業系統的事件處理程序負責。

PROTOCOL通訊協定的實現整合了作業系統的事件，當所有的系統化單晶片模型完成工作後，模型就會等待進行測試平台公用程式的觸發，執行緒間通訊細節的選擇採用與記憶體模組範例中相同的做法，例如依內嵌軟體而定。

通過這樣的方式，我們模擬了實際系統化單晶片的行為，並為韌體開發工程師加入除錯功能。

依系統化單晶片應用的不同，結果的檢查可以在測試平台公用程式或系統化單晶片的執行緒中完成。

《圖十三 動態測試平台》

案例研究的應用

以上所提的案例可以應用到絕大部份的系統化單晶片開發專案上，雖然可能會加入更多的處理器或內部組件，但整個模擬架構依然相同：

測試平台公用程式可以依韌體開發工程師的個別需求加以客製化。

例如完整的FLASH記憶卡模擬器已經依這些原則開發完成，韌體開發工程師可以通過智慧型互動化公用程式即時地與系統化單晶片模型溝通。

這個GUI介面實現了韌體除錯部份較高或較低階層的功能：

以現有的系統化單晶片TLM模型為基礎，我們也能夠進行部份RTL/SystemC的協同模擬：

任何的TLM模組都可以整合到RTL設計中而不需要相對應的RTL模組，要連結這兩種描述式語言，我們必須：

《圖十四 測試平台公用程式範例》

結論

目前許多市場上的軟體已經使用SystemC語言來加速系統化單晶片專案的開發，毫無疑問地，SystemC在整合到設計方法後帶來相當大的好處。

與其他語言比較，SystemC的一個重大優勢在於它的標準化，每家公司都能夠架構自有的除錯工具而不需要受到任何工具供應商的限制，透過這樣的方式，資料以及免費程式庫的交換將變得更加容易。

依照這樣的做法，ST推出了整合功能強大演算法內嵌韌體的系統化單晶片記憶卡模擬環境，所使用的唯一外部工具是C/C++開發環境，和先前的設計方法比較，在由軟體模擬轉換到硬體模擬時可以取得相當良好的成果。

雖然SystemC模型的建立以及CAD設計流程的標準化目前還在持續進行當中，但如果不善加利用將非常可惜，採用以上的設計方法，任何系統化單晶片設計專案都能夠以相當低的成本建立模型，同時取得較高的除錯層級以及更快的模擬速度。