當我們談及AI芯片，腦海中不免都會想起TOPS、L4/L5自動駕駛、圖像識別和處理算法等詞。但在初創(chuàng)企業(yè)、芯片大廠紛紛追逐“AI熱“的情況下，芯片的可靠性成了一個大問題，甚至對終端應用也有較大的影響。

自動駕駛故障，不止OEM要擔責

經(jīng)常關(guān)注汽車新聞的讀者想必都很清楚，近年來因為自動/輔助駕駛引發(fā)的事故越來越多，起因多種多樣，但很少會將其追溯到芯片上。有的車企為了追求快速上市，其AI芯片很可能只有AEC-Q100認證，而沒有ISO 26262這樣的功能安全認證，在他們看來這些標準太過
“傳統(tǒng)”了，對于產(chǎn)品的創(chuàng)新流程來說有些多余了。

這在消費者眼里也是如此，我們對功能的感知是最為直觀的，而對故障的感知只要在接受范圍來就好。這就使得此類車廠可以以一種“手機APP”開發(fā)式的模式運作，實現(xiàn)快速迭代。然而，這并不代表功能安全可以被忽視，畢竟當壞事落在自己頭上時，總得要個說法吧。

在實現(xiàn)功能安全的過程中，從提出要求、架構(gòu)、設(shè)計、編程到測試階段，都有對應的確認與驗證工作，然而通過驗證是一回事，能否實現(xiàn)追溯就是另一回事了。比如設(shè)計上的改動可能會違背芯片要求等等，最終導致實際性能不符等問題，所以在功能安全開發(fā)設(shè)計和認證的過程中，必須要做到可追溯。

Harmony Trace芯片設(shè)計追溯 / Arteris

IP廠商Arteris提出了一個追溯方案名為Harmony Trace，幫助芯片廠商更好地實現(xiàn)功能安全。Harmony Trace在這些分散的流程系統(tǒng)之間創(chuàng)造了一層整合系統(tǒng)，用于追蹤半導體產(chǎn)品壽命周期中的所有失誤。一旦違反芯片要求的錯誤出現(xiàn)，這套系統(tǒng)就會通知工程師這項改動需要進行檢查，從而自動化車規(guī)認證的審查流程。當然了，芯片開發(fā)廠商所用的開發(fā)工具流都是不盡相同的，所以Harmony Trace也提供了對現(xiàn)有主流EDA工具、認證流程的支持。

在自動駕駛安全標準繼續(xù)演進，ISO 21448和UL4600等標準提出的額外要求下，在AI芯片設(shè)計中保證可追溯性或許是縮短產(chǎn)品開發(fā)認證周期的一條捷徑。

可靠性第一

事實證明，不止自動駕駛領(lǐng)域，云端同樣需要可靠的AI計算芯片。我們從現(xiàn)在的云端計算集群來看，多個節(jié)點為云服務提供了強大的計算能力，但正是因為這般復雜的架構(gòu)，每一個節(jié)點都有可能成為整個系統(tǒng)的阿喀琉斯之踵。

這樣的案例我們也見多了，甚至開始影響到我們的生活，熱搜上時不時就會冒出“某某應用崩了”的消息，互聯(lián)網(wǎng)公司經(jīng)受的服務器故障可謂數(shù)不勝數(shù)，而且苦于定位故障來源，這其中，芯片也脫離不了干系。

造成這些后果的芯片可靠性問題主要有三種，早期失效（ELF）和正常設(shè)備運行下的隨機失效，還有不可避免的設(shè)備老化。芯片都是有著工作壽命的，所以最后一項難以從設(shè)計上解決，最多盡可能延長其壽命，而前面兩者才是當下云端需要提防的問題。

常見的早期失效有閘極氧化層失效、老化效果不好和軟擊穿等，隨機失效很多與運行環(huán)境有關(guān)，比如溫度過高、輻射過高等等。

為了進一步讓AI芯片免受這些可靠性問題的影響，初創(chuàng)公司Ceremophic公布了自己研發(fā)的QS1芯片。這是一款基于5nm工藝的分層學習芯片，集成了2GHz自定義機器學習處理器、2GHz的自定義FPU處理機器學習計算，還有一個基于ThreadArch的RISC-V處理器和ARM Cortex-M55應用處理器，Ceremophic稱后者主要用于元宇宙相關(guān)應用的視頻處理。在接口方面，該芯片支持到x16 PCIe6.0/CXL 3.0。

那么這款芯片在可靠性上的亮點又有哪些呢？Ceremophic稱對于早期失效而言，他們選用了高效的ASIC實現(xiàn)方式來使用抗ELF的邏輯庫，在正確的邏輯單元組合下以最小的設(shè)計開銷做到低ELF。

而在面對隨機失效上，Ceremophic用到了自己的多線程技術(shù)，利用兩個多線程處理器運行同一程序，一旦檢測到錯誤，就會利用多個結(jié)果來做出表決，并進行修正，接著程序執(zhí)行會直接從檢測到錯誤發(fā)生的地方開始運行，而不是一個未知的安全起始點，消耗更多的功耗。

在傳統(tǒng)的高可靠性設(shè)計中，往往都得采用高成本的解決方案，比如冗余，就像是需要在兩個地方做同一件事，帶來計算資源和功耗的雙重增加。不僅如此，解決方式也需要消耗更多的運行周期，這也是為何云端服務器出現(xiàn)故障后，不能快速恢復的原因。