<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計(jì)應(yīng)用 > 高帶寬嵌入式應(yīng)用中SoC微控制器的可編程總線設(shè)計(jì)

          高帶寬嵌入式應(yīng)用中SoC微控制器的可編程總線設(shè)計(jì)

          作者: 時(shí)間:2012-02-01 來源:網(wǎng)絡(luò) 收藏

          傳統(tǒng)SoC總線架構(gòu)已不能滿足新的聯(lián)網(wǎng)嵌入式設(shè)計(jì)對(duì)數(shù)據(jù)流進(jìn)行實(shí)時(shí)控制的需求, NetSilicon開發(fā)的帶寬控制系統(tǒng)可以使多個(gè)資源同時(shí)訪問總線,使其既滿足應(yīng)用要求又不會(huì)影響其他重要操作的性能。本文將對(duì)該系統(tǒng)的帶寬分配方案進(jìn)行探討。

          32位嵌入式設(shè)計(jì)越來越要求對(duì)網(wǎng)絡(luò)上數(shù)據(jù)流進(jìn)行實(shí)時(shí)控制,特別是在系統(tǒng)級(jí)芯片(SoC)層面,以確定性和無爭議的方式傳輸數(shù)據(jù)和控制信息變得非常重要。各種操作直接處于系統(tǒng)開發(fā)者既定的控制之下也很重要,而這在基于總線的SoC設(shè)計(jì)中并不總是能夠?qū)崿F(xiàn)。

          設(shè)計(jì)者和芯片供應(yīng)商常常借鑒板級(jí)及系統(tǒng)級(jí)架構(gòu)技術(shù),以便在最短的設(shè)計(jì)時(shí)間內(nèi)以最低的開發(fā)成本進(jìn)行SoC設(shè)計(jì)。由于手機(jī)和PDA等設(shè)備對(duì)確定性的實(shí)時(shí)響應(yīng)需求很少,所以傳統(tǒng)解決方案在此類應(yīng)用中表現(xiàn)還不錯(cuò)。

          但在許多新的聯(lián)網(wǎng)嵌入式設(shè)計(jì)中,傳統(tǒng)總線架構(gòu)不能滿足共享總線對(duì)及高密度數(shù)據(jù)流的需求,在下列應(yīng)用中尤其如此,如工業(yè)用人機(jī)界面(HMI)網(wǎng)絡(luò)顯示、POS終端設(shè)備,具有不同數(shù)據(jù)帶寬需求的彩色打印機(jī)、網(wǎng)絡(luò)投影儀和監(jiān)視攝像機(jī),以及網(wǎng)絡(luò)打印機(jī)、數(shù)字復(fù)印機(jī)、多功能一體機(jī)、傳真機(jī)和掃描儀等。

          許多基于片上串行互連的替代方案正在研發(fā)中,這些替代方案類似于串行結(jié)構(gòu)、交叉交換(crossbar switch)和基于數(shù)據(jù)包的總線。在這些新方案得以完善之前,鑒于時(shí)間和成本壓力,必須找到能修改從板級(jí)設(shè)計(jì)借鑒過來的共享總線架構(gòu)的方法,以滿足新的32位嵌入式聯(lián)網(wǎng)設(shè)計(jì)對(duì)確定性和實(shí)時(shí)性的要求。

          傳統(tǒng)SoC總線的優(yōu)缺點(diǎn)

          SoC開發(fā)者不愿意放棄這種通用共享總線,因?yàn)樗梢詼p少設(shè)計(jì)周期中的規(guī)范制定及驗(yàn)證工作,能使SoC的高層次集成如同將擴(kuò)展卡插到背板上一樣簡單。通過采用通用總線,開發(fā)者可以集中精力投入到更高層次的決策中。

          圖1:NS9xxx的帶寬控制系統(tǒng)。

          ARM公司在高級(jí)微控制器總線架構(gòu)(AMBA)中采用通用總線,允許獲得許可的使用者專注于自己的應(yīng)用開發(fā),從而快速將產(chǎn)品推向市場(chǎng)。

          微處理器、 DMA控制器、存儲(chǔ)器控制器及其它更高性能的模塊通過AHB連接。性能較低的模塊,比如UART、通用輸入/輸出(GPIO)及定時(shí)器等,則通過APB連接。

          但是,基于ARM的SoC所瞄準(zhǔn)的許多高端嵌入式應(yīng)用,要求它們?cè)谔幚磉@些應(yīng)用的確定性與實(shí)時(shí)性需求的同時(shí),還可以訪問高帶寬網(wǎng)絡(luò)環(huán)境。

          這些應(yīng)用要求SoC能夠發(fā)出控制信號(hào)、采集數(shù)據(jù)并在網(wǎng)絡(luò)上實(shí)時(shí)傳輸數(shù)據(jù)。基于不同的網(wǎng)絡(luò)特性及其帶寬要求,現(xiàn)有SoC總線架構(gòu)的性能將會(huì)得到盡可能的提升,例如,高端聯(lián)網(wǎng)嵌入式應(yīng)用可能要處理通過以太網(wǎng)連接從照相機(jī)傳輸?shù)酱蛴C(jī)的視頻數(shù)據(jù)位流,或從服務(wù)器傳輸?shù)酱蛴C(jī)的圖像,與此同時(shí)還可能根據(jù)與掃描、刷新和更新周期有關(guān)的確切要求對(duì)本地 LCD顯示進(jìn)行更新。使用外部LCD時(shí),LCD控制器必須知道通過該總線傳輸?shù)木唧w字節(jié)數(shù)量、數(shù)據(jù)發(fā)送順序以及數(shù)據(jù)在顯示器上顯示的特定時(shí)隙和順序,同時(shí)也很必要將信息不斷地饋送給LCD用于更新。

          圖2: NS9750原理框圖。

          共享總線的概念并不能滿足SoC中的這些要求。在典型的AHB設(shè)計(jì)中,總線主控是總線上全部的主要資源,也就是說,當(dāng)總線空閑時(shí),它們可向總線請(qǐng)求完成一個(gè)任務(wù)所需要的時(shí)間。但在基于ARM的SoC中,程序設(shè)計(jì)者不能直接控制當(dāng)它們掌管總線時(shí)可得到多少總線資源。

          共享總線架構(gòu)用多種方式來區(qū)分這些操作的優(yōu)先次序,包括:菊花鏈仲裁、集中式并行仲裁、基于自選或沖突監(jiān)測(cè)的分布式仲裁以及帶多個(gè)總線請(qǐng)求的總線仲裁。但當(dāng)指定的主控接管總線后,其他操作就會(huì)擱置在一邊。目前還沒有一種機(jī)制能夠讓多個(gè)資源同時(shí)訪問總線,使其既滿足應(yīng)用要求,又不會(huì)影響其他重要操作提供確定性及實(shí)時(shí)性響應(yīng)的能力。

          在AMBA環(huán)境中處理這類情況的一種通用方法是使用仲裁通道。如果有六個(gè)總線主控,總線便設(shè)計(jì)成有六個(gè)仲裁通道。但是,片上仲裁邏輯根據(jù)請(qǐng)求訪問該總線的主控?cái)?shù)目來分配這些通道,而不是把每個(gè)通道指定給某個(gè)特定的主控。如果有四個(gè)主控請(qǐng)求訪問總線,則這六個(gè)通道會(huì)在這四個(gè)主控之間進(jìn)行分配,確保每個(gè)主控有平等的機(jī)會(huì)訪問該總線。

          然而,這并不能解決如何分配足夠的總線帶寬以完成某一特定任務(wù)這一基本問題。若其中一個(gè)操作需要三個(gè)通道,而其它操作總共只需要兩個(gè)通道,則每一種操作將會(huì)分配到相同數(shù)量的可用通道空間。其結(jié)果是,有的通道沒有充分利用(甚至根本沒用到),而有的則超負(fù)荷使用,影響SoC在極低延遲內(nèi)對(duì)事件進(jìn)行確定性響應(yīng)的能力。

          帶寬控制系統(tǒng)

          因此,需要一種可編程的總線帶寬分配方案,在某一特定時(shí)刻為某一特定的主控分配其所需的總線配置,并將剩余的總線空間分配給其它可能要求訪問該總線的主控。由于這種方案可能隨時(shí)間改變,因此需要一種機(jī)制以便按照常規(guī)原理重新分配總線資源。

          NetSilicon公司已開發(fā)一種新的帶寬控制系統(tǒng)來取代采用AMBA架構(gòu)的帶寬控制系統(tǒng)。該系統(tǒng)采用一個(gè)16槽位旋轉(zhuǎn)優(yōu)先級(jí)總線仲裁器(見圖1),這種仲裁器包含一套可編程偽隨機(jī)或旋轉(zhuǎn)優(yōu)先級(jí)緩存替換算法。例如,在NetSilicon的 NS9750(見圖2)中,AHB上的六個(gè)通道不是通過競爭進(jìn)行分配,而是根據(jù)16槽位總線分配方案由六個(gè)總線主控分享。通過系統(tǒng)控制模塊中的專用寄存器,系統(tǒng)開發(fā)者目前可采用三種方法在SoC中分配總線資源。

          在最高層次,某特定總線主控每次發(fā)出的一個(gè)訪問請(qǐng)求,都會(huì)按請(qǐng)求順序得到響應(yīng),直到這六個(gè)主控全被輪詢。根據(jù)所需帶寬,每一個(gè)總線主控可分配到一定數(shù)目的槽位并獨(dú)占這些槽位。例如在NS9750中,四個(gè)槽位分配給CPU,四個(gè)槽位給以太網(wǎng),四個(gè)槽位給BBus橋,三個(gè)槽位給LCD,三個(gè)槽位給PCI/卡總線,但在系統(tǒng)運(yùn)行期間系統(tǒng)軟件會(huì)根據(jù)需要重新評(píng)估這一分配方案,這可用來確定AHB總線周期的數(shù)目。如果在下一個(gè)評(píng)估周期中情況沒有發(fā)生變化,則沿用以前的設(shè)置,如果情況有變,則協(xié)定新的總線主控槽位分配方案。

          為對(duì)總線資源進(jìn)行更精確的控制,這種循環(huán)仲裁方案提供兩個(gè)附加層次的可編程性能:分配給ARM CPU的總線帶寬大小以及這16個(gè)槽位中每個(gè)槽位的帶寬利用率。

          NS9750的ARM926EJ-S內(nèi)核作為總線主控時(shí)不能控制所有總線資源,缺省情況下它只能控制50%的總線帶寬或16個(gè)槽位中的8個(gè),這樣可確保其它五個(gè)總線主控可以一直占有至少50%的總線帶寬。不過,在程序設(shè)計(jì)者直接控制下,它可以按照指令將其部分帶寬釋放給另一個(gè)總線主控,或者,在該總線仲裁周期內(nèi)或程序設(shè)計(jì)者認(rèn)為必要的任何周期中控制另外的槽位。

          程序設(shè)計(jì)者也可為每個(gè)槽位選擇帶寬利用系數(shù)——100%、75%、50%或25%。這一選擇是通過控制何時(shí)以及以怎樣的順序分配每個(gè)槽位的訪問來實(shí)現(xiàn)的,系數(shù)為25%,則這個(gè)槽位每四個(gè)周期只能被輪詢一次;系數(shù)為50%,則每兩個(gè)周期輪詢一次;75%,則每四個(gè)周期輪詢?nèi)巍?

          對(duì)旋轉(zhuǎn)總線仲裁器進(jìn)行編程

          程序設(shè)計(jì)者可通過包含在系統(tǒng)控制模塊內(nèi)的幾個(gè)寄存器定義多種選項(xiàng)。第一個(gè)寄存器是16入口總線請(qǐng)求配置寄存器,它的每一個(gè)入口代表一個(gè)主控和一個(gè)準(zhǔn)許槽位的總線請(qǐng)求。每一個(gè)請(qǐng)求/準(zhǔn)許槽位每次只能分配給一個(gè)總線主控,但根據(jù)總線主控的帶寬要求,每個(gè)總線主控可同時(shí)連接多個(gè)請(qǐng)求/準(zhǔn)許槽位。當(dāng)多個(gè)通道分配給一個(gè)主控時(shí),這些通道應(yīng)均勻分布在這16個(gè)通道當(dāng)中。

          每個(gè)請(qǐng)求/準(zhǔn)許槽位都有一個(gè)兩位的帶寬壓縮字段(BRF),用以確定每個(gè)槽位能對(duì)系統(tǒng)總線進(jìn)行仲裁的頻率(100%、75%、50%或25%)。BRC將總線請(qǐng)求信號(hào)輸出到第二個(gè)16入口總線請(qǐng)求寄存器(BRR),默認(rèn)情況下,BRC中未被分配的槽位將阻止用任何總線請(qǐng)求信號(hào)設(shè)置相應(yīng)的BRR入口。

          第四個(gè)寄存器用于存儲(chǔ)哪個(gè)總線主控有數(shù)據(jù)在等待向AHB傳輸,而第五個(gè)寄存器則是程序設(shè)計(jì)者用來為每個(gè)總線請(qǐng)求和準(zhǔn)許槽位(分配給特定總線主控)分配權(quán)重值。

          使用循環(huán)仲裁

          圖3:NS9xxx的總線架構(gòu)

          在前面例子中,當(dāng)基于特定仲裁再分配調(diào)度方案的LCD請(qǐng)求額外的總線訪問時(shí),程序設(shè)計(jì)者可根據(jù)LCD必須處理的數(shù)據(jù)流的性質(zhì)來指定分配給LCD的優(yōu)先級(jí)。如果程序設(shè)計(jì)者認(rèn)為需要分配10個(gè)槽位給LCD控制器,剩余的6個(gè)槽位會(huì)按最初仲裁方案分配給其它總線主控。這樣LCD控制器可獲得十倍于正常情況下可得到的帶寬,以及十倍于其它主控的帶寬來處理這種特定情形下的負(fù)載。

          當(dāng)通過以太網(wǎng)連接傳送數(shù)據(jù)、同時(shí)LCD屏幕進(jìn)行刷新的時(shí)候,這種特性十分重要。LCD需要實(shí)時(shí)、準(zhǔn)確地進(jìn)行刷新,且不會(huì)被以太網(wǎng)請(qǐng)求中斷。

          在典型的AMBA總線架構(gòu)中,如果LCD對(duì)總線提出請(qǐng)求,不論有怎樣的刷新需求,它都不得不等待直到以太網(wǎng)主控將總線釋放出來。采用新的循環(huán)可編程仲裁方案,程序設(shè)計(jì)者可降低以太網(wǎng)傳輸?shù)膬?yōu)先級(jí),使數(shù)據(jù)以更低但可接受的速率傳輸,確保LCD得以適當(dāng)?shù)厮⑿露恢劣谑蛊聊怀霈F(xiàn)空白。

          如果為保證活動(dòng)畫面顯示對(duì)LCD延時(shí)和帶寬要求極高,則以太網(wǎng)協(xié)議需求還可進(jìn)一步降低傳輸速率。但停止數(shù)據(jù)流傳輸是不可以的。實(shí)際上,如果LCD主控控制了該總線并且只有當(dāng)刷新工作完成后才將總線釋放,則有可能停止數(shù)據(jù)流的傳輸。

          在外圍總線中增加突發(fā)模式DMA

          在基于AMBA的設(shè)計(jì)中,外圍總線的傳統(tǒng)設(shè)計(jì)方法是假定基于ARM內(nèi)核的嵌入式器件用于低端性能應(yīng)用。但現(xiàn)在的器件經(jīng)常需要在不切斷低帶寬外圍電路訪問總線資源的情況下,運(yùn)行一種或多種高帶寬應(yīng)用。在具有較多外圍電路的設(shè)計(jì)中,這種情況特別容易出問題。例如NS9750或NS9360,它們支持USB、I2C,具有四個(gè)多功能串行模塊(可選用UART或SPI,同步模式下的速率可達(dá)11Mbps)、50個(gè)單獨(dú)的可編程GPIO引腳、一個(gè)IEEE1284外圍端口以及16個(gè)通用定時(shí)器或計(jì)數(shù)器(每個(gè)都有自己的I/O引腳)。

          在傳統(tǒng)的APB實(shí)現(xiàn)方案中,采用FIFO就足以應(yīng)付通信外設(shè)(如UART)的低速率傳輸,F(xiàn)IFO可以在處理器必須介入并訪問APB之前將數(shù)個(gè)字節(jié)傳送到接口。但在本文所描述的許多高端嵌入式應(yīng)用中,一個(gè)或多個(gè)這樣的外圍電路可能需要高帶寬傳輸,要求能通過APB/AHB橋快速訪問主要的高性能總線。

          一種讓外圍總線工作于這種突發(fā)模式的方法,是僅用一條突發(fā)模式外圍總線(如NetSilicon的 BBUS)替代APB總線。這種突發(fā)模式外圍總線帶有四個(gè)支持突發(fā)模式的總線主控(見圖3):第一個(gè)總線主控是具有13個(gè)通道的DMA引擎,支持13個(gè)USB端點(diǎn);第二個(gè)總線主控是具有12個(gè)通道的DMA引擎,支持4個(gè)串行模塊(每個(gè)串行模塊有8個(gè)通道)和1284端口;第三個(gè)總線主控為BBUS-AHB橋,它包含一個(gè)DMA引擎,該引擎具有可訪問AHB系統(tǒng)總線的通道;第四個(gè)總線主控是一個(gè)USB宿主模塊。另外,這種DMA引擎有兩個(gè)獨(dú)立的專用DMA通道,可支持連接到外部存儲(chǔ)總線的外部設(shè)備。為簡化突發(fā)模式狀態(tài),每一個(gè)內(nèi)部DMA通道以“飛越模式”(fly-by mode)在系統(tǒng)存儲(chǔ)器及BBUS外圍電路之間傳輸數(shù)據(jù),而兩個(gè)外部DMA通道則選擇存儲(chǔ)器到存儲(chǔ)器的傳輸模式。



          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();