《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > 硬件實時操作系統(tǒng)信號量管理的設計與實現(xiàn)
硬件實時操作系統(tǒng)信號量管理的設計與實現(xiàn)
來源:電子技術應用2010年第11期
李 巖,谷萍萍
(哈爾濱理工大學 計算機科學與技術學院,黑龍江 哈爾濱 150080)
摘要: 信號量管理是操作系統(tǒng)中頻繁運行的程序段之一。為提高實時操作系統(tǒng)RTOS的響應能力,提出了基于FPGA硬件實現(xiàn)信號量管理的設計方案。采用片內(nèi)寄存器實現(xiàn)事件控制塊(ECB)、映射表等存儲結(jié)構(gòu),使用組合邏輯電路實現(xiàn)信號量管理模塊,提高了信號量創(chuàng)建、刪除及P/V操作的執(zhí)行速度。
中圖分類號: TP316.2
文獻標識碼: A
文章編號: 0258-7998(2010)11-0048-04
Design and realization of semaphore management in hardware RTOS
LI Yan,Gu Ping Ping
Harbin University of Science and Technology,Harbin 150080,China
Abstract: The semaphore management is a program segment which runs frequently in the operating system, in order to enhance the response capability of the real-time operating system RTOS, the design solution that implement the semaphore management based on FPGA is put forward. The storage structure, event control block(ECB) and mapping table, are realized by on-chip registers; The semaphore management is realized by combinational logic circuit; Both of them bring about high speed in creating semaphore, deleting semaphore and P/V operations.
Key words : hardware real-time operating system;semaphore management;ECB;FPGA

    隨著嵌入式技術的發(fā)展,實時操作系統(tǒng)RTOS(Real Time Operating System)被越來越多地應用在嵌入式系統(tǒng)中,但是對現(xiàn)有基于軟件實現(xiàn)的RTOS,單純依靠改進調(diào)度算法已經(jīng)不能使系統(tǒng)的實時性有很大提高。為提高系統(tǒng)的響應能力,國內(nèi)外一些研究機構(gòu)提出RTOS硬化的方法,并開始做這方面的研究工作[1]。目前,軟件硬化常用的有兩種方法:(1)微程序方式,特點是成本較低,方便靈活;(2)組合邏輯方式,特點是速度快、可靠性高,隨著大規(guī)模集成電路的發(fā)展,這種方式逐漸顯示出優(yōu)越性[2]。信號量管理是RTOS中頻繁運行的程序段之一,如果將這一部分用硬件實現(xiàn),對提高機器的速度將有很明顯的效果。本文采用組合邏輯方式參照uC/OS-II將信號量管理及ECB管理硬化到一片芯片上,作為獨立的模塊與處理器并行工作。
1 信號量管理的工作原理
     uC/OS-II中信號量主要數(shù)據(jù)結(jié)構(gòu)由兩部分組成:(1)信號量的計數(shù)值Cnt。當數(shù)值為正時用于記錄可使用的資源數(shù),當數(shù)值為負,其絕對值表示等待當前信號量的任務個數(shù);(2)等待該信號量的任務列表。信號量的基本數(shù)據(jù)結(jié)構(gòu)需要申請一個ECB來存儲。一個任務或ISR可以通過ECB向另外的任務發(fā)信號,一個任務可以等待另一個任務或中斷服務子程序給它發(fā)送信號,多個任務可同時等待同一個事件的發(fā)生[3]。當事件發(fā)生后,等待該事件的優(yōu)先級最高的任務進入就緒狀態(tài),觸發(fā)一次任務調(diào)度[3]。任務或者中斷服務子程序都可以給ECB發(fā)信號,對ECB進行操作。
    信號量管理的工作原理框圖如圖1所示。信號量管理模塊以及事件控制塊管理都是獨立于CPU的邏輯結(jié)構(gòu),都可以直接從數(shù)據(jù)總線上獲得數(shù)據(jù)信息進行處理,在信號量管理模塊與ECB的存儲模塊間建立一條數(shù)據(jù)通路,在不增加總線負擔的情況下加快二者間的通信。這些硬件邏輯獨立于CPU工作,減少了CPU的工作,從而提高系統(tǒng)的響應能力。

2 信號量管理的硬件設計與實現(xiàn)
2.1 ECB的設計與實現(xiàn)

    ECB是實現(xiàn)信號量管理的基本數(shù)據(jù)結(jié)構(gòu),因此在設計實現(xiàn)信號量管理之前,要先完成ECB管理的設計與實現(xiàn)。本系統(tǒng)中ECB的結(jié)構(gòu)參照μC/OS-II中ECB的結(jié)構(gòu)設計。每個ECB存儲單元包含一個EventType(事件類型),用于標記當前ECB被分配給信號量、互斥型信號量、郵箱還是消息隊列;當一個ECB被分配給信號量時,Cnt做為信號量的計數(shù)器;ECB中的等待表lut用于存儲等待當前信號量任務的優(yōu)先級(μC/OS-II中沒有兩個任務有相同的優(yōu)先級)[3]。
    ECB中等待表硬件實現(xiàn)的結(jié)構(gòu)示意圖如圖2所示。等待表的結(jié)構(gòu)類似一個8行8列的矩陣,存儲單元編號從00~77。當一個任務在申請當前信號量而沒有獲得時,應將當前任務設置為等待狀態(tài),令Wr有效,以申請該信號量任務的優(yōu)先級為地址,進行譯碼,選通相應單元后再進行寫1操作。例如,申請該信號量的任務優(yōu)先級Sid為111111時,對其進行譯碼,高三位行地址譯碼為10000000,低三位列地址譯碼為10000000,選中77單元向其寫入1,則優(yōu)先級為111111的任務進入等待狀態(tài)。若要將一個處于等待表中的任務刪除,令De有效,同樣,根據(jù)地址線選通某一存儲單元,向單元內(nèi)寫0,從而刪除某一處于等待狀態(tài)的任務。在控制電路中設置EventGrp 8位寄存器,用于記錄當前各行中是否有等待任務;如圖2所示,第i行中某一位置為1,EventGrp(i)=1,圖中狀態(tài)EventGrp(7)=1、EventGrp(6)=1、EventGrp(0)=0。Rd有效時,控制電路根據(jù)EventGrp采用一定算法生成優(yōu)先級的高三位;根據(jù)EventGrp讀出某行后生成優(yōu)先級低三位;下一時鐘送出最高優(yōu)先級。以上為對等待表進行基本讀寫操作的過程。

    該硬件系統(tǒng)中ECB基本存儲單元通過調(diào)用系統(tǒng)的IP核來實現(xiàn),根據(jù)存儲數(shù)據(jù)的不同,采用不同的IP核;多個基本單元通過一個上層文件生成一個ECB單元,每個單元再作為一個基本器件用于實現(xiàn)整個ECB的存儲體。通過地址的譯碼選通ECB單元,根據(jù)控制信號對數(shù)據(jù)做讀寫操作。
2.2 創(chuàng)建/刪除一個信號量
    ECB是公共數(shù)據(jù)結(jié)構(gòu),在傳統(tǒng)的操作系統(tǒng)中創(chuàng)建一個信號量時,首先需要申請一個ECB,初始化后才可以對這個信號量進行P/V等操作;在刪除一個信號量后,要對信號量占用的ECB進行釋放。創(chuàng)建信號量時,信號量管理模塊首先要申請一個空ECB,查找ECB的整個存儲體判斷是否有空余的ECB。如果沒有空余ECB,則信號量管理模塊將獲得一個申請失敗信號;否則將獲得一個空ECB的地址,并將其返回給創(chuàng)建該信號量的任務;再根據(jù)地址初始化ECB[3]。如果用硬件實現(xiàn)信號量管理后,按照以上過程進行操作會浪費很多時鐘,數(shù)據(jù)在模塊間來回傳送增加通信次數(shù),必然降低系統(tǒng)的執(zhí)行速度。針對這個問題,提出了在信號量管理模塊中設置一個用于記錄ECB使用情況的映射表,如圖3所示。為方便討論,假設系統(tǒng)中ECB有64個(可以根據(jù)系統(tǒng)中ECB的個數(shù)來改變表的大小),表的每個位置對應一個ECB,當某一位置為0時表示該位置對應的ECB空閑,為1時表示該位置對應的ECB被占用。如圖3所示,第1行、第8列為1,表示偏移地址為000111的ECB被占用;第2行、第2 列為1,偏移地址為010010的ECB被占用。

    在創(chuàng)建一個信號量時,查找ECB映射表,判斷是否有為0的位置。如果沒有則返回申請失敗;否則尋找一個為0的位置,生成ECB的地址,返回給創(chuàng)建該信號量的任務。在映射表中相應位置寫1表明該ECB已經(jīng)被占用,下一時鐘對申請到的ECB進行初始化,寫入信號量初始值。在刪除一個信號量時,首先根據(jù)信號量的ECB地址查詢映射表中對應位置是否為0,如果為0,則表示該信號量已經(jīng)被其他任務刪除,返回刪除錯誤;否則清除該信號量在映射表中的記錄,通知ECB管理模塊將等待該信號的所有任務置為就緒態(tài),觸發(fā)一次任務調(diào)度,清除ECB中的該信號量的所有信息。以上過程中不需要頻繁地去ECB管理模塊中進行整體查詢,因此節(jié)省了大量的通信時間。
2.3 申請/釋放一個信號量(P/V操作)
    信號量管理中的主要操作就是P/V操作,P/V操作實現(xiàn)的RTL圖如圖4所示。

    (1)P操作(申請某個信號量)。令pend_sem有效,首先應判斷申請信號量的任務是否為中斷服務程序(在μC/OS-II中,中斷服務程序不允許申請一個信號量),如果是則返回申請錯誤信息(pend_err為高),否則進行以下操作:令read_cnt有效去ECB管理模塊讀Cnt值;讀回后判斷Cnt的值。如果Cnt>0,當前申請任務獲得該信號量,任務繼續(xù)執(zhí)行,返回申請成功信號pend_err為低;否則pend_err為高阻,根據(jù)申請類型Pend_type(申請類型在μC/OS-II中分為有等待申請和無等待申請)來決定是否修改Cnt值,是否將申請信號量的任務置為等待態(tài)。
    (2)V操作(釋放某個信號量)。令post_sem有效,通過硬件電路使read_cnt有效,同時給出信號量的ECB地址,下一時鐘讀出Cnt值,并判斷;如果Cnt>0則表示沒有任務等待當前信號量,修改Cnt值;如果Cnt<0則表示當前有任務等待該信號量,修改Cnt值,令select_h有效,從ECB任務等待表中找出優(yōu)先級最高的任務,通知任務管理器將該任務置為就緒態(tài),觸發(fā)一次任務調(diào)度。
3 功能仿真
    為驗證設計對系統(tǒng)性能的影響,采用ISE 8.2軟件對各個模塊進行時序仿真。P/V操作仿真結(jié)果如圖5所示。P/V操作需要在兩個模塊之間進行讀寫數(shù)據(jù),操作過程中,P/V信號始終有效。

    (1)pend_sem有效(P操作)。申請信號量任務的優(yōu)先級為01,申請信號量的地址為05。pend_sem有效,令read_cnt為高,根據(jù)地址pend_addr讀當前信號量的值Cnt,下一個時鐘返回數(shù)值Cnt_in為0002,大于0;任務獲得信號量繼續(xù)執(zhí)行,wr_cnt為高,Cnt值進行減1操作后送Cnt_out寫回ECB。
    (2)post_sem有效(V操作)。根據(jù)地址讀Cnt值,Cnt值為FFFE<0(Cnt值以補碼形式存儲)。下一個時鐘Cnt進行加1操作后寫回ECB,同時Select_h為高,從等待該信號量的任務列表中選擇出優(yōu)先級最高的任務設置為就緒態(tài),觸發(fā)一次任務調(diào)度。
    (3)申請一個信號量。申請信號量任務的優(yōu)先級為03,申請的信號量的地址為09。如果下一個時鐘讀回的Cnt值為FFFD<0,并且申請類型為高(有等待申請),則修改Cnt值寫回,令wr_sid為高,將當前申請任務的優(yōu)先級送pend_prio_out寫入等待該信號的任務列表中。如果pend_err為高,則通知任務管理器將當前申請信號量的任務阻塞,并觸發(fā)一次任務調(diào)度。
    (4)申請一個信號量,讀回的Cnt值為FFFA<0,但當前申請類型為低(無等待申請),不進行任何操作,返回申請失敗,通知任務管理器將當前任務阻塞。
    用戶程序在創(chuàng)建、刪除一個信號量以及申請某類共享資源進行P/V操作時,用軟件實現(xiàn)信號量管理中,一般先從用戶態(tài)轉(zhuǎn)到系統(tǒng)態(tài),然后進行基本數(shù)據(jù)的查詢、讀出、比較、判斷等,再轉(zhuǎn)相應的程序入口,最后還要從系統(tǒng)態(tài)轉(zhuǎn)回用戶態(tài)。而用硬件實現(xiàn)信號量管理后進行以上操作只需一條讀或?qū)懼噶?,并且這條指令在用軟件實現(xiàn)的信號量管理中也是必須的,其他操作都由硬件邏輯來實現(xiàn),簡化了操作過程。從仿真結(jié)果看,進行P/V操作時只需要3個時鐘節(jié)拍,整體的執(zhí)行速度遠遠高于軟件。同時,RTOS中信號量的個數(shù)為多個,信號量管理在RTOS中頻繁運行。因此,硬化信號量管理后對整個機器速度的提高是非常明顯的,特別是對資源種類多、數(shù)量大的計算機系統(tǒng),速度的提高就會更加明顯。另一方面,由于硬件的可靠性遠超過軟件的可靠性,所以硬化后可提高RTOS的可靠性。
參考文獻
[1] 崔建華,孫紅勝,王保進.硬件實時操作系統(tǒng)的設計與實現(xiàn)[J].計算機技術應用,2008(5):34-37.
[2] 屈玉貴,趙保華,森下嚴.操作系統(tǒng)中信號量管理的固化[J].計算機應用與軟件,1990(06):29-33.
[3] LABROSSE J J.嵌入式實時操作系統(tǒng)&mu;C/OS-Ⅱ[M].邵貝貝譯.北京:北京航空航天大學出版社,2001:156-176
 

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權禁止轉(zhuǎn)載。