帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
嵌入式軟體的世紀大挑戰
 

【作者: 誠君】   2003年11月26日 星期三

瀏覽人次:【3817】

對設計微米晶片而言,摩爾定律使前端的驗證(verification)複雜度倍增。過去,摩爾定律只影響到硬體的驗證工作,僅衝擊到既存的解決方案。但是,今天嵌入式數位訊號處理器(DSP)和微處理器內核必須整合在一起,此技術上的困難度對業者而言是一個嶄新的挑戰。


將這些IP內核整合在一起時,IP通路商不只要提供驗證硬體的工具,也要提供與硬體相關的嵌入式軟體和開發工具。因此DSP和SoC整合的成功關鍵有二:一是硬體的驗證,另一是與前者同時進行的嵌入式軟體(embedded software)的移植和驗證。


過去,EDA業者已經為純硬體驗證流程開發出許多種方法。其中最有效的方法是使用抽象(abstraction)法和使用相關的工具將問題侷限在正確的條件之下解決它。這種方法導致晶片設計工作可以從傳統的主板級(board level)電路佈局(layout)設計向上提升到暫存器轉換層級(RTL)的設計,使上層的IP具有可再重覆使用的特性。這種方法已經沿用了將近40年,這些年來RTL的使用效率相當良好。精準的正規(formal)法、直接隨意(directed-random)法、硬體輔助的驗證方法也一一被採用,當這些方法被正確使用時,一流的團隊能一次就成功地設計出晶片來。業者現在可以設計內含數百萬個邏輯閘的硬體,已經超越了過去的數百個邏輯閘。其中的關鍵在於設計之初就能使用最好的工具和方法。


相反的,過去20年來,軟體的驗證流程並沒有重大的改變。今天軟體工程師所設計的驗證碼行數和過去的工程師設計的行數差不多。只不過,今天的龐大程式需要更多的軟體工程師才能如期完成。


因為嵌入式軟體只能在硬體存在的地方才能被驗證,它不像Windows或UNIX應用程式可以完全與硬體無關,所以「內電路模擬器(ICE)」成為開發嵌入式軟體的必備工具。SoC就是嵌入式軟體的「宿主」,變化多端的SoC因嵌入式軟體的加入,使得整個系統的設計問題變的更加複雜。


這個問題的產生是因為:傳統上,供嵌入式軟體驗證用的平台要到SoC設計專案的最後階段才能準備好。當SoC的硬體問題都被解決了,嵌入式軟體的驗證問題卻十萬火急、迫在眉梢。就是卡在這裡,使得SoC的上市時間一直延遲。國內目前的幾家SoC晶片設計公司都面臨著這個問題,即使勉強硬著頭皮將研發多時的SoC正式推出,最後也會因為沒有提供嵌入式軟體和其開發工具,或提供的嵌入式軟體和其開發工具造價高昂(因為是委託國外軟體公司設計的),或支援的嵌入式軟體太少或不支援價格低廉、開放原始碼的嵌入式Linux,最後淪落成和4-bit、8-bit微控制器一起競逐狹小的電子消費性市場,以每顆幾角、幾分來計價,實在是令人惋惜。


解決這個頭痛的問題需要廣泛地採用抽象方法,並且在SoC設計的初期,就先讓嵌入式軟體工程師加入,遂行其軟體驗證工作。晶片設計業者必須在心態上能調整過來,雖然他們過去似乎有些鄙視作業系統開發者。再者,嵌入式軟體的驗證工作需要巨額資金投入,因為軟體是具有純智慧財產的特質,不管是向國內或國外購買驗證工具或服務,這筆開銷都無法避免的。


業者必須具備一個功能強大的抽象層,可以驅使硬體電路和嵌入式軟體按照預先規劃好的流程進行設計。所有重大的軟硬體問題都能在設計的最初階段就被發現,並隔離於一個小角落,在不影響整體計畫的既定時程下,另外派遣特別小組去抽絲剝繭,剷除問題。


因此,新一代的系統層級設計需要新的思維和方法,它必須能夠結合Verilog/VHDL和C/C++。為了節省資源、並結合軟硬體設計者以前的寶貴經驗,絕不能再發明新的語言,逼迫設計者放棄以前的知識和程式碼或模型。這種語言必須支援各種一般的或特殊的軟硬體規格需求、於SoC設計過程中的每一階段的驗證和除錯功能、最佳化的性能、以添增程式庫的方式不斷增加新抽象模型...等。目前有一種語言正符合前述的要求,就是SystemC。「開放SystemC協定團體(Open SystemC Initiative;OSCI)」(http://www.systemc.org/)成立於2000年,類似GNU一樣,該團體將免費供大家參考用的原始程式碼公開放在SourceForge網站上。目前已經有許多EDA公司提供符合SystemC標準的工具和模組化的程式庫。


簡言之,SystemC的特徵就是將軟體和硬體模組化,它們之間的通訊不再是電子訊號,而是函式呼叫(function calls),呼叫完畢就表示「交易(transaction)」結束了。因此,這種模式也稱作「交易層模型化(transaction-level modeling)」。因為硬體已經被模組化,而且處理速度很快(一般約每秒100K時脈),所以嵌入式軟體可以在設計初期很容易地被執行。不過,任何工具都有它的極限,對硬體的暫存器轉換層設計而言,硬體描述語言(HDL)仍然是最容易、最穩定、最快速的程式語言,而且支援最多且成熟的工具和程式庫。此外,即時的系統模擬仍然需要硬體工程師的理性判斷才行,因為SystemC的功能再怎麼強大,它畢竟仍然是一個工具而已。這也是模擬理論或數學模型化的極限。


SystemC帶來的最大益處可以說是它能夠在SoC設計一開始時就為我們建立起智慧型的「測試平台(testbench)」,是在我們還未進行暫存器轉換層細部設計之前,而且這個測試平台可以一直用到SoC設計完成以後,在這期間它可以為我們發現錯誤(bug)並示警。當然在進行暫存器轉換層細部設計時,我們需要不斷地修改測試平台。不過,它始終都能和「交易層模型化」的環境保持一致性。因為SystemC與C/C++的用法相似,所以對嵌入式軟體工程師而言,使用它並不會困難。因此,軟硬體工程師夢寐以求的開發工具似乎就此誕生了,而「黃金模型(Golden Model)」也許就可以很快地得到。


常常聽到國內SoC設計業者抱怨說:原本以為OEM系統廠商只要使用已公開原始程式碼的Linux就可以輕鬆地利用SoC開發出許多便宜、功能又多的產品來。但是,沒有想到嵌入式軟體的技術問題是這麼難解決。沒錯!目前國內業者最需要的是:能夠完美地整合硬體和軟體的高明工具和方法,能夠在最早的時間內完成SoC的分析與驗證工作。這個挑戰對全世界的EDA設計業者而言也是艱鉅的,因為使用微米製程製造的SoC比我們現有的SoC還要複雜許多倍。


(作者為電子產業資深研發工程師,現為誠君工作室負責人:su2b08@saturn.seed.net.tw)


相關文章
創新光科技提升汽車外飾燈照明度
以模擬工具提高氫生產燃料電池使用率
眺望2025智慧機械發展
再生水處理促進循環經濟
積層製造加速產業創新
comments powered by Disqus
相關討論
  相關新聞
» 數智創新大賽助力產學接軌 鼎新培育未來AI智客
» VicOne深植車用資安DNA再報喜 獲TISAX AL3最高等級認證
» 勤業眾信獻策5方針 解決GenAI創新3大常見風險
» Fortinet整合SASE突破組織分散管理困境 重塑雲端安全的混合未來
» UD Trucks選用VicOne解決方案 利用情境化攻擊情報洞察風險


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

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