帳號:
密碼:
最新動態
產業快訊
CTIMES / 文章 /
實現車聯網應用的 IC 可靠性
從ISO 26262看散熱變化與電晶體測試

【作者: Richard Lee】   2015年10月14日 星期三

瀏覽人次:【33369】


汽車IoV(車聯網)應用程式有很多獨特的要求。通常,不同的技術會整合到單顆的IC元件中。例如,輪胎壓力傳感模組不僅僅需要MEMS感測器設備,還需要射頻設備將資料傳輸到安全控制系統。通過各種IoV應用程式的處理經驗,我們歸納出一些似乎一致的基本設計要求:


1.微處理器/中央處理器CPU/MCU


2.嵌入式及快閃記憶體


3.無線射頻協定支援(RF Connectivity)


4.低功耗電源管理


5.高效率、低成本的感測器介面



圖1 : 汽車互聯網(IoV)應用包含了許多獨立的功能,這些功能既相互關聯又遵循嚴格的安全優先順序。
圖1 : 汽車互聯網(IoV)應用包含了許多獨立的功能,這些功能既相互關聯又遵循嚴格的安全優先順序。

換句話說,一般IoV模組會整合感測器、執行器、超低功耗處理器、無線閘道和電源管理單元於一身,從而讓設備更加智慧化,能夠執行感應、捕獲和分析,並在必要時採取措施。這種設備可能需要保持「始終開機」(always on)狀態。為了省電,也可以先關閉,然後在需要時自動喚醒(Auto wake up circuit)。


除了需要擁有很多功能之外,IoV的另一大關鍵要求就是安全性和可靠性。IC可靠性挑戰包括靜電放電(ESD)保護、電應力超載(EOS)後的恢復能力、溫度和電壓變化容差,以及防止通過設備入侵系統的增強式安全性。為確保在IC設計期間解決這些問題,國際標準組織(ISO)制定了汽車應用功能安全標準ISO 26262。


ISO 26262 汽車電子設計可靠性標準

ISO 26262從2005年左右開始制定,並已於2011年年底正式發佈。該標準基於已有標準的規定,例如電子設備標準 IEC 61508。ISO 26262及AEC-Q100明確規定了汽車特定的安全性和可靠性生命週期。為符合 ISO 26262的規定,設計師必須將功能安全特性視為每個汽車子系統開發流程必不可少的一部分,包括功能規格、設計、實施、整合、驗證、確認及產品發佈,如圖2所示。



圖2 :  ISO 26262的V形開發模型。
圖2 : ISO 26262的V形開發模型。

該標準中的要求可視為V形的生命週期模型。V形右側表示十二個實施步驟。特定技術包括故障模式與影響分析(FMEA)方法,該方法定義了多個安全級別,其中ASIL(汽車安全完整性級別)A為最低安全級別,ASIL D為最高安全級別。


較高的ASIL安全級別意味著極為嚴苛的故障率要求。例如,ASIL B級要求故障率小於 100 FIT(即故障率,是可靠性的測量單位)。1 FIT表示被測物件在十億個小時的運行過程中僅能出現一次故障,100 FIT則表示在每十億個小時的執行時間內出現故障的次數限制為100次。另外,故障率還取決於所採用的晶圓製造工藝、晶片面積和工作溫度範圍。在汽車應用中,溫度可能會發生劇烈變化,引起時序問題和運行故障,例如電路閂鎖效應。


尤其,AEC-Q100包含了溫度等級標準。例如,位於排氣管附近、發動機艙、後備箱或者汽車面板中的設備會暴露在不同的極端溫度下,因此需對應不同的溫度等級,如表1所示。此外,不同的模組擁有不同的安全優先順序,例如車對車通訊、防碰撞系統或多媒體娛樂系統。


表1 汽車安全AEC溫度等級

等級

最低溫度

最高溫度

HTOL(高溫運行壽命)

0

-40

150

175oC Ta 下持續工作 408 個小時或者 150 oC Ta 下持續工作 1000 個小時

1

-40

125

150oC Ta 下持續工作 408 個小時或者 125 oC Ta 下持續工作 1000 個小時

2

-40

105

125oC Ta 下持續工作 408 個小時或者 105 oC Ta 下持續工作 1000 個小時

3

-40

85

105oC Ta 下持續工作 408 個小時或者 85oC Ta 下持續工作 1000 個小時

4

0

70

90oC Ta 下持續工作 408 個小時或者 70 oC Ta 下持續工作 1000 個小時


在設計過程中解決安全性和可靠性問題

IC設計階段是解決IC安全性和可靠性問題的最佳時機,例如越來越受到關注的電路可靠性驗證。由於電路設計不佳導致的潛在故障模式包括:


‧ 介質擊穿(Dielectric breakdow)


‧ 熱載流子效應(Hot-carrier effects)


‧ 擴散(Diffusion)


‧ 電遷移(Electromigration)


這些問題尤其明顯,因為隨著故障機制的不斷發展,在製造測試過程中通常無法檢測出這些問題,從而導致故障延遲到後來才出現。


電路可靠性驗證

對於面向IoV市場的IC設計師而言,電路可靠性驗證是他們所面臨的其中一項設計挑戰。下面我們瞭解一下簽核之前能夠執行的一些關鍵IC電路可靠性檢查。防止互連中閘極氧化層(gate oxide)時變擊穿是設計師們普遍關注的一個問題。一些IoV/IoT應用經過優化實現了低功耗,因此,這些設備可能會採用低電源電壓的流程,相應地具有更薄的閘極氧化層。設計師們必須格外謹慎,避免發生設計錯誤。


例如,如果超過相鄰導線之間的電壓降最大允許值,將會導致氧化層擊穿(oxide breakdown),隨著時間推移還會引起設備故障。同樣地,PMOS設備容易受到負偏壓溫度不穩定性(NBTI)的影響,引起PMOS電晶體的臨界電壓隨著時間的推移而升高,最後導致邏輯閘開關時間變慢。


電壓感知設計規則就是為了防止出現這些問題。遺憾的是,這些規則難以執行,因為許多低功耗IC設計擁有不同供應電壓的多個電源域,這就使得人工執行可靠性檢查成為一項幾乎不可能完成的任務。遺憾的是,傳統的DRC工具很難執行很多所需的可靠性檢查。因此,設計師們需要使用特定工具—既能夠瞭解功耗設計意圖,又可以實現電晶體級別的可靠性驗證檢查。


在本文中,我們展示了使用Calibre PERC進行自動化可靠性驗證的方法,特別是在電壓感知(voltage-aware)DRC流程領域。該工具能夠從幾何和電氣約束兩個方面來驗證可靠性,以確保網路得到保護、晶片面積得到充分利用。此外,它還能自動跟蹤電壓在多個電壓域中的傳遞,從而將正確的設計規則應用到每個設計節點中(見圖3)。如果用戶想要超越標準的晶圓代工平臺,以便滿足自己的可靠性驗證需求,也可以自訂電路驗證規則。



圖3 :  Calibre PERC電壓感知DRC流程:原理圖網表和物理設計用於傳播電壓值;然後將電壓特定設計規則應用到每個物理設計節點中。
圖3 : Calibre PERC電壓感知DRC流程:原理圖網表和物理設計用於傳播電壓值;然後將電壓特定設計規則應用到每個物理設計節點中。

功耗和熱效應的考慮

設計驗證的另一大關鍵挑戰是功耗和熱(溫度)分析。執行該分析不僅需要熱源建模(包括靜態和動態電壓和電流),還需要瞭解因操作模式和並行任務載入所引起的切換活動變化(Switching activity & operation mode)。分析所得的“功率模擬分析”可以轉換為基於幾何形狀、材料屬性和環境條件等物理因素的熱模型。


比如,可以考慮在底層規劃期間獲取熱感知。設計佈局規劃開始後,設計團隊可以制定包括封裝設計屬性的高層次功率映射。該功率映射可以導入熱分析器,例如 Mentor Graphics FloTHERM 產品。這個工具可以顯示出預期的熱點部位以及為提高熱性能需要作出設計更改的地方。例如,可能需要確保兩個或多個不同的設計模組在非常接近的溫度下運行,從而發現時序所造成的影響。圖 4 是來自 FloTHERM 的螢幕截圖,顯示了在帶有非均勻功率分配或電活動的設計中的溫度變化。



圖4 :  帶非均勻功耗的設計中的晶片溫度分佈圖。
圖4 : 帶非均勻功耗的設計中的晶片溫度分佈圖。

此外,該工具還可以通過溫度—時間曲線圖來支援瞬態分析,這些曲線圖可以使用波形檢視器顯示出來(圖 5)。這有助於設計師將溫度變化與操作模式和來源負載相關聯。



圖5 :  溫度—時間曲線圖有助於設計師將溫度變化與操作模式和有源負載相關聯。
圖5 : 溫度—時間曲線圖有助於設計師將溫度變化與操作模式和有源負載相關聯。

與底層規劃工具結合使用時,該流程允許設計師進行反覆運算設計,以實現針對功率分配進行優化的底層規劃,從而管理溫度並提高晶片可靠性(圖 6)。此外,該流程也可以擴展到封裝設計,包括 SiP、2.5D 和 3D IC 封裝方法。



圖6 :  在IC物理設計流程中生成熱/功耗感知。
圖6 : 在IC物理設計流程中生成熱/功耗感知。

安全性和可靠性測試

如上所述,提高安全性和可靠性的一種方式就是將其融入到設計中。另一種方式是在晶片生產過程中提供高品質測試,此外,還提供在通電期間或定期調用內置自動檢測功能,從而在產品出現運行安全問題之前提醒用戶系統性能降低。


電晶體級別測試—Cell aware ATPG

過去幾十年來,製造業一直使用傳統的Stuck-at fault故障模型來檢測IC缺陷。該測試旨在驗證設計中所有的邏輯節點都可自由地假定為 1 或 0 狀態,從而確保任何與標準儲存格互連的導線都不存在開路或短路的情況。但是,實現更低的缺陷率和更高的可靠性需要新的測試方法,尤其是對於採用更小及更複雜的製程,如 FinFET 電晶體。


單元感知測試方法可以在組成 IC 基本構造塊的單元內進行電晶體級別的測試。該測試採用 Mentor Graphics Calibre(例如 Calibre xACT)進行,測試時會首先提取技術庫中以 GDSII 格式表示的每個物理單元。每個提取單元會生成一份帶寄生電阻和電容的電晶體級別網表(Netlist)。電阻元素表示存在潛在開路缺陷的導電路徑,而電容元素識別存在潛在橋接缺陷的位置(圖 7)。



圖7 :  Cell Aware故障模型庫的生成過程。
圖7 : Cell Aware故障模型庫的生成過程。

單元網表生成之後,可以使用類比模擬器來分析單元,以瞭解單元內潛在的特定故障行為。例如,執行模擬時,每個寄生電容器將被不同的電阻值替換。類似地,每個寄生電阻器使用不同的電阻值來進行建模。之後根據模擬單元輸出偏離正確電路操作的方式對每次模擬結果進行分析並識別缺陷(圖 8)。此外,延遲效果同樣可以進行建模和分類。


這種特徵提取可以針對技術庫中的所有單元執行,最後產生一個單元感知庫(Cell Aware Library)。Mentor Graphics Tessent 測試平臺可以使用這一單元感知庫自動生成測試模式,以檢測出基於單元級別故障模式的缺陷。只需對指定技術(製程節點)執行一次單元感知庫特徵提取,之後任何使用該技術製造的設計都能使用這種方法。


圖8 :  通過模擬進行的單元特徵提取,以確定潛在故障的影響。
圖8 : 通過模擬進行的單元特徵提取,以確定潛在故障的影響。

該測試可以檢測單元內的缺陷,而不僅僅是單元之間連接中的缺陷。這種能力顯著地提高了測試品質,從而降低了生產漏檢。這一點對於要求品質盡可能接近「零缺陷」的IoV應用而言至關重要。


邏輯內置自測(BIST)為解決IoV方案的最佳應用

正如前面所討論的,有些缺陷源于隨時間推移所發生的退化機制。如果不通過謹慎的設計來預防,生產測試也無法將它們檢測出來。這就是為什麼 IoV 應用需要持續測試的原因,目的就是確保所有系統都安全可靠(圖9)。邏輯內置自測 (LBIST) 解決方案通過在通電或定期操作間隔期間進行全面測試來滿足這個需求。LBIST 可以內嵌到單個 IC 中或者在系統級別上實現,通過中央控制器管理單個元件中測試模式的佈線。


除了檢測 IoV 系統元件存在的故障之外,更為重要的一點是,LBIST 解決方案能夠直接從 LBIST 模式診斷出故障甚至電源檢測(Power-up test),以便卸掉有缺陷的元件或使用備用系統替換。此外,該診斷還可提高故障隔離能力,從而實現快速可靠的維修。



圖9 :  邏輯內置自測可滿足持續安全需求。
圖9 : 邏輯內置自測可滿足持續安全需求。

以下是高品質LBIST解決方案的一些主要特點:


包括用於動態創建測試模式的隨機信號發生器(Random Pattern Generator)


‧ 片上簽名計算器(On-chip signature calculator)將所有響應資料累加為單一的通過/失敗簽名


‧ 能夠使用與製造測試相同的掃描測試架構


‧ 無需在外部測試設備中存儲模式


另一個重要特點是能夠通過 IEEE 1149.1 相容介面啟動和控制LBIST,從而可以通過由1149.1介面定義的信號所驅動的非同步介面進行測試控制。


結論

ISO 26262和IEC 61508標準為設計安全可靠的汽車IC提供了良好的指導和參考。而AEC-Q100更是提供安全可靠性規範,雖然AEC並未有審查及認證的機制,但隨著更加複雜的技術引入到汽車應用(例如通過射頻連接到中央控制系統的車載網路),「為安全而設計」的方法勢必會成為IC設計流程不可或缺的一部分。


(本文作者現任職於Mentor Graphics Taiwan技術處長)


相關文章
滿足你對生成式AI算力的最高需求
台灣AI關鍵元件的發展現況與佈局
一美元的TinyML感測器開發板
用科技滅火:前線急救人員的生命徵象與環境監測
221e:從AI驅動感測器模組Muse獲得的啟發
相關討論
  相關新聞
» 全球智慧手機用戶數持續增長 2028年蘋果將超越三星
» 全球智慧手機用戶數持續增長 2028年蘋果將超越三星
» 荷蘭半導體再添助力 ChipNL獲1200萬歐元資金挹注
» Honda發表全新e:HEV油電混合動力系統:S+ Shift技術
» 半導體生產技術加速演進 高純度氣體供應為成功基礎


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

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