高承,王正彥
(青島大學,青島 266071)
?
FPGA設計中信號量管理的硬件電路設計
高承,王正彥
(青島大學,青島 266071)
摘要:在對嵌入式實時操作系統μC/OS-II中任務之間通信進行深入研究的基礎上,提出了將信號量的管理用基于FPGA設計的硬件電路來完成,同時保證新的混合式實時操作系統對用戶來說是透明的,即保證了混合式實時操作系統的可移植性。經過設計和不斷地改進,混合式實時操作系統成功的移植到Altera公司的DE2-70開發板上,并完成了信號量管理的測試。這是一次探索性的設計,是混合式嵌入式實時操作系統設計中非常重要的一部分。
關鍵詞:RTOS;FPGA;Nios II;信號量
引言
隨著信息化、智能化、網絡化的發展,嵌入式系統獲得了廣闊的發展空間。目前嵌入式技術已成為智能領域的核心技術,特別是物聯網的爆發為嵌入式系統提供了廣闊的應用空間。
嵌入式系統推動了物聯網的崛起,物聯網的崛起,也帶來嵌入式系統巨大的發展潛力。物聯網的核心設備是智能終端,物聯的實現就是智能終端的網絡化運行。嵌入式系統又是智能終端的“大腦”和“中樞神經”,因此嵌入式系統是物聯網產業發展的核心推動力。嵌入式系統是計算機硬件與軟件高度融合的智能體,已經形成了巨大的技術空間和人才市場。實時操作系統(RTOS)是嵌入式系統的基礎運行平臺,其性能的好壞直接影響嵌入式系統性能的高低。
傳統的嵌入式實時操作系統,內核和應用程序是放在一起的,內核任務的優先級一般高于應用程序任務的優先級,因此內核任務優先享有CPU使用權,進而使應用程序的執行效率降低。目前,提高嵌入式實時操作系統處理能力主要是通過使用更高主頻和更多位數的處理器,或者是改進軟件編程算法來實現。但是處理器主頻和位數的提高受限于當前的制造工藝,而軟件編程算法已經不能使其實時性和穩定性進一步提高。因此,單純依靠這兩種方式來提高嵌入式實時操作系統的處理能力已經遠遠不能滿足需要。鑒于硬件電路在處理并發性任務時的優異表現,越來越多的研究人員開始將目光轉向硬件實時操作系統(HRTOS),而近年來不斷發展的FPGA也為完成一個硬件實時操作系統的設計提供了很大的便利。
從20世紀80年代開始,國外就提出了硬件實時操作系統的概念。美國的JAEHWAN LEE和INCENT JOHN MOOENY III在分析比較了RTOS調度器的軟件、硬件實現的基礎上,提出專用硬件IP核實現RTOS調度器,將會大大提高RTOS的工作效率。任務調度是RTOS的核心所在,任務間的通信、外部時間的處理以及中斷處理等都離不開任務調度的參與。
巴西的MELLISSA VETROMILLE和LUCIANO OST分析并對比了將RTOS系統任務調度器分別采用硬件和軟件實現的效率,結果表明硬件調度模型具有更高的性能。
美國馬里蘭大學的PAUL KOHOUT、BRINDA GANESH和BRUCE JACOB 實現了硬件實時任務管理,結果也同樣表明由硬件來完成最為耗時的任務管理所用時間更短且更可靠。
東北大學的尹振宇、趙海、許久強等提出了一種基于硬件操作系統(HOS)的設計結構,在處理器中添加微代碼處理邏輯及硬件處理模塊,將比較耗時的操作采用硬件來實現。
總結國內外的發展趨勢,目標都是設計一款獨立的硬件實時操作系統。但是,獨立的硬件實時操作系統沒有統一的標準,可移植性也就不夠強?;诳梢浦残缘目紤],通過在已有的軟件實時操作系統研究的基礎上,采用軟硬件結合的方式來設計一款實時操作系統,既可以提高效率,又能夠保證可移植性。
1混合式實時操作系統整體設計框架
1.1實時操作系統和平臺的選擇
μC/OS-II[1]由Micrium公司提供,是一個可移植、可固化、可裁減、占先式、多任務實時內核。它提供了基于優先級的任務調度與管理、任務間同步通信、時間管理和中斷服務、內存管理等功能。整個內核基本上都是由C語言編寫而成,只有少部分CPU 硬件相關部分是采用匯編語言編寫的(匯編語言總量只有約200行),便于移植到任何一種其他的CPU 上。正是由于這些優勢,所以選用μC/OS-II作為混合式RTOS的參考系統。
硬件部分的設計采用硬件描述語言Verilog HDL[2]來進行編寫并綜合出硬件電路。選用的軟件為Quartus II9.1和NiosII-IDE,Quartus II9.1所帶的SOPC Builder(可編程片上系統)可以很方便地根據自己的需要搭建出一個處理器,這個處理器的內核就是Nios II處理器,而外圍可以根據自己的需要添加任何需要的外設,包括定時器、PIO口、ROM、FLASH等。同時,通過NiosII-IDE可以將μC/OS-II實時操作系統移植到以Nios II為內核的處理器上,為測試提供了很大便利。而處理器和所設計的硬件電路可以通過已經設計好的AVALON總線來進行通信,而不用自己單獨去研究一套新的通信協議來進行軟硬件之間的通信。測試采用的是Altera提供的DE2-70開發板。
1.2混合式實時操作系統的整體架構
通過對μC/OS-II系統進行深入分析、分離可以用硬件實現的部分,設計出對應的硬件電路,然后通過AVALON總線實現軟件內核和硬件電路之間的通信,同時保證修改后的系統對用戶來說是透明的。具體框圖如圖1所示。
圖1 混合式實時操作系統整體框圖
圖1中的CPU是通過Quartus II軟件中的SOPC Builder根據需要搭建的處理器[3],搭建好的處理器作為一個單獨的底層模塊,然后再將軟件操作系統中可以硬化的部分設計成硬件邏輯電路,作為另一個底層模塊,最后在頂層模塊中對搭建的處理器和硬件邏輯電路進行例化,組成一個完整的模塊,下載到DE2-70開發板上進行測試。
2信號量管理軟件部分
2.1信號量簡介
操作系統必須具有對任務運行進行協調的能力,從而使任務之間可以無沖突、流暢地同步運行,而不致產生災難性的后果。計算機系統是依靠任務之間的良好通信來保證任務與任務的同步的。在μC/OS-II中,使用信號量、消息郵箱、消息隊和信號量集來實現任務之間的通信,而信號量就是用于任務間通信的一類事件。通過使用信號量可以給共享資源設置一個標志,這個標志可以控制共享資源的占用情況。
μC/OS-II的信號量由兩部分組成:①信號量的計數值,這個值是一個十六位的無符號整數;②任務等待表,該任務等待表是一個長度為64位的整型數組,每一位代表一個任務,若任務處于等待該信號量的狀態,那么對應位為1,否則為0。
μC/OS-II中信號量的工作原理:每當有任務申請信號量時,如果信號量計數器OSEventCnt的值大于0,則OSEventCnt減1并使任務繼續運行;如果OSEventCnt的值為0,則將任務列入任務等待表OSEventTbl[],從而使任務處于等待狀態。如果有正在使用信號量的任務釋放了該信號量,則會在任務等待表中找出優先級別最高的等待任務,使它就緒后調用調度器引發一次調度;如果任務等待表中已經沒有等待任務,則信號量計數器加1。信號量工作原理圖如圖2和圖3所示。
圖2 任務請求信號量
圖3 任務發送信號量
2.2事件控制塊ECB
圖4 事件控制塊結構圖
為了對任務之間用于通信的事件進行統一管理,μC/OS-II定義了一個叫做事件控制塊的數據結構(ECB)[4],ECB可以用來描述信號量、消息郵箱、消息隊列等事件。ECB結構如圖4所示。用戶應用程序的任務通過指針pEvent來訪問事件控制塊。成員OSEventCnt為信號量的計數器;OSEventPtr主要用來存放消息郵箱或消息隊列的指針;OSEventTbl[OS_EVENT_TBL_SIZE]是任務等待表;OSEventGrp表示任務等待表中的各任務組是否存在等待任務;OSEventType是事件的類型,它可以是信號量、消息郵箱或消息隊列。用戶要根據該域的具體值來調用相應的系統函數,以保證對其操作的正確性。
3混合式實時操作系統信號量管理的硬件設計
3.1軟件部分修改
通過分析,在保證對用戶透明的條件下,可以對事件控制塊中的任務等待表進行硬件化設計[5],那么成員OSEventGrp、OSEventTbl就可以去掉,因為使用軟件進行查表和寫表操作是比較費時的,尤其是進行表的遍歷更加費時。如果將表相關的操作轉移到硬件電路中,軟件只是負責發送指令或者讀取,不僅可以提高效率,還可以降低內存占用、減輕CPU的負擔。
在硬件設計中不能動態地添加或者刪除存儲表,如果用硬件來實現任務等待表,就必須在初始化的時候就建立與事件控制塊對應數目的任務等待表。通過對μC/OS-II系統進行分析發現,事件控制塊的最大數目是確定的,這為實現任務等待表硬件化設計提供了前提。在硬件化設計時可以直接建立與事件控制塊數目相同的任務等待表——[63∶0]TaskWaitTbl[0DK]∶EVENT_COUNT_MAX]。同時,為了能夠將軟件中修改后的事件控制塊和硬件中的任務等待表之間建立一一對應的關系,在事件控制塊數據結構中添加一個INT8U類型的變量OSEventCode來為任務控制塊進行編號,這個編號將作為與硬件中的任務進行關聯的標識碼。修改后的事件控制塊結構如下所示:
typedef stmct{
INT8UOSEventType;
INT16UOSEventCnt;
void *OSEventPtr;
INT8UOSEventCode;
}OS_EVENT;
在μC/OS-II系統進行初始化的時候會調用事件控制塊初始化函數,通過修改該函數來完成對事件控制塊的編號,然后對表的各種操作進行編碼,當軟件需要操作任務等待表的時候,向硬件發送編好號的命令碼,最后硬件部分完成對任務等待表的各種操作。信號量管理整體結構如圖5所示。
圖5 信號量管理硬件化設計整體框圖
3.2硬件部分設計
硬件部分主要是根據軟件發送的命令碼對任務等待表進行相應的操作。命令碼編碼如下:
001為初始化對應的任務控制塊;010為使對應的任務等待表的相應位置1;011為使對應的任務等待表的相應位置0;100為讀取相應的任務等待表中最高優先級等待任務的優先級;101為讀取相應的等待表中是否有等待任務;110為讀取相應的任務等待表中指定位置數據。
硬件部分整體設計圖如圖6所示。
圖6 信號量管理硬件邏輯框圖
其中,OSEvent_ctrWord為命令字,由軟件寫入到硬件,經過指令譯碼器譯碼后對任務等待表進行相應的操作;OSEvent_tabCode為事件控制塊的編號,此編號使得事件控制塊和相應的任務等待表關聯起來;OSEvent_prio_in為任務的優先級輸入,任務等待表的各個位對應著任務的優先級,從而可以根據優先級來確定對任務等待表的哪一個位進行操作;OSEvent_prio_out為優先級的輸出,主要是輸出任務等待表中最高優先級等待任務對應的優先級,軟件部分可以發送命令碼并讀取該值;OSEvent_isWait主要是輸出當前任務等待表中是否有等待任務;OSEvent_Wait用于讀取任務等待表中對應位的數據。
4系統測試與結果
測試平臺為Altera公司的DE2-70開發板,將硬件系統下載到開發板上,然后利用NiosII-IDE軟件寫出測試程序[6],選擇μC/OS-II操作系統,完成對系統的測試。程序運行結果如下所示:
Hello from prio:1
Hello from prio:3
task3 running count is 1
Hello from prio:3
task3 running count is 2
Hello from prio:1
Hello from prio:3
task3 running count is 3
Hello from prio:3
task3 running count is 4
Hello from prio:1
Hello from prio:3
task3 running count is 5
Hello from prio:1
fun is running!
Hello from prio:3
task3 running count is 6
Hello from prio:3
task3 running count is 7
Hello from prio:1
Hello from prio:3
task3 running count is 8
Hello from prio:3
task3 running count is 9
測試程序:首先創建任務1(task1,優先級為1),在任務1中創建任務2(task2,優先級為2)和任務3(task3,優先級為3)。task1創建task2和task3后是一個無限循環語句,循環體中主要輸出當前運行任務的優先級,即表示task1是不是運行成功;task2是一個無限循環體,每隔2 s請求一次信號量,如果請求成功就調用fun()函數,fun()函數輸出“fun is running!”,如果請求不成功則任務2添加到任務等待表中,直到信號量有效再運行;task3每隔3 s 運行一次,當task3運行5次的時候,發送信號量。從結果可以看出,當task3運行5次之后fun()函數調用成功,說明系統測試通過。
結語
參考文獻
[1] 任哲.嵌入式實時操作系統μC/OS-II原理及應用[M] .北京:北京航空航天大學出版社,2012:116-140.
[2] 潘松,黃繼業,潘明.EDA技術實用教程——VerilogHDL版[M] .5版.北京:科學出版社,2013:58-89.
[3] 周立功.SOPC嵌入式系統基礎教程[M] .北京:北京航空航天大學出版社,2006:57-92.
[4] 譚浩強.C程序設計[M] .3版.北京:清華大學出版社,2009:281-318.
[5] 崔曉英.基于FPGA的硬件實時操作系統的設計[D] .哈爾濱:哈爾濱理工大學,2010.
[6] 崔建華,孫紅勝,王保進.硬件實時操作系統的設計與實現[J] .電子技術應用,2008(5).
高承(碩士研究生),主要研究方向為嵌入式與操作系統應用。
(責任編輯:薛士然收修改稿日期:2015-11-25)
Hardware Circuit Design of Semaphore Management Based on FPGA
Gao Cheng,Wang Zhengyan
(Qingdao University,Qingdao 266071,China)
Abstract:Based on the communication research of the tasks in the embedded real-time operating system μC/OS-II,a scheme is proposed, that the semaphore management is completed using the hardware circuit based on FPGA.At the same time,the new hybrid real-time operating system is transparent to the users,which ensures the portability of the hybrid real-time operating system.The hybrid real-time operating system has been successfully transplanted to Altera DE2-70 development board,and the test of semaphore management is completed.This is an exploratory design,and it is an important part in overall design of the hybrid embedded real-time operating system.
Key words:RTOS;FPGA;Nios II;semaphore
中圖分類號:TP316.2
文獻標識碼:A