當前,在域控制器集中式架構階段,智能駕駛和智能座艙是車載AI芯片的兩個重要應用領域。充分挖掘在這兩個場景下的應用需求是車載AI芯片廠商的核心驅動力。新算法模型的引入,以及整車EE架構的發展,都會對車載AI芯片的迭代產生較大的影響。
1)不管是智能座艙,還是智能駕駛,所應用的算法模型都在不斷地變化和演進,尤其是在智能駕駛領域,更為明顯,從先前的CNN網絡演進到現在的BEV+ Transformer+OCC網絡,促使車載AI芯片向適應更新的算法模型的架構方向進化。
2)車載AI芯片的迭代與整車EE架構的演進相互協同發展。在域控制器集中式架構階段,車載AI芯片基本都是針對特定功能域下的應用場景去設計和開發,比如,智能座艙或智能駕駛。隨著整車EE架構進入跨域融合階段,“艙駕融合”成為重點的關注方向,芯片廠商需要兼顧智能座艙和智能駕駛的應用需求,設計出一款高度適配“艙駕一體”的車載AI芯片。
一、新的算法模型對車載AI芯片的影響
當前,在智能駕駛領域,頭部車企在城區NOA方面開始“攻城略地”,“BEV + Transformer”已成為實現這一戰略目標的主要技術手段;在智能座艙領域,生成式AI大模型被逐漸引入,用來強化艙內的AI視覺和語音等人機交互體驗。因此,在車載AI芯片上所運行算法的復雜度、模型參數以及數據規模均會大幅上升,倒逼車載AI芯片向新架構、大算力等方向演進。
但是,新的算法模型與傳統的芯片架構之間存在著一定的“隔閡”,比如,不少業內人士反映,Transformer 網絡在一些車載AI芯片上很難部署,主要原因在于過去傳統端側的AI芯片主要是針對CNN網絡去設計開發,通用性比較差,對于Transformer等較新的算法模型適應性較弱。
針對這一問題,奕行智能創始人兼CEO劉琿回答說:“首先,Transformer和CNN兩者計算類型完全不同。CNN屬于計算密集型網絡,整個網絡是非常規整的、一層層的卷積操作,每層里若干通道的卷積核作為權重是可以被輸入特征共享的存儲數據。
“Transformer屬于訪存密集型網絡,特點是算法模型里不規則形狀的張量多,需要大量矩陣操作的Transpose/Permute/Reshape等算子,體現在硬件上就是對片上內存的容量和訪存帶寬的要求會比以CNN為目標的加速芯片高很多。映射在計算里面的表現便是對訪存的來回操作,在內存中搬運的次數會比較多。所以,是否能夠適應Transformer模型,不僅要看AI芯片是否具備足夠的訪存容量,而且還要有足夠的訪存帶寬。訪存帶寬有多個層級,從計算內核到L1,再到L2,以及把這些東西連接起來的總線,都是決定因素。
“其次,Transformer對于浮點算力的要求非常高,因為Transformer的Attention模塊是矩陣乘+ Softmax,它其實是一個指數運算,對精度的要求非常高。傳統的AI芯片主要針對CNN網絡設計,可以通過Int8來完成,基本上沒有預留浮點算力。沒有浮點算力,對計算精度會造成很大的影響,所以浮點計算資源不足是過去很多AI芯片存在的問題之一。
“最后,向量計算資源對于完成Transformer運算也非常重要。上面已經提到Attention是一個矩陣乘+Softmax來回重復操作的過程。矩陣乘是比較規則的矩陣運算,Softmax屬于指數運算。而指數運算本質上是向量運算,向量運算就需要用向量引擎去做,如果用矩陣運算單元去做向量運算,效率會很低,因此,需要有足夠的向量計算資源去支撐。”
那么,Transformer算法模型容易在什么樣的芯片架構上部署,或者說如何才能提高芯片對新的算法模型的適配度呢?
1)專門增加相關的算法模型引擎
傳統 AI 推理專用芯片大多針對 CNN/RNN網絡設計, 普遍針對INT8精度,幾乎不考慮浮點運算,并行計算效果不佳。如果將Transformer網絡簡單量化為INT8精度后,整體的性能會顯著下降,主要是由于普通的激活函數量化策略無法覆蓋全部的取值區間。
英偉達在設計GPU新架構Hopper時,專門增加了Transformer引擎,即專門為Transformer算法做了硬件優化,它集合了新的 Tensor Core、FP8 和 FP16 精度計算,以及 Transformer 神經網絡動態處理能力,旨在加速AI計算的效率。Transformer引擎能夠在訓練神經網絡的每個步驟中動態選擇神經網絡中每一層所需的精度,可以協調動態范圍和準確度,比如,可以根據工作負載在FP8和FP16格式之間進行自動切換,期望跑的每一步都只用最低精度需求,同時又不損失精度的情況下來訓練模型,以期達到最高的效率。下一代車載AI芯片Thor便是采用這樣的GPU架構。
英偉達 Transformer 引擎工作原理示意圖(圖片來源:英偉達官網)
2)針對特定算子進行優化
設計一款什么算法模型都支持的芯片也不太現實,如果這樣,成本一定高,研發周期一定長。那么,怎樣才能讓芯片盡可能多地去支持不同類型的網絡呢?安霸半導體研發副總裁孫魯毅談到:“Transformer模型的核心算子是Self-Attention和 Cross-Attention ,中間包含了一些計算類型,比如矩陣乘法、Softmax等。首先,要從原理上支持他們中間的各種計算;其次,芯片以及工具鏈要具備足夠的靈活性,后期便可以通過修改調整工具鏈,使得芯片在計算效率不下降的情況下去支持新的算法。
“網絡模型的核心計算的地方集中在一些反反復復進行特定計算的操作上。正因為如此,才可以通過設計專門的芯片去提高效率。如果整個網絡都是亂序的,那么,專用處理器就沒法設計,只能做通用處理器了。因此,我們專門優化了一些很重要的算子,比如,針對Transformer里面的矩陣計算以及一些非線性計算的算子進行優化,來提高芯片對于一些特定網絡的計算效率。”
3)適當增大內存帶寬,避免其成為計算的“瓶頸”
在內存帶寬的需求上,相比CNN,Transformer不僅模型更寬、更深、參數更多,其算子復雜度也更高,計算單元需要頻繁地從存儲單元中存取數據與指令,因此,Transformer網絡對于SRAM的利用率,對于內部總線突發大帶寬訪問等方面提出了更高的要求。那么,到底需要多大的帶寬?某芯片公司研發工程師回答說:“這不能一概而論,算力、SRAM大小、算法模型類型都會導致對存儲帶寬產生不同的需求。因此,芯片設計也不可能按照最大帶寬來設計,否則芯片成本無法接受,需要依據具體的應用需求做出合理規劃”
4)因地制宜,不同的應用場景適合不同的設計方式
后摩智能聯合創始人&產品副總裁信曉旭說“Transformer在性能上雖然比CNN有了很大的提升,但我覺得它并不是整個自動駕駛算法的終局,將來一定還會出現新的算法模型,能夠更好地解決目前尚未解決的問題。在此情況下,如果把芯片做得過于專用化,可能在這一代芯片上,BEV /Transformer可以跑得很好,但當新的網絡模型出來的時候,可能應對起來就比較吃力。
“現在,對于計算類芯片,大家的核心追求是計算效率。專用的芯片是基于算法定義芯片的方式,是其中一種提高計算效率的方式和手段。然而,自動駕駛是一個復雜的系統,在最開始做芯片設計時候,我們就需要能夠真正的理解自動駕駛的業務流,并能夠以此為導向來設計NPU:一定要從系統的維度去看,去設計,而不是簡單的拼積木的形式。更多的時候,從傳感器數據流進入系統開始,就要想著怎么設計才能讓系統更高效的運行。
“因此,在智駕領域,不同的細分市場可能需要用不同的方式去定義和設計芯片。
前視一體機方案適合采用‘算法定義芯片’的方式,因為前視一體機不需要實現太復雜的功能,通常也不會涉及到更先進的算法,這樣的方式能夠在最大程度上提高計算效率。
對于高階智能駕場景,還有很多Corner case尚未完全解決,大家在做芯片的時候就要考慮通用性,以及未來對新算法的適配性。芯片的底層設計要充分考慮上層應用算法的發展,在提供足夠通用性的前提下,還要兼顧計算效率,這也是后摩智能當時選擇做存算一體架構的原因之一。”
5)把NPU當成AI處理器來設計,而不是簡單的AI加速器
針對當前最新流行的算法模型,愛芯元智聯合創始人&副總裁劉建偉認為:“談到處理器,一般都會有指令集的概念,我們是把算子作為這些處理器的指令集,即所謂的算子集就是處理器的指令集。以前的NPU主要是針對CNN網絡去開發,如果是從設計加速器的角度去考慮,當時會很容易陷入到只考慮 CNN網絡模型的慣性思維中去。而我們是把‘到底需要什么樣算子’的需求分解到底層,相當于直接去考慮處理器的指令集應該如何設計。在這種情況下,當BEV和Transformer 出來之后,只需要增加一些BEV 和Transformer相關的算子就可以。以這樣的思路去設計AI芯片,才能更好地兼顧通用性和靈活性。
“ 首先,把NPU當成一個AI處理器來設計,關注的是處理器的指令集。雖然網絡結構變了,只是網絡里面的算子的組合方式不一樣,但是算子本身的變化沒有那么大。
“ 其次,新的算法模型出來,到底需要什么樣的算子?我們要做的事情是把這些算子實現好,讓算子在硬件上跑得足夠快。對算法工程師來講,只需要考慮這個硬件能支持哪些算子,怎樣才能讓這些算子在硬件上跑得快。隨著時間的推移,硬件和對應算子的適配度會越來越高。”
6)基于“軟件定義芯片”的理念去設計AI芯片
要想設計好一款芯片,首先一定要深刻理解算法和軟件。一位業內專業人士曾直言不諱的提到,為什么當前一些AI芯片不能很好地適配最新的算法,最大的原因可能在于他們前期的市場調查做得不充分,前瞻算法的發展趨勢研究不透徹,導致設計出來的產品不具備有前瞻性,雖然能夠解決以前客戶提出的問題,但卻不一定能夠解決現在以及未來可能出現的問題。”
在筆者看來,地平線就是一家奉行“軟件定義芯片”類似設計理念的公司。地平線智能駕駛產品規劃與市場總經理呂鵬談到:“我們一直都是強調要‘從軟件中來,到軟件中去’的理念去設計芯片,以軟件驅動芯片的設計和創新的架構設計去支撐整個軟件算法的開發。舉個例子,如果一家芯片公司沒有軟件的Know-How,設計芯片時沒有考慮清楚將來量產的時候最主流的算法會是什么,那么,一旦芯片量產后,運行當時最先進、主流的算法的效率可能會非常低,因此,芯片便很難支撐先進的算法落地。從本質上來說,征程6對Transformer高效的支持性能也是基于地平線對于算法的深刻理解而推演出來的結果。”
征程6采用地平線新一代納什架構BPU,原生支持Transformer網絡。針對Transformer網絡模型,地平線在J6上有幾個獨特的設計:a.強大的并行浮點算力:支持多線程并發的SIMT Vector Processing Unit(VPU);支持BF16/FP16/FP32 多種浮點數據類型,在性能和精度之間取得更好的平衡。b.特別優化的超越函數:支持 Layer-norm&Softmax 算子的硬件加速;支持 Transpose&Reshape算子的硬件加速。Transformer模型中有一些非常關鍵的算子,雖然計算量不大,但復雜度很大。也就是說,計算量可能只占3%的算子,運行時間可能要占到10%~30%。因此,通過設計超越函數的算子,使得原本非常長的計算時間得到快速的縮減。
c.采用全新的存儲系統設計,片上包括L0M、L1M、L2M,共三級存儲系統,用于數據緩沖和交換。同時,先進的總線架構配合高帶寬的DDR,有效緩解內存墻的問題。
二、艙駕一體對車載AI芯片的影響
1)為什么要做“艙駕一體”?
當前,主機廠大多處于域控制器集中式架構階段。在以功能劃分的域控制器基礎上,為進一步降低成本和增強不同域之間的協同,出現了跨域融合,即將多個域融合到一起,比如,將動力域、底盤域以及車身域三者合并為整車控制域;將更高算力需求的座艙域和智駕域整合為“艙駕一體”計算域。
黑芝麻智能高級市場產品總監徐曉煜認為:“隨著自動駕駛的部分功能成熟應用并且相應體驗得到市場和用戶的接受,智能化配置的裝配率會快速提高并快速趨同,隨之而來的行業挑戰就是如何在保證功能、性能等產品指標的前提下優化成本并讓不同定位的車型都可以標配。
“行業共識的有效路徑就是對不同的系統作進一步的整合和集成,原本多個供應商的多個硬件需要融合為一個系統、一套硬件,從而在域控制器本身、硬件材料、連接線材、軟件費用等多方面降低成本。
“現階段是一個恰逢其時的時間窗口,新型的電子電氣架構為艙駕融合在整車層面提供了底座基礎,智駕和座艙的標準智能化也已逐漸趨向于成熟,同時,更重要的是芯片方面,新一代的高性能處理器已經問世,新的架構和技術可以更好地支持多功能的集成,從而可以更進一步將多芯片艙駕一體系統推向單芯片艙駕一體系統。”
2)實現“艙駕一體”面臨的挑戰是什么?
據相關業內人士透露,在2025年左右,會有輕量級的單SoC芯片艙駕一體方案量產落地。但也有部分業內人士沒有那么樂觀,他們認為單SoC芯片艙駕一體方案量產落地可能不會那么快,還存在一些問題待解決。整體來講,艙駕一體肯定是大勢所趨,大家普遍對在這方面的布局也比較認可。
“艙駕一體”面臨的挑戰,從技術角度,可以從硬件和軟件兩個維度來看:
硬件層面
對于芯片廠商而言,開發一款合適的艙駕一體SoC芯片本身就存在很大的挑戰。因為它需要將多個系統和功能融合在一起 ,并且還要能兼顧不同應用場景的需求 —— 有的重視響應,需要及時反饋;有的側重安全,需要高穩定可靠性;有的既要性能強,還要兼容軟件豐富,通用性好。
安霸半導體孫魯毅談到:“理想型的艙駕一體SoC需要在支持智能駕駛全功能高負荷運行的時候,還要支持座艙內的用戶交互和娛樂系統,這非常有挑戰性。
“要保證用戶交互和娛樂系統非常好的響應速度和較強的3D圖像渲染能力,艙駕一體SoC不僅需要充足的內存帶寬,而且對GPU和CPU的性能要求也比較高。除非艙駕一體SoC單芯片的總性能大于等于單獨的座艙SoC和智駕SoC這兩顆芯片性能之和,否則很難保證兩邊同時工作的效果。而且,兩邊的DRAM系統最好是分開的,互相不影響內存帶寬和訪問延遲;另外,在GPU資源的使用上,座艙的娛樂系統和智駕系統最好也完全分開使用;如果AI計算使用專門的NPU,也要考慮是否被兩套系統共享。”
“但這樣的芯片,成本和功耗自然都不會低,而且復雜度很高,出問題的概率也會增加。而且,座艙和智駕的功能安全需求等級不一致,如果兩邊都做成滿足智駕水平的功能安全等級,必然會抬高成本。如果兩邊按座艙的標準去做功能安全,智駕系統則存在安全性風險。總之,單Soc芯片艙駕一體方案目前仍是一個值得探索但尚未被成功驗證的道路。”
軟件層面
座艙和智駕如何進行安全有效的隔離?智駕域的特點是高可靠性和低時延性;而座艙域更注重娛樂和用戶體驗,需要更豐富的功能和較高的OTA頻率。如何把兩個系統能進行很好的整合,保證不同任務的優先級情況和不同功能安全等級的實現,這都存在很大的挑戰。
目前座艙和智駕中相關模塊對功能安全的要求:智能座艙中控娛樂模塊需要達到ASILA等級,儀表模塊需要達到ASILB等級;智能駕駛泊車模塊至少需要達到ASILB等級,行車模塊需要達到ASILD等級。那么芯片底層的加速器資源針對這些不同功能安全等級的應用如何進行有效隔離是很棘手的問題。
對于單SoC艙駕一體方案,某Tier1智駕域控專家曾這樣說到:“座艙和智駕這兩種安全級別不一樣的軟件放在一起該如何共存?可以采用虛擬機的方式,也可以采用Container的方式。通過這些方式都可以在軟件層面上把不同的應用隔離出來,但更大的問題在于隔離完以后該怎么辦?通訊怎么解決、調度怎么解決、資源怎么保證,把這些問題都解決好才是更具挑戰性的難題。”
從非技術層面來看,就是老生常談的一些問題了,比如缺乏行業技術標準,以及組織架構不匹配等,但這些非技術問題解決起來的難度可能比技術問題更大。
行業技術標準的問題
對于自動駕駛系統來講,L0~L2有相應的標準。但是高階自動駕駛尚處于演進過程中,業界沒有統一的標準:傳感器方案沒有統一,感知的數據格式不一致,那么,它對芯片處理架構的需求不一樣。可想而知,把高階自動駕駛和豐富的座艙功能進行跨域融合和打通,形成所謂的“艙駕一體”,在業內更是沒有統一的技術和產品標準去約束。
“艙駕一體落地需要行業標準的推動,甚至需要強迫一些廠商逐漸把他們的軟件架構打開。制定行業標準的目的就是把大家的利益統一起來,誰不跟著行業標準走,誰就會吃虧、掉隊,甚至面臨淘汰,這樣才能逐漸推動整個行業的發展和進步。”某Tier1智駕域控專家介紹說。
組織架構方面的問題
針對艙泊行一體方案,研發部門的分工問題目前雖然已經被大家普遍意識到了,解決問題需要芯片廠家、主機廠以及一級供應商的通力協作。目前,在實施層面,主機廠的座艙和智駕項目大部分還依然是由兩個獨立的部門去完成,怎么能夠跨部門把這個項目去落地, 需要有更符合方案需求、更具競爭力的產品以及全方位的技術支持來一起推動方案落地量產。
另外,目前大部分座艙和智駕系統分別還需要選擇多個不同的供應商來完成,如何提供有競爭力的產品,在單一芯片上實現座艙、泊車以及行車輔助駕駛功能,幫助整車廠優化成本,降低研發投入,提升盈利;給終端消費者帶來更優的用戶體驗,是芯片廠家和整車廠商所共同面對的機遇與挑戰。
芯擎科技戰略業務發展副總裁孫東認為:“做艙駕一體需要芯片廠家、主機廠或者Tier1在座艙開發、泊車開發和行車開發方面有一定的積累。因此,艙駕一體落地更大的挑戰是要提供實際需求的產品,相比現有方案,要能夠給整車廠降本增效,能夠讓參與者受益和提升競爭力。新生事物肯定要打破以前的慣性,以前任何的一個組織架構都受到當時的技術條件和產品形態影響。隨著市場的發展和技術的進步,艙泊行一體方案的發展,也會隨之有新的東西誕生。對于芯片廠、軟件公司、Tier1以及主機廠,都是很大的挑戰,從產品技術規劃、供應商的選擇、合作方式以及團隊組織架構方面,都需要有做出相應的調整來加速這個趨勢的發展,使自身更好的在技術方案演進的過程中受益,并成為行業發展的引領者。”
3)“艙駕一體”的演進路徑
艙駕融合是未來的發展趨勢,已經成為行業內的共識。雖然現在還存在一些問題和挑戰,但是只要我們發現了問題,問題終究會被逐個解決。但是,大家依然會關心:單SoC芯片的艙駕一體方案什么時候可以落地?艙駕一體的發展路線又將會是怎樣的呢?
后摩智能信曉旭認為:“艙駕一體的發展路徑應該是從One Box 到One Board,再到One Chip,循序漸進式的發展,不太可能一下子就跨越到單SoC芯片艙駕一體的‘完美’解決方案。比如,先通過One Box或One Board的方案,先試著去解決組織上的問題,把開發過程中碰到的問題以及各方的職責先梳理清楚,把該踩的坑先踩一遍。”
多數人基本贊同艙駕一體會走漸進式的發展路線,在硬件層面,會從One Box,One Board,再到One Chip。同樣,在功能層面,也是會先集成已經成熟穩定的功能,慢慢再集成更高階、更復雜的功能。
談到艙駕一體發展路線時,芯馳科技CTO孫鳴樂認為:“座艙整合智駕相關功能,一個可能的路線是:座艙首先集成360環視、APA等泊車功能,再進一步集成ADAS行車功能,然后再集成更高階的自動駕駛功能。L2.x的ADAS和座艙的集成,是相對比較有可行性的。而對于L3級別自動駕駛的集成,其難題在于,自動駕駛的邊界到現在為止還沒有完全清晰。比如最近“有圖”和“無圖”的方案討論得很激烈,激光雷達是否會成為標配大家也有不同的意見,這些都是高階智能駕駛面臨的方向性問題,在這些技術路線問題尚未統一的情況下,高階智駕功能就不太容易和座艙系統做集成。”
“從長期來看,終極方案 —— 單SoC芯片艙駕一體方案的發展是大方向。但現階段,由于高階智駕的功能需求尚未完全穩定,目前市場也沒有性能和成本都比較理想的單SoC芯片能夠很好地支持座艙和高階自動駕駛的所有功能。因此,在市場需求的驅動下,當前艙駕一體會停留在L2.x的ADAS和座艙功能集成,高階自動駕駛和座艙功能還會采用多SoC芯片方案來實現。
芯擎科技孫東也基本認同這樣的演進路線:“ 目前,L2及以下的輔助駕駛功能,傾向于直接集成到座艙的SoC芯片去完成,芯擎科技現有產品的算力能夠完全滿足需求,并且具有極佳的性價比。L3以上的高階智能駕駛方案,傾向于用更大算力的智駕SoC芯片去實現。
“ 目前,輔助駕駛在市場的滲透率也才30%左右,NOA功能的滲透率更低。如果有企業率先在市場上把艙駕一體方案推出來,并且切實降低了成本或在不增加用戶成本的基礎上,將原本中高端車型的智駕功能擴大到中低端車型,輔助駕駛的滲透率將會更快的提升,整個行業都會受益。新的事物進入到市場上,肯定要有一定的導入期。只要方案有價值,并且是可靠的,方案的全行業落地實現無非就是時間上的問題。”
關于艙駕一體方案的量產落地時間問題,徐曉煜認為:“討論艙駕一體需要相對準確地定義不同的市場階段所需要融合的東西。當前已進入成熟期的L2+級別自動駕駛與已大規模普及的座艙功能的融合,2025年起會進入量產和快速發展期。
“更高算力以及更高階智駕的融合尚需時間,隨著下一階段未來5年高階智駕的突破,面向2028年后的融合功能邊界會逐漸清晰。同時,下一代工藝所支撐的新一代融合SoC芯片也會面世,進而可以支撐更高算力性能,更多算力類型的需求。
“可以看到,一些主機廠和Tier1已經開始籌備艙駕一體的平臺項目,可以預見2024年將是艙駕一體突破期的起點,目前企業在協調不同部門開發模式上的挑戰,軟件上集成管理更多大型軟件模塊的挑戰,新型芯片的軟硬件完善和成熟方面挑戰等,都會隨著領先的OEM/Tier1的實際項目展開而得到快速解決。”
4)“艙駕一體”需要一款什么樣的車載AI芯片?
對于單芯片艙駕一體方案,按實現的難易程度可以劃分為:輕量級單SoC艙駕一體和高階單SoC艙駕一體。
輕量級單SoC艙駕一體方案,會集成成熟的L2級的駕駛輔助功能+基本的座艙功能。面向的細分市場主要是針對20~25萬左右的車型。徐曉煜認為:“對于這類的芯片,性價比是第一要素,通過單芯片最大程度減少系統元器件數量。除了可以將座艙和智駕各自需要的算力類型安全可靠地集成在一個芯片架構之上,還需要考慮將獨立MCU、獨立的外圍接口芯片等都盡可能地做集成。挑戰在于對芯片的架構、綜合性能、面積、功耗等都帶來了新的問題需要攻克。”
高階單SoC艙駕一體方案,將會集成L2+甚至L3以上的高階智能駕駛功能+豐富的座艙功能。未來,這樣的方案必然是用于搭載于高端車型上。但是,由于高階智能駕駛和高階智能座艙的功能迭代和技術發展路線尚未完全收斂,同時,目前也尚未有一款合適的SoC芯片推出,所以,短期內很難量產落地。那么,那這樣一款芯片應該具備什么樣的特質呢?
高通Snapdragon Flex SoC 參考方案示意圖(圖片來源-高通)
創新的硬件架構:滿足跨域多場景需求,能夠基于虛擬化技術將異構資源進行合理和安全地隔離分配 —— 把不同類型的算力,根據不同場景,以不同規格和安全要求進行靈活的搭配和組合。
高算力需求:實現城區NOA等高階智能駕駛功能,對于芯片的AI算力需求也在逐漸增加,有效AI算力可能至少需要在200TOPS,同時還需要滿足座艙內影音娛樂所需要的強大的渲染能力和通用算力需求,因此對于GPU和CPU的算力資源也必然會有較大的需求。
具備較為豐富的外設接口:之前座艙和智駕SoC芯片分別對應有各自獨立的外設接口,現在兩者進行整合后,相當于要在這一顆芯片上預留好之前所有的接口。比如,CES 2024 上,暢行智駕正式推出了面向中央計算的單SOC 艙駕融合域控制解決方案“RazorDCX Tarkine”。面向自動駕駛,其支持11V5R12USS接入,預留12路CAN/CANFD 接口,并提供8路車規級以太網接口;面向座艙,支持多屏互動、音頻放大器、車載音頻總線(A2B)以及面向媒體的系統傳輸總線(MOST)接口與連接。
總之,實現高階的單SoC艙駕一體方案,對SoC芯片的要求會更高:需要在設計芯片時,就能規劃好座艙和智駕對CPU、GPU及NPU等各種算力的類型的需求,并在可行的工藝制程下,全面靈活地實現性能、功耗和成本之間的最佳平衡。
三、如何才算一款“好用”的車載AI芯片?
上一篇:小米SU7引爆市場,國產芯迎新增量?
下一篇:英特爾發布全新SoC解決方案,大幅降低成本,加速電動汽車創新
- 熱門資源推薦
- 熱門放大器推薦