基于ARM的SoC設計入門

要設計一個基于ARM的SoC，我們首先要了解一個基于ARM的SoC的結構。圖1是一個典型的SoC的結構：


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

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

如果公司已經決定要開始進行一個基于ARM的SoC的設計，我們將會面臨一系列與這些基本構成相關的問題，在下面的篇幅中，我們嘗試討論這些問題。

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


表1
ARM已經給出了基本的參考意見：

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

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

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

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


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

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


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

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


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

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