<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 嵌入式系統 > 設計應用 > 基于PCIe總線(xiàn)的多路復用DMA高速傳輸系統的設計

基于PCIe總線(xiàn)的多路復用DMA高速傳輸系統的設計

作者: 時(shí)間:2016-09-12 來(lái)源:網(wǎng)絡(luò ) 收藏

其次,需要解決DMA通道的使用分配。在多線(xiàn)程機制下對DMA通道請求隊列的管理有2種方案,隊列管理方案如圖4所示。

e.jpg

在方案一中,每個(gè)的線(xiàn)程把自己的DMA請求(DMA_Req)放入DMA請求隊列(DAM_Queue)中,Oueue Read負責從隊列中取出DMA請求。在此使用鎖機制,將隊列寫(xiě)操作作為臨界區,在鎖定的臨界區只允許讓一個(gè)線(xiàn)程訪(fǎng)問(wèn),其它線(xiàn)程排隊等待。這樣的方案設計簡(jiǎn)單易懂好管理,然而在實(shí)際的測試中,由于線(xiàn)程資源及調度是由操作系統來(lái)完成的,測試結果表明各個(gè)通道的DMA_Req并不能公平地寫(xiě)入隊列,DMA物理通道并不能公平的服務(wù)于每一路,導致了各個(gè)通道間傳輸速率不均衡。

在方案二中,各個(gè)把自己的DMAReq寫(xiě)入自己的DMA_Queue中,Queue_Read通過(guò)輪詢(xún)的方式讀取各個(gè)DMA_Queue的DMA 請求,測試結果表明DMA物理通道資源能被公平的分配且請求處理效率更高。因此傳輸系統的DMA請求隊列管理采用方案二實(shí)現。

3.2.3 系統通信模塊

主機與從機兩個(gè)處理器系統天然的分離特性,使得性能與正確性產(chǎn)生矛盾,如果兩端的消息通信只是簡(jiǎn)單的發(fā)送/接收和處理,不能保證兩端不同時(shí)使用同一資源。因此為傳輸系統規定了一個(gè)有順序語(yǔ)義的通信機制如圖5所示。

f.jpg

圖5中黑色箭頭表示的是程序的執行順序,白色部分代表了對主機端消息的處理,黑色部分代表了對從機端消息的處理。主從機端皆有一個(gè)消息隊列,所有需要發(fā)送的消息(msgQ)都先存入消息隊列中,主機和從機端通過(guò)令牌機制來(lái)輪流向對方遞送消息。如果一方消息隊列為空,也需要讓度令牌,使得對方能繼續遞送消息。以主機機端為例,其消息處理過(guò)程如下:(1)等待從機端發(fā)送讓度令牌的消息Ack;(2)收到Ack后接收從機端的發(fā)送的消息Req;(3)對消息進(jìn)行處理并且準備要發(fā)送給對方的Ack和從消息隊列中取出msgQ(若消息隊列為空,則填入NULL);(4)向對方發(fā)送Ack和msgQ。從機端的消息處理與主機端是一一對應的。

系統中使用NT橋的8個(gè)32位的MailBox寄存器來(lái)實(shí)現主從機的消息通信,MailBox寄存器是NT橋的鏈路端口和虛擬端口共有的,都可見(jiàn)可讀可寫(xiě)。

令牌跳躍式的消息傳遞機制是否會(huì )成為整個(gè)傳輸系統提升傳輸速率的瓶頸,將在下文的實(shí)驗測試中給出結論。

3.2.4 客戶(hù)端通信模塊

使用“Abstract”樣式。為了提供一個(gè)簡(jiǎn)易通用的客戶(hù)端接口,Plx_Server和Client_Register的進(jìn)程間通信使用Socket實(shí)現。傳輸系統的主程序Plx_Server通過(guò)創(chuàng )建服務(wù)器(Server Socket)未向連接服務(wù)器的客戶(hù)端(Client Register)提供服務(wù)。服務(wù)包括了數據收發(fā)請求,連接建立/端開(kāi)請求等。Plx_Server處理Client_Register連接請求的流程如圖6所示。

g.jpg

在圖6中客戶(hù)端的連接注冊、客戶(hù)端配對和建立傳輸通道都是由主機端完成的,從機端的連接注冊需要交付給主機端來(lái)完成。

3.2.5 客戶(hù)端API

調用客戶(hù)端API(Client_Register)完成連接配對請求后,Client_Register將返回一個(gè)Socket描述符。用戶(hù)只需要參考標準Socket編程規范,即可使用Socket標準函數接口,比如read、write、close等進(jìn)行數據通信。

4 系統性能優(yōu)化分析

為滿(mǎn)足視頻轉碼設備對數據傳輸性能的要求,傳輸系統除了要滿(mǎn)足傳輸速率、速率均衡的要求外,CPU資源使用率也要作為考慮的因素。在測試中當處理器系統的 CPU使用率超過(guò)50%后,傳輸系統的總帶寬隨之下降。為此,傳輸系統做了以下優(yōu)化:(1)設置Plx_Server的CPU相關(guān)性,使進(jìn)程同時(shí)關(guān)聯(lián)多個(gè) CPU;(2)線(xiàn)程在等待或空閑時(shí)適當掛起以釋放占用的CPU資源。

5 實(shí)驗結果分析

本傳輸系統結合視頻轉碼設備的使用做了大量的測試,首先測試傳輸系統數據傳輸帶寬,測試結果如圖7所示。實(shí)驗結果表明了系統傳輸性能穩定,傳輸總帶寬約為1100MB /s。隨著(zhù)傳輸通道數的增加,每一對正在傳輸的通道將重新公平分配資源,分配到的資源將減少,使得單路傳輸帶寬將減小,但總帶寬基本保持不變。

h.jpg

另外驗證傳輸系統消息通信機制是否會(huì )成為限制傳輸速率的瓶頸。測試數據如表2所示。傳輸系統最少每秒可發(fā)送/接收一共1776個(gè)消息,完成一次傳輸(每次 可發(fā)送4MB大小數據)一共需要發(fā)送/接收5個(gè)消息,則經(jīng)換算傳輸系統消息通信帶寬為1776/5x4=2220MB/s,遠遠超過(guò)了傳輸系統數據傳輸總帶寬,不會(huì )成為限制傳輸速率的瓶頸。

i.jpg

在處理器型號為Intel Core i5系列,雙核4線(xiàn)程的主機上運行傳輸系統進(jìn)程時(shí),進(jìn)程對主機CPU使用率低于20%,這使得主機在使用從機(視頻轉碼設備)時(shí)還有足夠的余力處理其它任務(wù)。

6 結語(yǔ)

本文基于PEx8619的PCIe接口芯片完成了跨PCIe NT橋的傳輸系統的設計,實(shí)現了雙處理器間的多通道數據傳輸功能。經(jīng)試驗測試,傳輸系統總帶寬達到1100MB/s,實(shí)時(shí)性好,性能優(yōu)越且可移植性強,在需要高速傳輸系統的領(lǐng)域如視頻實(shí)時(shí)轉碼等有很好的應用前景。


上一頁(yè) 1 2 下一頁(yè)

關(guān)鍵詞: DMA傳輸 非透明橋 虛擬通道

評論


技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>