帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
從系統整合到SoC技術介紹(上)
 

【作者: 誠君】   2001年11月05日 星期一

瀏覽人次:【9740】

據半導體裝置與材料協會(SEMI)分析全球半導體業的復甦可能要延到2002年中,其根據是對通訊業持續成長的預估將帶動SoC的需求,而SoC將刺激可攜式高速率電子產品的消費需求,例如:行動電話、MP3播放機、傳呼機(pager)、PDA等等。


為了迎接這個復甦的機會,許多IC設計公司正面臨著更加複雜的產品所帶來的競爭壓力,解決之道就是要充分利用SoC開發平台來設計晶片,這可以消除因產品必須快速上市,所帶來的壓力。本文介紹SoC設計面臨的挑戰及其三種解決方案,其中可程式系統級晶片(Programmable System on Chip;PSoC)技術能夠極大地提高產品上市時間,遠遠勝過傳統的ASIC設計方法。


隨著晶片尺寸的縮小及元件密度的提高,在單晶片中整合的功能也越來越多。然而,只靠遵循摩爾定律而發展的SoC技術尚不能在晶片上實現所有元件的整合,還需要有無數複雜的設計細節,這包含宏觀的和微觀的、硬體的和軟體的成份。而這些都是實現功能完整的SoC所必需的。


未來整合的硬體設計

過去硬體供應商都將注意力放在個別的硬體設計本身,而很少考慮到這些硬體是如何和其它元件一起工作的。一旦暫存器級介面或特定作業系統的元件驅動程式設計完畢,ASIC、FPGA及其它元件供應商通常都會認為他們的工作已經結束。這就意味著元件整合的重擔要落到購買者或其它開發商和整合者身上,這些人必須在專用的、不統一的底層環境中進行設計和管理。而且他們必須解決由此導致的一系列問題,如(圖一),即便這不是他們的專長或主要的應用目標,甚至有些硬體供應商都不提供任何支援。


開發商與整合者通常都會被迫去解決許多基本問題:利用工程資源從頭開發元件驅動程式;整合來自不同軟體供應商的專用應用程式介面(API); 處理寫得不好的軟體驅動程式;根據單元硬體和應用程式介面進行系統設計;應付總體開發成本的增加及產品上市時間延長等等問題。


其實連接硬體與應用軟體的整合工作是件很痛苦的事,因為各家設計規格的不同以及技術保密的考量,這種整合工作非得自已做不可。再說誰會願意再去理一遍頭緒進行系統硬體的修改與升級呢?通常這些系統被認為是「不可觸摸的黑盒子」。一旦元件被整合以後,它們就變成永久性的固定元件,將始終占用裝置和系統整合者的寶貴資源。


《圖一  元件與驅動程式間的問題》
《圖一 元件與驅動程式間的問題》

發展快速遠端擷取技術

除了這些棘手的整合問題外,還有一個更現實的問題需要解決,那就是如何提供滿足快速成長的遠端擷取(remote access)市場所需的新技術。許多傳統的本地匯流排結構正逐步被基於TCP/IP的乙太網路結構和基於網際網路的擷取方式所替代。因此,硬體供應商需要好好地考慮一下這些新技術。


鑒於目前的設計競爭越來越激烈,硬體供應商必需藉由元件整合才能突顯自己。也就是說,產品從設計一開始就要考慮應用軟體環境及使用問題,並需要具有網路擷取方面的支援。


應用產品開發商並不願意為了處理數據和控制流而去費力地了解元件數據表所提供的暫存器級描述。他們沒有必要為暫存器中的位元作業或保留位元映射的唯寫(write-only)暫存器的虛擬複製而擔憂。他們不須去管與硬體相關或與應用程式介面相關的問題,例如:為什麼從一個元件中讀取的數據與從另一個讀取的不同?需要不同的包含文件(include files)、不同的功能調用和不同的返回代碼(return code)?而軟體開發商需要的是更高編程級別的有效作業,總之,他們需要最簡單的方法去擷取數據流(data flow)、控制流(control flow)和狀態(state)資訊。那麼硬體供應商要如何才能解決這些問題呢?這個問題保留到本文後面再來談,先看看應用產品開發商和系統整合人員的觀點。


應用開發商的觀點

藉由Wintel的環境,或多或少能夠滿足應用開發商的高級編程介面需要,應用開發商利用標準API能夠為相同的硬體裝置找到通用的編程介面。另一方面,電腦電話整合(CTI)市場也採用了一些標準來提供較高級的應用編程介面(S.100和TAPI)。這些標準可使不同硬體供應商的電話線路板在共同的單一框架(framework)內一起工作,例如,Dialogic公司的中間件(intermediate level)產品CT-Media,它能提供應用開發框架,並可支援來自多個硬體供應商的產品。


OLD/OPC標準

製造與工業自動控制(IA)市場也開發出了用於介面控制的製程控制OLE(OPC)標準,該標準基於微軟的「組件對象模型(Component Object Model;COM)」結構。利用已經發行的DCOM版本,這些應用軟體能夠藉由區域網路從遠端擷取硬體裝置。


目前有三種常用的開發環境(Windows、Linux、Java)可支援特定的元件或應用,這些元件包含:硬體介面卡和積體電路,如FPGA、ASIC、SoC等嵌入式元件,以及一些週邊元件。應用軟體開發商需要更高級的標準介面來推展開發工作,並更快地將產品推向市場。


系統整合人員的觀點

應用開發商在努力進行介面開發的同時,系統整合人員也遇到了類似的問題。為了提供必要的用戶級(client level)功能,系統整合人員必須集中於小型構建模組(包括軟體和硬體)的匯編工作。


儘管謹慎的軟體開發商從模組化、可再使用的角度著手系統設計(硬體開發商同樣如此),但硬體與軟體之間的連接常常是定制的,通常沒有可再使用性,這就使得系統整合人員的工作變得愈加複雜。


以基本的類比數位轉換器(ADC)硬體電路板(或積體電路)考量,該系統需要一定精密度和取樣率的ADC元件,而市場上符合要求的產品有很多。系統整合人員可能採用其中的一種進行設計,但隨即該方案就變成了一個緊密耦合(co-coupled)且不易替換的模組。如果想採用一個新的ADC元件,就需要再編寫一個新的介面,幾乎相當於再做一遍系統整合工作。


除了基本的硬體/軟體介面外,計算平台和作業系統也會限制系統整合人員的靈活性。要想把一個專門針對VxWorks環境下PowerPC系統而開發的驅動程式移植到其它硬體平台或作業系統是很困難的,因此需要開發和維護多個軟體版本。


在企業級應用中,用Java開發的應用軟體可運行於多種平台和作業系統。在嵌入式系統中,整合人員也需要同樣的靈活性。在硬體/軟體介面以及平台和作業系統的整合中,硬體裝置與其相對應的應用軟體之間需要更寬鬆的耦合,這樣才能使系統整合人員在解決用戶問題時有更大的靈活性。


未來硬體供應商的職責

如果能夠確保應用開發商和系統整合人員從擷取和通訊等相關實現細節中分離開來,硬體供應商就能使他們的產品變得更加實用,而且更富吸引力。實際上,硬體供應商需要支援某些類型的裝置軟體整合框架,以便對裝置進行擷取。如(圖二)。


《圖二  裝置軟硬體整合框架》
《圖二 裝置軟硬體整合框架》

優質軟體介面

硬體供應商必須提供高品質、全功能的軟體介面,才能滿足應用開發商和系統整合人員的需求。在提供硬體的同時,花些時間在軟體介面上將給應用開發商和系統整合人員帶來極大的便利。應該確保所提供的驅動程式工作正常,並盡量提高硬體產品的性能和品質。


在許多情況下,這些硬體產品是賣給軟體和系統整合商的,而非硬體開發商。因此,國內大多數的OEM硬體製造商,都必須在軟體介面的開發上多加把勁,才能獲得更多客戶的信賴。


隨著硬體裝置複雜性的不斷提高,保持軟體介面的模組化能使開發商專注於感興趣的功能模組。提供對裝置等級(device level)的支援以及多緒(multi-thread)、多用戶的擷取能力將產生錦上添花的功用。


開發統一擷取方式

對於不同類型的裝置來說,硬體應用擷取所需的許多功能是類似的,即使這些功能的具體實現方法對每個裝置來說會有所不同,但這也是大同小異的。配置(configure)、管理和數據流等功能對不同的裝置應呈現相同的方式,即必須開發出統一的擷取方式,這樣才可以使應用開發商獨立於硬體(hardware-independant)的具體實現方案之外,產生所謂的「透明化(transparent)」效果。


像Java這樣的技術,就有應用軟體編寫一次即可運行於任何地方的優點。但對於裝置驅動程式來說,編寫一次即可運行於任何地方,這樣的想法有點過於理想化。雖然如此,編寫一次的裝置驅動程式而使之運行於多種平台的觀點,仍是開發商極力追求的目標,也就是說,要做到裝置與作業系統分離,全靠驅動程式將它們連接起來。


利用內建網路通訊協定堆疊的支援,可使應用軟體運行於分散式環境中。提供對標準軟體的支援,能使裝置即刻具備網路擷取功能,而無需軟體開發商建立「承接介面(socket interface)」或做類似的工作。


在客觀條件下,應盡量採用裝置的擷取標準。現在還沒有太多的標準裝置API,工業裝置製造商們是首批創建並採用標準的群體之一(對於特定級別的工業裝置來說是指OPC)。


當技術發展的比較成熟時,裝置實現與通訊細節應該變得更加透明。應用軟體開發商能夠利用標準的介面方法在任何時間、任何地點擷取任何裝置,而無需了解裝置環境的底層細節或所使用的網路連接。這並不是一個不切實際的幻想,當全面了解目前已經實現的某些技術後,大家就會發現這個理想並不是那麼遙遠。


無ASIC的可程式SoC

系統級晶片(SoC)一般都包含三大基本要素:處理器、記憶體和邏輯單元,如(圖三)。整合了這三類電路也就相當於在單個晶片上實現了大多數系統的所有功能。


系統級整合(system level integration)因需要大量不同類型的積體電路,且只適用於特殊的應用,所以僅侷限在光罩ASIC上開發,而整合處理器、記憶體和邏輯電路的晶片,過去都需要這種專門的技術來設計。


目前只有少數設計者有機會接觸光罩ASIC,因為對於不能保証年產量在幾十萬片以上的設計,ASIC供應商基於成本考量,於是不會輕易接受。對單一設計來說,IP和光罩改變等非經常性工程(Non-Regular Engineer;NRE)成本動輒就是幾十萬美元。


只有極大產量的訂單才能允許在單一晶片上使用ASIC技術實現SoC;另外,對於那些生存周期較短、更新換代較快的產品來說,除了產量因素外,ASIC設計和製造周期也顯得太長。最後還要說明的是,ASIC產品很不靈活。設計中的任何一點錯誤或修改都將導致額外的光罩費用,以及再加工所需的較長製造周期。


《圖三  SoC的三大基本要素》
《圖三 SoC的三大基本要素》

明日之星:可程式SoC

雖然大多數設計商希望採用SoC來實現他們的設計以節省功耗、空間和成本,但絕大多數人都還未接觸過系統級整合。他們仍需依賴離散的標準產品(discrete standard components)之某種組合,如微處理器、記憶體、數位信號處理器(DSP)和可程式邏輯(PLD)。實際上,市場上仍存在著半導體供應商尚未涉及的真空地帶。


FPGA供應商正提供數量超過百萬系統閘的更大型FPGA來滿足中等批量、易於修改、周轉快的SoC需求。處理器的IP軟核心及其它小型IP功能模組可讓設計者在FPGA上實現處理器、記憶體和邏輯功能,而無需從頭建立所有的功能模組。


由於相對於較大的晶片尺寸,這些高密度FPGA仍有不少侷限之處,如較大的占用面積、較大的功耗和較高的成本。另外,FPGA邏輯電路的粗糙型結構也不是實現處理器核心的最有效途徑。


FPGA供應商的盲點

一個微控制器作為離散元件來購買只需6美元,而在高密度FPGA中作為IP軟模組來實現可能要花60美元。這些元件對於目前競爭激烈的市場來說太過昂貴。因此,高密度FPGA主要用於ASIC原型設計(prototype design),然後再轉換成ASIC實現,或成本與功耗是次要因素的應用場合,例如蜂窩基地站和高級網路基礎設施。


在功耗、面積和成本是主導因素的應用中,事實已經証明FPGA供應商藉由大型FPGA元件向所有設計商推薦SoC技術的努力失敗。


PsoC的應用

半導體行業怎樣才能向設計商推廣系統級整合方案呢?解決方案是創建混合產品,即可程式系統級晶片(programmable SoC;PSoC),它可以在一塊現成的可程式晶片上提供系統級整合。


許多IC供應商已經在可程式系統級整合的實現上邁出了可喜的步伐。這些新元件所提供的系統級功能包括處理器、記憶體和可程式邏輯,而沒有與ASIC相關的NRE費用或較長的製造周期問題。


可程式系統級晶片還具有和光罩ASIC一樣的高整合度(低功率、小尺寸、低成本)及和FPGA一樣的低風險、靈活性和快速上市的特性。目前已有幾家IC供應商能夠提供這種類型的可程式SoC。Atmel公司於1999年開發出首個基於RISC的現場可程式系統級積體電路(FPSLIC),FPSLIC元件現已量產。Xilinx和Altera公司也於2000年宣佈開發出各自的可程式系統級產品,預計在2001年投產。


這三家供應商都在單片可程式IC上整合了一個微控制器,並帶有不同密度的可程式邏輯、記憶體和週邊元件。因此設計商可以充分利用系統級整合的優勢,而不用擔心與光罩ASIC有關的複雜性和風險問題。事實上,在設計商的桌面上就可直接完成SoC設計。


相關文章
ChipLink工具指南:PCIe® 交換機除錯的好幫手
氫能競爭加速,效率與安全如何兼得?
智慧製造移轉錯誤配置 OT與IT整合資安防線
創新光科技提升汽車外飾燈照明度
以模擬工具提高氫生產燃料電池使用率
comments powered by Disqus
相關討論
  相關新聞
» 豪威集團推出用於存在檢測、人臉辨識和常開功能的超小尺寸感測器
» ST推廣智慧感測器與碳化矽發展 強化於AI與能源應用價值
» ST:AI兩大挑戰在於耗能及部署便利性 兩者直接影響AI普及速度
» 慧榮獲ISO 26262 ASIL B Ready與ASPICE CL2認證 提供車用級安全儲存方案
» 默克完成收購Unity-SC 強化光電產品組合以滿足半導體產業需求


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

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