帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
多媒體當道32位元處理器趁勢而起
 

【作者: David Katz】   2005年02月01日 星期二

瀏覽人次:【6052】

隨著嵌入式系統的複雜度迅速地提高,設計者在處理器的選擇上必須面對新的挑戰。在許多先進的應用中,具備彈性與低成本特性的8位元和16位元微控制器(MCU)不斷將地盤拱手讓給32位元的系統單晶片(SoC)。當然,8位元和16位元處理器仍然在嵌入式應用中居於穩固的地位。然而在某些方面,由於系統成本、產品擴充性與性能等需求,使得這股32位元的趨勢其來有自。以下本文將使用多媒體市場為討論背景,檢視MCU轉向32位元的主要動機。


32位元MCU優勢何在?

要了解為何32位元MCU在多媒體領域成長如此快速的原因,首先要考慮的是8位元MCU並不能提供在這些系統中保證即時操作所需的頻寬與運算功率。而有一個明顯的問題是:「那何不升級到16位元微控制器呢?」畢竟這些元件真的可以提升傳輸量與效能;此外,它們所消耗的待機電流也很低,而且一般可以提供比8位元競爭產品更大容量的內建記憶體。


結果,答案是相當簡單的。實現一個以32位元MCU為基礎的系統,它的實際的成本與許多今天使用的16位元解決方案是差不多的,但它的效能遠大過16位元MCU卻是顯而易見的;如(圖一)。以下有多個理由說明兩者成本其實相差無幾。



《圖一 多樣化的 MCU領域》
《圖一 多樣化的 MCU領域》

<本圖表示,在32位元MCU中整體朝向親和性多媒體之SoC形式整合的趨勢,而低效能8位元與16位元MCU則是典型適用在以控制為主的周邊。>


製程技術

由於矽晶製程持續微縮化,32位元架構變得不再昂貴。更小的元件製程產生更小的裸晶片,因此在每片晶圓上具有更多的裸晶。這直接轉換成更低的每個單位晶片成本。除此之外,隨著32位元元件轉成0.18微米或0.13微米(對比8位元元件一般使用0.25微米)所能達到的操作速度就更快。舉例來說,大部分8位元和16位元MCU的運行速度多在100MHz以下,但採用0.13微米製程設計的32位元元件可以達到的速度是前者的好幾倍。


有二大理由說明為何以更小的製程來設計8位元元件是不具成本效益的:


  • (1)8位元元件由於整體缺乏頻寬,任何從製程微縮來達到的額外速度都可能是浪費的。


  • (2)一般8位元元件的目標價格約在2美元左右,對以某些更小幾何製程實現的元件而言,這個價格太低了。



當更小的製程可能對8位元元件的成本結構造成負面的衝擊時,它對32位元MCU卻是有好處的,除了微縮它們的晶片尺寸外,還有空間挪出位置給SoC適用的一整組周邊用。甚至於如此在效能上的大躍進,成本僅約5美元左右,足以與16位元MCU成本結構相抗衡。


可編程模式

另一項與成本有關的考量在於與32位元架構相關的編程模式。由於處理器的資料路徑中有更多位元以及新增加的由32位元資料與位址暫存器所構成的暫存器檔案,編譯器支援因此大幅提升。此外,32位元元件常會支援16與32位元運算碼,這使得指令集架構的彈性更大,改善程式碼密度,並允許許多運算在單一核心時脈週期內完成。


換句話說,這二項特性減少對人工撰寫的組合語言程式的依賴,因此開發者可主要以高階語言像C語言來撰寫程式。以C為基礎的編程模式直接轉換為更低的開發與維護成本。它也讓公司內現有的應用程式能被轉譯成從未想像到的MCU環境領域。


擴充的周邊支援

如前所述,多媒體系統中MCU的角色通常是作為系統的控制器。它們不適用在密集資料處理上──這是數位信號處理器(DSP)擅長的工作──相反地,MCU會用來控制DSP的動作,並且管理人機介面、作業系統以及與其他系統元件的連接。


就是這種與外面世界的連接關係,推動朝向32位元MCU發展的趨勢。許多普遍存在的周邊(高速USB2.0、PCI...等)支援如此高的資料率,使得在8與16位元MCU上處理這些資料流變得很困難甚至不可能。例如,在網路連結性的領域,最大的資料暫存器若為8位元甚至是16位元,將無法支援一整組網路協定。


8/16位元MCU在高速下運行的基本問題來自於它們受限的處理能力與較小的記憶體定址範圍。有些8位元MCU只有一些資料暫存器,並沒有單獨的累加器。完整的暫存器檔案存在是非常重要的,因為它能省卻在記憶體與累加器之間頻繁轉換資料的需求。此外,有多重32位元資料位址產生暫存器,效能就能大幅提升。這些32位元MCU的特性造成編譯碼的密度更高,連續頻寬更大,還有如我們討論過的,更加有彈性的編程模式。


受到32位元MCU競爭壓力,16位元MCU業者也有其因應對策,他們試圖擴充MCU內部的匯流排大小,好使得作業的速度更快,而不用增加解決方案的最終成本。雖然這類型方案多少有點助益,但效能上的基本鴻溝仍然存在。


32位元MCU系統趨勢

與32位元MCU成長的另一新興趨勢在於傾向結合更多DSP功能在同一晶片上。雖然今天大部分多媒體的設計使用由MCU主控的DSP,為了成本,空間與節省耗電考量,開發者卻總是想將此一功能整合成一顆晶片。促成此一趨勢的是一般在32位元元件才有的更快的時脈速度:更高的MHz代表能進行信號處理的空間更多。


不過,先天上MCU的架構並非針對高效率信號處理。因此,製造商嘗試用多種技術來降低此一缺點。


其中一個做法是以單一封裝中生產一種包含一顆DSP和MCU的多晶片模組(MCM)。這種做法的缺點是設計者必須以“50/50”比例去分割控制與DSP功能。舉例來說,一旦DSP“用爆了”MCU並不能接手未完成的運算。同時,當DSP與MCU核心都存在時,就需要二組開發工具。


另一種選擇是將DSP功能內建到MCU中。這種做法只適合簡單的信號處理應用。MCU時脈速度與運算架構基本上並不很適用在密集的數字處理。有些MCU想要用增加乘法/加法(MAC,DSP的主要特徵)單元加以補償。但這種做法仍然缺乏較前瞻應用所需的基本架構設計。


最後一種選擇是將MCU和DSP功能整合成一顆處理器。這類處理器呈現一種統一的架構,不僅適合做為數位運算,而且也能執行以控制為主的工作任務;以ADI的Blackfin系列處理器為例,它同時具備一顆16位元DSP與32位元MCU的功能。經由平衡決定性控制任務與複雜計算能力兩邊的需求,這種做法可依系統的即時需要,允許達到執行100%控制或100%運算。


結語

未來32位元MCU將繼續以更低的成本來提供更大的處理資料量與更多的特性。同時,系統單晶片技術也將持續把微控制器功能,普及的連接性以及強大的運算能力整合在一起,以實現真正的單晶片解決方案。很明顯地,這些32位元SoC已經宣告了自己在多媒體領域中的地盤,而它們對這些市場所造成的革命性改變將會日趨明顯。(作者任職於美商亞德諾Blackfin應用事業群)


延 伸 閱 讀

應用廣泛的 MCU (微控制器),在簡單的家電設施、複雜的多媒體產品以及汽車、工業控制等領域都可見其身影。相關介紹請見「綜觀台灣MCU產業現況」一文。

隨著汽車 IA 化的到來,車體內的微控制器越來越多,從早期的 20 多顆,到近年來的 50 多顆,甚至高階車種已經達到 100 多顆, MCU 對車體的重要性將日益壯大。你可在「全球車用微控制器趨勢演進」一文中得到進一步的介紹。

目前全球 MCU 仍以 8 位元為主力產品;根據 Instat 統計資料顯示, 8 位元 MCU 在 2001 年仍以消費性應用產品為主。在「MCU應用分佈趨勢」一文為你做了相關的評析。

市場動態

混合訊號 IC 業者 Silicon Laboratories 在 2003 年底併購 MCU 廠商 Cygnal Integrated Products 之後,隨即在 2004 年以推出 8 位元通用型 C8051F 系列新產品正式宣佈跨入 MCU 市場。相關介紹請見「結合類比功能 8位元MCU挑戰更高階應用」一文。

在競爭激烈的 8 位元 MCU 市場中, MicroChip 推出了體積最小、 SOT-23 封裝的 6 針腳快閃 MCU ,搶下 8 位元 MCU 盟主的企圖心非常明顯。你可在「小體積大效益 挑戰MCU設計極限」一文中得到進一步的介紹。

盛群半導體新推出 8 位元精簡型 MCU 內建 8~9 位元 ADC ,適用於家電、車用周邊及其他智能控制的產品,其精簡的架構提供使用者一個具有優異性價比的解決方案。在「盛群推出8位元精簡型MCU」一文為你做了相關的評析。

相關文章
AI高齡照護技術前瞻 以科技力解決社會難題
3D IC 設計入門:探尋半導體先進封裝的未來
SiC MOSFET:意法半導體克服產業挑戰的顛覆性技術
意法半導體的邊緣AI永續發展策略:超越MEMS迎接真正挑戰
CAD/CAM軟體無縫加值協作
comments powered by Disqus
相關討論
  相關新聞
» 應材於新加坡舉行節能運算高峰會 推廣先進封裝創新合作模式
» 生成式AI海嘯來襲 企業更需要AI雲端服務來實現創新與發展
» 研究:Android品牌多元化布局高階市場 本地化策略與技術創新將引領潮流
» AI走進田間 加拿大團隊開發新技術提升農食產業永續發展
» 以電漿科技回收鋼鐵業二氧化碳 比利時打造全球首例


刊登廣告 新聞信箱 讀者信箱 著作權聲明 隱私權聲明 本站介紹

Copyright ©1999-2024 遠播資訊股份有限公司版權所有 Powered by O3  v3.20.2048.3.145.66.104
地址:台北數位產業園區(digiBlock Taipei) 103台北市大同區承德路三段287-2號A棟204室
電話 (02)2585-5526 #0 轉接至總機 /  E-Mail: webmaster@ctimes.com.tw