基于A(yíng)RM的SoC設計入門(mén)

要設計一個(gè)基于A(yíng)RM的SoC，我們首先要了解一個(gè)基于A(yíng)RM的SoC的結構。圖1是一個(gè)典型的SoC的結構：


圖1
從圖1我們可以了解這個(gè)的SoC的基本構成：

• ARM core：ARM966E
• AMBA 總線(xiàn)：AHB+APB
• 外設IP(Peripheral IPs)：VIC(Vector Interrupt Controller), DMA, UART, RTC, SSP, WDT……
• Memory blocks：SRAM, FLASH……
• 模擬IP：ADC, PLL……

如果公司已經(jīng)決定要開(kāi)始進(jìn)行一個(gè)基于A(yíng)RM的SoC的設計，我們將會(huì )面臨一系列與這些基本構成相關(guān)的問(wèn)題，在下面的篇幅中，我們嘗試討論這些問(wèn)題。

1. 我們應該選擇那種內核？
的確，ARM為我們提供了非常多的選擇，從下面的表-1中我們可以看到各種不同ARM內核的不同特點(diǎn)：


表1
ARM已經(jīng)給出了基本的參考意見(jiàn)：

• 如果您在開(kāi)發(fā)嵌入式實(shí)時(shí)系統，例如汽車(chē)控制、工業(yè)控制或網(wǎng)絡(luò )應用，則應該選擇Embedded core。
• 如果您在開(kāi)發(fā)以應用程序為主并要使用操作系統，例如Linux, Palm OS, Symbian OS 或 Windows CE等等，則應選擇Application core。
• 如果您在開(kāi)發(fā)象Smart card，SIM卡或者POS機一樣的需要安全保密的系統，則需要選擇Secure Core。

舉個(gè)例子，假如今天我們需要設計的是一個(gè)VoIP電話(huà)使用的SoC，由于這個(gè)應用不需要使用到操作系統，所以我們可以考慮使用沒(méi)有MMU的內核。另外由于網(wǎng)絡(luò )協(xié)議盞對實(shí)時(shí)性的要求較高，所以我們可以考慮ARM9系列的內核。又由于VoIP有語(yǔ)音編解碼方面的需求，所以需要有DSP功能擴展的內核，所以ARM946E-S或ARM966E-S應該是比較合適的選擇。
當然，在實(shí)際工作中的問(wèn)題要比這個(gè)例子要復雜的多，比如在上一個(gè)例子中，我們也可以選擇ARM7TDMI內核加一個(gè)DSP的解決方案，由ARM來(lái)完成系統控制以及網(wǎng)絡(luò )協(xié)議盞的處理，由單獨的DSP來(lái)完成語(yǔ)音編解碼的功能。我們需要對比不同方案的面積，功耗和性能等方面的優(yōu)缺點(diǎn)。同時(shí)我們還要考慮Cache size，TCM size，實(shí)際的內核工作頻率等等相關(guān)問(wèn)題，所以我們需要的一個(gè)能構快速建模的工具來(lái)幫助我們決定這些問(wèn)題?，F在的EDA工具為我們提供了這樣的可能，例如Synopsys®的CCSS（CoCentric System Studio）以及Axys®公司的Maxsim®等工具都可以幫助我們實(shí)現快速建模，并在硬件還沒(méi)有實(shí)現以前就可以提供一個(gè)軟件的仿真平臺，讓我們在這個(gè)平臺上進(jìn)行軟硬聯(lián)仿，評估我們設想的硬件是否滿(mǎn)足需求。

2.我們應該選擇那種總線(xiàn)結構？
在提供內核給我們的同時(shí)，ARM也提供了多種的總線(xiàn)結構。例如ASB，AHB，AHB lite，AXI等等，在定義使用何種總線(xiàn)的同時(shí)，我們還要評估到底怎樣的總線(xiàn)頻率才能滿(mǎn)足我們的需求，而同時(shí)不會(huì )消耗過(guò)多的功耗和片上面積。這就是我們平時(shí)常說(shuō)的Architecture Exploration的問(wèn)題。
和上一個(gè)問(wèn)題一樣，這樣的問(wèn)題也需要我們使用快速建模的工具來(lái)幫我們作決定。通常，這些工具能為我們提供抽象級別很高的TLM（Transaction Level Models）模型來(lái)幫助我們建模，常用的IP在這些工具提供的庫中都可以找到，例如各種ARM core，AHB/APB BFM（Bus Function Model），DMAC以及各種外設IP。這些工具和TLM模型提供了比RTL仿真快100～10000倍的軟硬聯(lián)仿性能，并提供系統的分析功能，如果系統架構不能滿(mǎn)足需要，那么瓶頸在系統的什么地方，是否是內核速度不夠？總線(xiàn)頻率太低？Cache太??？還是中斷響應開(kāi)銷(xiāo)太多？是否需要添加DMA？等等，諸如此類(lèi)的問(wèn)題，我們多可以在工具的幫助下解決。
當然，機器不是萬(wàn)能的，不要指望工具能告訴你問(wèn)題在哪里并告訴你怎么解決，工具能提供給你的只是一些統計的數據，而需要我們工程師去分析問(wèn)題出在哪里并想出解決辦法，所以熟悉AMBA體系結構和ARM內核是非常必要的。

3.如何選擇外設IP，使用現成的IP還是自己定制？
使用IP最大的優(yōu)勢是Time to Market，ARM提供了相當多的外設IP供我們選擇。ARM提供的外設IP集（PrimeCell® IP）包括了常用的絕大部分外設，我們可以參考表2：


表2：
PrimeCell®的IP一直在增加，ARM會(huì )不定期在網(wǎng)站上公布最新可用的PrimeCell® IP，詳情情參考：
http://www.arm.com/products/solutions/PrimeCellPeripherals.html
ARM除了提供這些IP的RTL之外，還提供這些外設的驅動(dòng)程序及測試程序。
使用現成IP方便的，但同時(shí)也帶來(lái)靈活性的限制。舉個(gè)例子，當我們需要一個(gè)SPI總線(xiàn)接口的時(shí)候，我們應該使用ARM的SSP(Synchronous Serial Interface)這個(gè)IP，但是這個(gè)IP為了提供能與Motorola SPI，TI SSP，NS Microwire都兼容的功能，犧牲了片上面積，導致IP復雜度增加了。如果我們的應用僅僅是需要和Motorola SPI的標準兼容，那我們又何必需要一個(gè)這樣復雜的IP呢？
自己定制IP雖然得到了靈活性的優(yōu)勢，但是確需要設計工程師完成自己的一套驗證，同時(shí)也要為這個(gè)IP開(kāi)發(fā)驅動(dòng)程序，工作增加了許多。我的建議是具體情況具體分析，在選擇IP的時(shí)候也可以考慮第三方公司提供的基于A(yíng)MBA總線(xiàn)標準的IP，比如Synopsys®的DesignWare® IP庫中就有很多基于A(yíng)MBA標準的IP可供選擇，有時(shí)這些IP能夠提供比ARM的IP更好的靈活性并同時(shí)使用更少的片上面積和功耗。比如同樣是Memory Controller，DesignWare®的DW_memctl就比ARM的MPMC(Multi-port Memory Controller)更靈活，可以定制更多的參數。關(guān)于DesignWare® IP的詳細資料，請參考：
http://www.synopsys.com/products/designware/designware.html

4.自己設計的連接在A(yíng)MBA總線(xiàn)上的IP如何驗證？
如果我們確實(shí)要自己設計連接在A(yíng)MBA總線(xiàn)的IP，那么熟悉AMBA的總線(xiàn)標準是必須的。但是設計往往不是問(wèn)題，問(wèn)題是如何驗證我們的IP能符合所有AMBA標準定義的行為 呢？
作為一個(gè)IP的驗證，我們常常會(huì )使用所謂的Component-Based Verification，具體做法如圖-2所示：


圖2
在圖2中我們要驗證的是一個(gè)USB的IP，這個(gè)USB模塊直接連到AHB總線(xiàn)上，在我們的testbench中需要如圖中所示的各種VIP（Verification IP），如圖中所示的BFM，Bus Monitor，才能夠模擬一個(gè)USB模塊會(huì )在真實(shí)的總線(xiàn)結構中會(huì )遇到的全部情況。這些VIP可以由EDA vender提供，也可以由工程師自己編寫(xiě)，但通常這些VIP不會(huì )使用HDL語(yǔ)言編寫(xiě)，而是使用HVL(Hardware Verification Language)語(yǔ)言。例如：e®, Vera等語(yǔ)言，當然同時(shí)也要使用支持這些語(yǔ)言的工具，如Verisity®的Specman®。由于系統高速總線(xiàn)（通常是AHB或AXI）上的行為比較復雜，所以我建議這樣的VIP不要由工程師自己開(kāi)發(fā)，而盡量使用EDA vender提供經(jīng)過(guò)了完善測試的VIP。對于低速外設總線(xiàn)（APB）或SPI，I2C，USB等總線(xiàn)，則自己開(kāi)發(fā)BFM模型和Monitor是可行的。

5. 搭建好的平臺如何驗證？
我們選擇了適合的ARM core和總線(xiàn)結構，挑選了合適的IP，然后搭好了積木，TOP完成了，問(wèn)題也來(lái)了，TOP該如何驗證？
關(guān)于SoC的驗證確實(shí)是個(gè)大題目，特別是在以IP為基礎的SoC設計方法出現以后，在工程師的設計能力和驗證能力中間出現了差距，也就是我們能在短時(shí)間內完成設計，卻需要化數倍于設計的時(shí)間和人力來(lái)驗證。最消耗時(shí)間的工作一般來(lái)說(shuō)發(fā)生在軟硬聯(lián)仿(SW/HW Co-simulation/Co-verification)的階段。
大家知道，抽象級越高的仿真越快，反之越慢，所以如果在我們的TOP文件中所有的模塊都是RTL或Gate level的（包括ARM core），那么仿真的速度是誰(shuí)也無(wú)法接受的，所以現實(shí)一點(diǎn)的方法是使用ARM core的DSM（Design Simulation Model）模型。具體方法如圖-3所示：


圖3
我們在圖3中可以看到，對于內核(Processor)和Memory Controller我們都使用了使用高級語(yǔ)言編寫(xiě)的行為模型，并在這些行為模型和真正的RTL之間使用PLI(Program Language Interface)語(yǔ)言編寫(xiě)的接口。當然，所有別的外設IP和總線(xiàn)結構都還是使用RTL(因為我們就是要驗證這些RTL)。DSM模型大多由IP提供商提供，如果使用的是ARM core，當然就由ARM提供了。軟件由ARM提供的開(kāi)發(fā)工具(ADS，RealView)編譯好，產(chǎn)生bin文件，然后儲存的Memory的模型中。
這時(shí)我們已經(jīng)可以開(kāi)始仿真了，ARM的DSM模型會(huì )在仿真的過(guò)程中產(chǎn)生一個(gè)log.eis文件，這個(gè)文件順序記錄了ARM core曾經(jīng)執行過(guò)的所有指令，通過(guò)這個(gè)文件，我們就可以對軟件進(jìn)行debug了。
當然，使用這個(gè)文件對軟件進(jìn)行debug是很痛苦的，因為工程師不僅不能中斷、跟蹤、單步執行軟件，更不能使用Semihosting功能進(jìn)行文件操作和調試信息傳遞。如果可以使用AXD或Realview Debugger來(lái)對軟件進(jìn)行debug將給工程師帶來(lái)極大的方便，所以EDA公司也推出了相關(guān)的產(chǎn)品，例如Mentor Graphics®公司的Seamless®以及我們前面提到的Axys®公司的Maxsim®等工具都能提供與AXD或者Realview Debugger協(xié)同仿真的接口。這樣我們就可以象在目標板上調軟件一樣在仿真平臺上調試軟件了。
在這個(gè)抽象級別的仿真速度比純RTL平臺要快一些，大約能夠做到1～100指令每秒的速度。在這樣的平臺上進(jìn)行驅動(dòng)程序和啟動(dòng)代碼驗證是可行的，但是如果要進(jìn)行應用程序的全功能驗證，特別是有操作系統的應用，這樣的平臺還是太慢了。比如在這樣的平臺上啟動(dòng)一個(gè)uClinux™，往往需要化數周的時(shí)間。顯然，在這樣的速度下驗證應用程序還是不現實(shí)的。
解決這個(gè)問(wèn)題我們有兩個(gè)個(gè)選擇：
(1) 使用硬件加速器
某些EDA vender會(huì )提供相關(guān)的解決方案，例如Cadence®公司的PALLADIUM® Accelerator/Emulator 和Mentor Graphics®的VStationPRO® Emulation system。這些都是能夠加速我們仿真的加速器，但是一般價(jià)格昂貴，所以對大多數的Design House來(lái)說(shuō)，這個(gè)方法不但性?xún)r(jià)比不高，而且也沒(méi)有必要。
(2)使用FPGA原型進(jìn)行測試
這個(gè)方法對于大多數公司來(lái)說(shuō)是比較現實(shí)的。這正是我們的下一個(gè)問(wèn)題。

6. 如何完成FPGA原型驗證？
完善的FPGA驗證對芯片功能驗證是非常必要的，同時(shí)正如我們在上一個(gè)問(wèn)題中提到的，要完成完整的功能驗證，沒(méi)有FPGA原型的幫助是非常困難的。具體到基于A(yíng)RM的SoC，我們可以選擇以下的一些方法：
(1) 由ARM公司提供的Integrator® prototyping board
ARM提供了一套名叫Integrator®開(kāi)發(fā)套版，使工程師能夠在這個(gè)套版上搭建和設計芯片盡量一致的驗證平臺。簡(jiǎn)單來(lái)說(shuō)，ARM提供了Integrator® CT (Core Tile)來(lái)實(shí)現相應的ARM Core的功能和行為；使用Integrator® LT(Logic Tile)來(lái)實(shí)現我們芯片中除了ARM Core以外的所有數字邏輯（Integrator® LM上有個(gè)FPGA），使用Integrator® IM(Interface Module)連接模擬器件，再把這三個(gè)板作為子板統統插接到Integrator® AP（ASIC development Platform）。這樣我們就像裝電腦一樣裝出了一個(gè)SoC。在這個(gè)平臺上，基本上所有的功能驗證都可以做到，只要你對頻率的要求不是太高（比如在你的應用中ARM core要跑在100MHz），這個(gè)平臺是可以完成實(shí)時(shí)測試的。
(2) 由第三方供應商提供的FPGA驗證平臺
例如ALDEC®公司的Riviera-IPT FPGA verification system。這個(gè)系統的硬件是一塊PCI接口的板卡，這個(gè)板卡的核心的一個(gè)FPGA，我們的數字邏輯還是放在這個(gè)FPGA中。同時(shí)，在這個(gè)母板上可以插上不同的ARM core的Integrator® CM，這樣就完成了數字部分的搭建了。這個(gè)系統同樣能提供與ARM的方案差不多的性能，但是它比ARM的方案有更多一些的靈活性。
Riviera提供了一個(gè)能讓ARM core， FPGA中的已綜合邏輯和未綜合的RTL三方協(xié)同仿真的功能。這個(gè)功能的好處的我們可以復用原來(lái)在工作站環(huán)境下仿真時(shí)使用的Testbench、激勵和參考輸出，并可以把RTL象搬積木一樣一塊一塊的搬到FPGA中。也就是說(shuō)，在開(kāi)始時(shí)所有RTL和Testbench都可以在PC機上進(jìn)行仿真（當然是使用Riviera提供的仿真器），這時(shí)仿真的速度是比較慢的；一旦工程師覺(jué)得哪一塊的RTL已經(jīng)OK了，那么他就可以將這一塊RTL綜合到FPGA中，隨著(zhù)越來(lái)越多的模塊進(jìn)入FPGA，仿真的速對會(huì )越來(lái)越快。最后，所有的數字邏輯都綜合到了FPGA中。在RTL仿真和FPGA之間建立交互還有一個(gè)好處是在FPGA debug的時(shí)候給我們帶來(lái)了很多方便。調試過(guò)FPGA的工程師常常有著(zhù)痛苦的回憶，由于FPGA內部的信號不可見(jiàn)，FPGA的debug往往非常耗時(shí)，Riviera在提供RTL和FPGA聯(lián)仿的同時(shí)，還可以提供觀(guān)察FPGA內部信號的功能，類(lèi)似Xilinx®的CHIPSCOPE。詳細資料請參照網(wǎng)頁(yè)：
http://www.aldec.com/products/riviera-ipt/pages/coverification/
(3) 自己開(kāi)發(fā)FPGA原型板
當然，如果自己設計FPGA原型板，那么工程師就會(huì )擁有最大的靈活性，自己的開(kāi)發(fā)板上可以放置任何需要的器件。選用的FPGA可以盡量貼近實(shí)際SoC的運行速度，如果有Analog IP對應的Analog器件，那么功能驗證的覆蓋率將會(huì )非常小，最大程度減少投片不成功的風(fēng)險。這個(gè)方案的代價(jià)是設計和調試驗證板的時(shí)間，有時(shí)這個(gè)時(shí)間還會(huì )超過(guò)芯片設計的時(shí)間，同時(shí)也需要工程師擁有設計高速PCB的相關(guān)知識。
ARM core的測試樣片是驗證板的核心，這個(gè)測試樣片實(shí)際上就是直接將內核拿去流片得到的（當然還要加上必要的PLL）。通常，ARM授權的Foundry會(huì )提供這樣的測試樣片，需要注意的是這個(gè)測試樣片是否能達到應用所要求的速度，如果不能，那么實(shí)時(shí)測試將不可能實(shí)現。
另外一個(gè)需要注意的問(wèn)題是FPGA的容量。在做AMBA總線(xiàn)結構FPGA綜合的時(shí)候工程師會(huì )發(fā)現以AMBA總線(xiàn)為基礎的RTL對FPGA資源的消耗非常驚人，有時(shí)一個(gè)150K Gate Count的數字邏輯會(huì )無(wú)法綜合到一個(gè)150萬(wàn)門(mén)的FPGA中（如Xilinx®的XC2V1500），所以在驗證板的規劃初期一定要選擇一個(gè)留有余量的FPGA（或幾個(gè)FPGA組成陣列）。