|
1 引言 如今，隨著(zhù)集成電路工藝發(fā)展到深亞微米的階段，處理器體系結構的設計研究正朝著(zhù)多 核的方向發(fā)展。Intel、IBM、SUN 等主流芯片產(chǎn)商已經(jīng)在市場(chǎng)上發(fā)布了自己的多核處理器。 目前多核處理器的發(fā)展尚處于起步階段，有很多問(wèn)題還有待解決。其中，一個(gè)十分重要的方 面就是設計高效的片上通信架構。多個(gè)內核上同時(shí)執行的各個(gè)程序之間可能需要進(jìn)行數據 共享與同步，因此多核處理器的硬件結構必須支持各個(gè)CPU 內核之間的通信。一般說(shuō)來(lái)， 異構多核處理器和同構多核處理器在通信機制的設計上有著(zhù)不同的考慮。異構多核處理器通 常是針對嵌入式系統的應用，主要存在著(zhù)總線(xiàn)、存儲控制器、共享存儲區等通信機制。 異構多核處理器系統的幾種主要通信機制，事實(shí)上都可以通過(guò)一個(gè)共享存儲區來(lái)實(shí)現，例如郵箱、消息、信號量實(shí)際上都是以共享存儲區作為傳播載體。同時(shí)，也考慮到 SystemC 的設計方法可以支持設計者在不同層次上建模減小了代碼量和工作量，提供了更高的工作效 率。因此本文在采用共享存儲器通信機制的同時(shí)，基于SystemC 提出且建立事務(wù)級多核通 信模型，并利用MP3 解碼程序實(shí)例證明了本模型有效的實(shí)現了多核間的通信。 2 SystemC 通信總線(xiàn)模型 2.1 SystemC 簡(jiǎn)介 SystemC 由C++衍生而來(lái)，在C++基礎上添加硬件擴展庫和仿真庫構成，從而使SystemC 可以建模不同抽象級別的包括軟件和硬件的復雜電子系統[4]。他的最基本的結構單元是模塊 (module)，模塊可以包含其他模塊或過(guò)程(process)和方法(method)，過(guò)程如同C 語(yǔ)言中的函 數用以實(shí)現某一行為模塊，通過(guò)接口(port) 與其他模塊通信接口之間用信號(Signal) 相連。 一個(gè)完整的系統由多個(gè)模塊組成，每個(gè)模塊包含一個(gè)或多個(gè)過(guò)程和方法，過(guò)程是平行工作的。 基于SystemC 的設計方法支持設計者在不同層次上建模減小了代碼量和工作量提供了更高 的工作效率，也就是說(shuō)利用SystemC 與傳統的方法相比可以更為高效快速地進(jìn)行仿真。 2.2 模塊細化及基于SystemC 的通信總線(xiàn)行為級建 模 一個(gè)典型的片上系統模型框架通常包括總線(xiàn)、總線(xiàn)仲裁器、微處理器、數字信號處理器 (L6P)、存儲器和其他專(zhuān)用集成電路(ASIC)。這樣一個(gè)復雜的系統，傳統的設計辦法是全部 使用C/C++進(jìn)行描述以進(jìn)行系統級建模和驗證，然后將硬件部分的描述手工翻譯為 VHDL/Verilog HDL，等硬件描述語(yǔ)言進(jìn)行描述.等硬件全部實(shí)現后再進(jìn)行軟件的設計與實(shí)現。在引入SystemC 作為建模語(yǔ)言的情況下，整個(gè)系統可以方便地用一種語(yǔ)言進(jìn)行描述、 建模、仿真、細化，直到最終實(shí)現。 在使用 SystemC 建立片上總線(xiàn)行為級模型時(shí)，根據總線(xiàn)一般模型中各個(gè)模塊的行為特 性，進(jìn)行了進(jìn)一步的模型細化，得出片上總線(xiàn)行為級模型的SystemC 模塊結構圖，如圖1 所示。在模型細化的過(guò)程中，總線(xiàn)主設備被劃分為直接型主設備、阻塞型主設備和非阻塞型 主設備;總線(xiàn)從設備被劃分為快速存儲器、慢速存儲器和代表ASIC 的通用串口;通信總線(xiàn)和 仲裁器模塊保持不變。 總線(xiàn)采用分層通道的方式實(shí)現，實(shí)現了直接型接口、阻塞型接口和從設備接口。在某些 時(shí)鐘的上升沿，總線(xiàn)收集到來(lái)自各個(gè)主設備的從設備讀寫(xiě)請求，并將這些請求加入請求隊列。 在時(shí)鐘的下降沿，總線(xiàn)將請求發(fā)送給總線(xiàn)仲裁器，由總線(xiàn)仲裁器根據一定的仲裁規則進(jìn)行仲 裁，從請求隊列中選擇出合適的主設備請求并通過(guò)從設備接*由總線(xiàn)從設備進(jìn)行服務(wù)。 3 基于異構多核的通信模塊設計與實(shí)現 3.1 設計原理 按照上文中提到的總線(xiàn)架構，多核處理器作為通信總線(xiàn)的主設備而共享存儲區作為總線(xiàn) 的從設備形成了整個(gè)系統模型，但考慮到異構多核與同構多核相比存在一個(gè)問(wèn)題：即由于不 同內核的應用程序采用的是不同的交叉編譯器，因此高級語(yǔ)言所指定的內存空間是無(wú)法做到 一致的，即便是直接寫(xiě)匯編程序指定內存地址，由于操作系統分配給不同模擬器的程序空間 是不同的，也無(wú)法做到共享存儲。也就是說(shuō)，無(wú)論是高級語(yǔ)言編程，還是匯編語(yǔ)言編程，都 要解決二進(jìn)制代碼和內核模擬器之間的通信。因此上文中提到的基于SystemC 的通信總線(xiàn) 就需要針對不同的異構多核組合進(jìn)行相應的修改，缺少通用性，違反了模塊設計封裝化原則。 經(jīng)過(guò)不斷的探索和比較，本文最終采用了一種從方法學(xué)角度和可擴展性角度來(lái)看，都比 較合適的方法： 在各個(gè)處理器與通信總線(xiàn)之間添加一個(gè)通信控制模塊(CMCCtrl-- Communication control)如圖2 所示。 該模塊用來(lái)專(zhuān)門(mén)處理各個(gè)核之間的通信指令，對其進(jìn)行解釋翻譯，并將最終行為直觀(guān)的 告訴總線(xiàn)，達到核間通信的目的。新架構設計按照SystemC 交易級建模(TLM)原則，為以后 多核功能的擴展性提供可能性。 3.2 通信機制 為了異構多核通信的實(shí)現,需要向多核仿真器的每個(gè)模擬器內核擴展三條訪(fǎng)問(wèn)共享存儲 區的指令，分別是：申請空間、讀取和寫(xiě)入。 在內核代碼中對共享存儲區訪(fǎng)問(wèn)指令進(jìn)行譯碼之后，需要對共享存儲區發(fā)出操作請求， 與操作請求一起發(fā)送的是操作的信息，對于申請、讀取和寫(xiě)入三種操作，各自的操作信息如 下表所示： 當 CMCCtrl 受到接收到來(lái)自Core1/Core2 的訪(fǎng)問(wèn)請求，模塊觸發(fā)。同時(shí)隨著(zhù)請求一起接 收下來(lái)的其他信息，包括指令編碼、請求的數據類(lèi)型、地址偏移等等。CMCCtrl 對這些請求 信息進(jìn)行分析，當判斷出核間需要數據通信后，將需要的信息提取發(fā)送至總線(xiàn)模塊。具體模 塊描述如下: SC_MODULE(CMCCtrl) { sc_inout isCore1, isCore2; //來(lái)自Core1/Core2 的訪(fǎng)問(wèn)請求，是本模塊的觸發(fā)信號 sc_out core1_latency, core2_latency; //返回給Core1/Core2 的延時(shí)信息 sc_inout data_value; //需要傳遞的數據 sc_port bus_port; //通信總線(xiàn)模塊接口 /*返回給Core1/Core2 的應答信號，表明CORE1/Core2 獲得了共享存儲區的訪(fǎng)問(wèn)權，并 且可以繼續執行下一個(gè)周期的操作*/ sc_inout ackCore1, ackCore2; /*隨著(zhù)isCore1/isCore2 請求一起接收下來(lái)的請求信息，包括指令編碼、請求的數據類(lèi)型、 地址移等等*/ sc_inout data_type, array_capacity, data_index, data_id; /*隨著(zhù)is Core1/isCore2 請求一起接收下來(lái)的，表明當前Core1/Core2 運行的周期數，用 于進(jìn)行內核調度判斷和訪(fǎng)存沖突分析*/ sc_in core1_cycle, core2_cycle; /*對isCore1 或者isCore2 的上升沿敏感的響應函數，它被定義為線(xiàn)程類(lèi)型，是CMCCtrl 類(lèi)的實(shí)現函數。函數內部需要對兩個(gè)內核的訪(fǎng)問(wèn)請求進(jìn)行判斷、控制，并調用相應的其 它成員函數。*/ void Controller(); //對于每一個(gè)write_shm_data 請求，將數據寫(xiě)入指定的共享存儲區空間 void WriteShmDataHandler(struct InstBuffer *inst); //對于每一個(gè)read_shm_data 請求，將數據寫(xiě)入指定的共享存儲區空間 void ReadShmDataHandler(struct InstBuffer *inst); …… SC_HAS_PROCESS(CMCCtrl); // constructor CMCCtrl (sc_module_name _name){……} }; 4 MP3 解碼程序的多核測試 為了更加充分進(jìn)行驗證，并展示多核通信模塊在實(shí)際應用中的價(jià)值，本文選擇了MP3 解碼程序進(jìn)行基于多核系統的移植，并驗證仿真結果以及仿真效率。 MP3編碼的主要方法是在頻域上對音頻文件內容進(jìn)行編碼壓縮，而解碼過(guò)程是還原頻域 的內容再變換成原始的時(shí)域音頻信號。按照ISO/IEC11172-3標準，MP3解碼算法分為同步與 校驗、Huffman解碼、比例因子解析、反量化、重排序、立體聲處理等十個(gè)部分。 在考慮應用程序的多核移植時(shí)，可以是數據劃分也可以是任務(wù)劃分的。對于MP3代碼， 如果采用數據劃分式，則可以在不同的處理器內核上解不同的數據幀。而如果采用任務(wù)劃分 方式，則可以將解碼的不同過(guò)程在多個(gè)內核之間形成流水作業(yè)，采用共享存儲區進(jìn)行不同流 水級之間的數據傳遞。顯然后者需要更多的核間通信，更適合于驗證其性能，因此，本文采 用了按照任務(wù)劃分的方式進(jìn)行代碼的多核移植。 在測試中，我們采用ARM+PISA的雙核系統，因此需要將MP3解碼程序按照功能劃分為 兩部分，分別放在兩個(gè)內核上運行，形成流水線(xiàn)。本文所采用的MP3解碼軟件在A(yíng)RM開(kāi)發(fā) 套件（ARM Design Suit）軟件仿真平臺上測試的結果表明：合成多項濾波器部分占用了大 約50％的計算量。根據這個(gè)結論，本文粗略地對應用程序在雙核之間進(jìn)行任務(wù)劃分：其中 一個(gè)內核運行計算量最大的合成濾波，另外一個(gè)內核實(shí)現Huffman解碼、比例因子解析、反 量化等步驟。兩個(gè)內核通過(guò)系統提供的通信控制模塊進(jìn)行通信并保持同步。 表2是這一測試的統計結果。統計數據提供了兩方面的信息： 1）MP3解碼程序的雙核加速比，由統計結果中的“運行周期數”反映； 2）多核仿真器在進(jìn)行MP3解碼仿真時(shí)的仿真效率，由“仿真時(shí)間”和“仿真速度”兩 項統計結果反映。 5 總結 無(wú)論考慮單位計算性能的能耗因素，還是對于提高處理器性能，多核體系結構尤其是異 構多核體系結構都是當前的熱點(diǎn)研究方向。本文主要論述了面向異構多核處理器的片上通信 設計。對于處理器的內核間通信，采用了共享內存技術(shù)。 本模型充分體現了SystemC的語(yǔ)言?xún)?yōu)勢，對進(jìn)一步了解和探討異構多核處理器結構、核 間通信、異構多核低功耗設計等方面打下一定基礎。 本文作者創(chuàng )新點(diǎn): 提出了一種基于SystemC的異構多核通信架構模型，并通過(guò)添加控制 模塊解決異構多核間通信通用性問(wèn)題。 |
