基於ARM的SoC設計入門[轉]

標籤：des   http   io   os   使用   ar   for   strong   檔案   

原文：基於ARM的SoC設計入門

我們跳過所有對ARM介紹性的描述，直接進入工程師們最關心的問題。
要設計一個基於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已經給出了基本的參考意見：

• 如果您在開發嵌入式即時系統，例如汽車控制、工業控制或網路應用，則應該選擇Embedded core。
• 如果您在開發以應用程式為主並要使用作業系統，例如Linux, Palm OS, Symbian OS 或 Windows CE等等，則應選擇Application core。
• 如果您在開發象Smart card，SIM卡或者POS機一樣的需要安全保密的系統，則需要選擇Secure Core。

舉個例子，假如今天我們需要設計的是一個VoIP電話使用的SoC，由於這個應用不需要使用到作業系統，所以我們可以考慮使用沒有MMU的核心。另外由於網路通訊協定盞對即時性的要求較高，所以我們可以考慮ARM9系列的核心。又由於VoIP有語音編解碼方面的需求，所以需要有DSP功能擴充的核心，所以ARM946E-S或ARM966E-S應該是比較合適的選擇。
當然，在實際工作中的問題要比這個例子要複雜的多，比如在上一個例子中，我們也可以選擇ARM7TDMI核心加一個DSP的解決方案，由ARM來完成系統控制以及網路通訊協定盞的處理，由單獨的DSP來完成語音編解碼的功能。我們需要對比不同方案的面積，功耗和效能等方面的優缺點。同時我們還要考慮Cache size，TCM size，實際的核心工作頻率等等相關問題，所以我們需要的一個能構快速建模的工具來協助我們決定這些問題。現在的EDA工具為我們提供了這樣的可能，例如Synopsys?的CCSS（CoCentric System Studio）以及Axys?公司的Maxsim?等工具都可以協助我們實現快速建模，並在硬體還沒有實現以前就可以提供一個軟體的模擬平台，讓我們在這個平台上進行軟硬聯仿，評估我們設想的硬體是否滿足需求。

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倍的軟硬聯仿效能，並提供系統的分析功能，如果系統架構不能滿足需要，那麼瓶頸在系統的什麼地方，是否是核心速度不夠？匯流排頻率太低？Cache太小？還是中斷響應開銷太多？是否需要添加DMA？等等，諸如此類的問題，我們多可以在工具的協助下解決。
    當然，機器不是萬能的，不要指望工具能告訴你問題在哪裡並告訴你怎麼解決，工具能提供給你的只是一些統計的資料，而需要我們工程師去分析問題出在哪裡並想出解決辦法，所以熟悉AMBA體繫結構和ARM核心是非常必要的。

3.如何選擇外設IP，使用現成的IP還是自己定製？
使用IP最大的優勢是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之外，還提供這些外設的驅動程式及測試程式。
使用現成IP方便的，但同時也帶來靈活性的限制。舉個例子，當我們需要一個SPI匯流排介面的時候，我們應該使用ARM的SSP(Synchronous Serial Interface)這個IP，但是這個IP為了提供能與Motorola SPI，TI SSP，NS Microwire都相容的功能，犧牲了片上面積，導致IP複雜度增加了。如果我們的應用僅僅是需要和Motorola SPI的標準相容，那我們又何必需要一個這樣複雜的IP呢？
自己定製IP雖然得到了靈活性的優勢，但是確需要設計工程師完成自己的一套驗證，同時也要為這個IP開發驅動程式，工作增加了許多。我的建議是具體情況具體分析，在選擇IP的時候也可以考慮第三方公司提供的基於AMBA匯流排標準的IP，比如Synopsys?的DesignWare? IP庫中就有很多基於AMBA標準的IP可供選擇，有時這些IP能夠提供比ARM的IP更好的靈活性並同時使用更少的片上面積和功耗。比如同樣是Memory Controller，DesignWare?的DW_memctl就比ARM的MPMC(Multi-port Memory Controller)更靈活，可以定製更多的參數。關於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?。由於系統高速匯流排（通常是AHB或AXI）上的行為比較複雜，所以我建議這樣的VIP不要由工程師自己開發，而盡量使用EDA vender提供經過了完善測試的VIP。對於低速外設匯流排（APB）或SPI，I2C，USB等匯流排，則自己開發BFM模型和Monitor是可行的。

5. 搭建好的平台如何驗證？
我們選擇了適合的ARM core和匯流排結構，挑選了合適的IP，然後搭好了積木，TOP完成了，問題也來了，TOP該如何驗證？
關於SoC的驗證確實是個大題目，特別是在以IP為基礎的SoC設計方法出現以後，在工程師的設計能力和驗證能力中間出現了差距，也就是我們能在短時間內完成設計，卻需要化數倍於設計的時間和人力來驗證。最消耗時間的工作一般來說發生在軟硬聯仿(SW/HW Co-simulation/Co-verification)的階段。
大家知道，抽象級越高的模擬越快，反之越慢，所以如果在我們的TOP檔案中所有的模組都是RTL或Gate level的（包括ARM core），那麼模擬的速度是誰也無法接受的，所以現實一點的方法是使用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提供的開發工具(ADS，RealView)編譯好，產生bin檔案，然後儲存的Memory的模型中。
這時我們已經可以開始模擬了，ARM的DSM模型會在模擬的過程中產生一個log.eis檔案，這個檔案順序記錄了ARM core曾經執行過的所有指令，通過這個檔案，我們就可以對軟體進行debug了。
當然，使用這個檔案對軟體進行debug是很痛苦的，因為工程師不僅不能中斷、跟蹤、逐步執行軟體，更不能使用Semihosting功能進行檔案操作和調試資訊傳遞。如果可以使用AXD或Realview Debugger來對軟體進行debug將給工程師帶來極大的方便，所以EDA公司也推出了相關的產品，例如Mentor Graphics?公司的Seamless?以及我們前面提到的Axys?公司的Maxsim?等工具都能提供與AXD或者Realview Debugger協同模擬的介面。這樣我們就可以象在目標板上調軟體一樣在模擬平台上調試軟體了。
在這個抽象層級的模擬速度比純RTL平台要快一些，大約能夠做到1～100指令每秒的速度。在這樣的平台上進行驅動程式和啟動代碼驗證是可行的，但是如果要進行應用程式的全功能驗證，特別是有作業系統的應用，這樣的平台還是太慢了。比如在這樣的平台上啟動一個uClinux?，往往需要化數周的時間。顯然，在這樣的速度下驗證應用程式還是不現實的。
解決這個問題我們有兩個個選擇：
(1) 使用硬體加速器
某些EDA vender會提供相關的解決方案，例如Cadence?公司的PALLADIUM? Accelerator/Emulator 和Mentor Graphics?的VStationPRO? Emulation system。這些都是能夠加速我們模擬的加速器，但是一般價格昂貴，所以對大多數的Design House來說，這個方法不但性價比不高，而且也沒有必要。
(2)使用FPGA原型進行測試
這個方法對於大多數公司來說是比較現實的。這正是我們的下一個問題。

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

基於ARM的SoC設計入門[轉]