圖中所示為用于開發(fā)中下一級(jí)輸入的配置平臺(tái)。這里的核心思想是確定系統(tǒng)的瓶頸并執(zhí)行軟硬件劃分。該方案在進(jìn)行軟硬件劃分方面是有效并安全的，因?yàn)槠脚_(tái)提供能夠用來識(shí)別出整個(gè)系統(tǒng)瓶頸的原始統(tǒng)計(jì)信息。該階段中，實(shí)現(xiàn)了IP的功能模型，使其具備了具體的接口，并嵌入了功能性。而在軟硬件劃分階段將對(duì)該方法學(xué)中所用的方案進(jìn)行具體化。附加到該平臺(tái)上的另一個(gè)是DMA-PL080的TLM模型，下一步是用MACHWRTL替代整個(gè)MACHWSystemC功能模型，如圖2所示。整個(gè)周邊環(huán)境是一樣的，因此測試注入與其他步驟中的注入一樣。與之前環(huán)境的變化是采用了負(fù)責(zé)到信號(hào)變換的事務(wù)處理適配器。由于該系統(tǒng)基于ARM，適配器的書寫必須遵從信號(hào)級(jí)AHB總線接口。實(shí)際上，該平臺(tái)將相同的環(huán)境表征為現(xiàn)實(shí)系統(tǒng)，不過與此同時(shí)，開始面對(duì)仿真性能方面的問題。顯然，我們還不能用該配置來執(zhí)行廣泛的調(diào)試/驗(yàn)證，不過可以運(yùn)行簡單的測試(具有較短的仿真時(shí)間)。

　　圖2：從SystemCMACHW向VHDLRTLMACHW適配器的轉(zhuǎn)換。

　　由于在當(dāng)前仿真環(huán)境中發(fā)現(xiàn)瓶頸，我們對(duì)基于硬件模擬XTREME服務(wù)器的平臺(tái)進(jìn)行評(píng)估，該平臺(tái)基本提供了硬件所需的FPGA塊，并提供了軟件與整個(gè)環(huán)境的無縫集成?；赬TREME服務(wù)器中早期平臺(tái)的移植只需要很少工作量，并且相對(duì)于基于ncsim的仿真環(huán)境，實(shí)現(xiàn)了5倍的仿真速度。很顯然，這使得我們能夠調(diào)試并執(zhí)行VHDLRTL設(shè)計(jì)的驗(yàn)證，否則將會(huì)浪費(fèi)過多時(shí)間。同時(shí)，基于Xtreme服務(wù)器的平臺(tái)還提供了同等調(diào)試能力。

　　硬件/軟件劃分

　　系統(tǒng)中軟硬件劃分決策是最為重要的一個(gè)方面。之所以硬件/軟件劃分變得如此關(guān)鍵，是因?yàn)槿缦乱恍┮蛩?，如系統(tǒng)的實(shí)時(shí)處理需求，應(yīng)用軟件的存儲(chǔ)限制以及其他因素。許多時(shí)候，設(shè)計(jì)開發(fā)階段一些決策依賴于直覺判斷或者先前的經(jīng)驗(yàn)。但當(dāng)某些事情發(fā)生錯(cuò)誤時(shí)這將蘊(yùn)含一個(gè)風(fēng)險(xiǎn)。隨著系統(tǒng)復(fù)雜度以及流片成本的增加，這種決策方法可能會(huì)鑄成大錯(cuò)。強(qiáng)調(diào)需要一種有助于實(shí)現(xiàn)更好軟硬件劃分決策的方法學(xué)具有許多原因。

　　在UWBMAC系統(tǒng)開發(fā)范例中，具有很多必須很好遵守的時(shí)間約束，這是因?yàn)閼?yīng)用層完全依賴于空中——即來自射頻天線的全局廣播定時(shí)。實(shí)現(xiàn)決策的方案建立在我們從具體的系統(tǒng)級(jí)平臺(tái)的執(zhí)行中所獲取的經(jīng)驗(yàn)。我們能夠分析流水線數(shù)據(jù)通道中的數(shù)據(jù)流，能夠有效地發(fā)現(xiàn)它們是否將對(duì)系統(tǒng)構(gòu)成任何瓶頸。通常，當(dāng)系統(tǒng)中的數(shù)據(jù)流發(fā)送時(shí)，數(shù)據(jù)幀必須從MAC發(fā)送到PHY，而對(duì)于接收，所產(chǎn)生的數(shù)據(jù)幀則從PHY到MAC，并存入到存儲(chǔ)器中由軟件進(jìn)行進(jìn)一步的分析。在仿真場景分析過程中，能夠識(shí)別出是否需要在硬件中進(jìn)行一些協(xié)議解析以采取及時(shí)的措施。

　　圖3：系統(tǒng)中著重硬件支持需求的應(yīng)用場景。

　　圖3中詳細(xì)給出了一個(gè)決策范例。根據(jù)協(xié)議的需求，接收數(shù)據(jù)中有一個(gè)控制包，它通知下次發(fā)送事件的通用定時(shí)，即何時(shí)發(fā)送下一個(gè)數(shù)據(jù)包?？紤]到MAC硬件是一個(gè)典型的數(shù)據(jù)通道，并將控制幀傳送到存儲(chǔ)器中，軟件對(duì)控制幀進(jìn)行處理并決定打開發(fā)送窗口。在發(fā)送窗口打開出現(xiàn)問題時(shí)，用這種方案就能發(fā)現(xiàn)瓶頸。系統(tǒng)平臺(tái)結(jié)果被用來確認(rèn)這一理解，于是能夠做出更好決策來實(shí)現(xiàn)效率更高的系統(tǒng)。圖3中的另一個(gè)場景顯示了軟硬件劃分后的結(jié)果。

　　第一個(gè)范例中，當(dāng)軟件處理控制幀時(shí)，全局定時(shí)如下：

　　窗口編程時(shí)間=T+tRP+tPM+tintr+tsw_lat>T+texp，故在系統(tǒng)中，SW沒有對(duì)及時(shí)打開發(fā)送窗口的指令進(jìn)行編程。

　　在第二個(gè)范例中，當(dāng)MACHW處理控制幀時(shí)，全局定時(shí)為：

　　窗口編程時(shí)間=T+tprg_winexp，故系統(tǒng)中，HW對(duì)及時(shí)打開發(fā)送窗口的指令進(jìn)行編程。

　　與此同時(shí)，現(xiàn)有的SPEAr板起到了很大的幫助作用，因?yàn)樵诎迳蠝y出了AES-CCM引擎的性能。因此能夠推斷出硬件中存在AES-CCM，因?yàn)锳ES-CCM軟件算法給不出所需要的性能。