英飛凌AURIX? TC4x最詳技術(shù)解讀

在 6 月 28 日的第二屆英飛凌汽車(chē)創(chuàng)新峰會(huì)上，英飛凌科技正式發(fā)布了采用28 納米工藝技術(shù)生產(chǎn)的 AURIX? TC4x 系列微控制器（MCU），進(jìn)一步增強(qiáng)其 AURIX? 微控制器家族的產(chǎn)品陣容。

圖1

#01

產(chǎn)品 Overview

1.1 AURIX? TC4x 產(chǎn)品總覽

2014 年，英飛凌推出了第一代 AURIX? TC2x  系列，首次在單片機(jī)中集成多達(dá)三個(gè) TriCore?  內(nèi)核，為汽車(chē)電子帶來(lái)了前所未有的多核處理能力。

2018 年，第二代 AURIX? TC3x 系列推出，進(jìn)一步將多核處理能力提升到新高度，集成多達(dá)六個(gè) TriCore? 內(nèi)核。該系列在實(shí)時(shí)性能、功能安全（最高等級(jí) ASIL-D）、信息安全等方面表現(xiàn)卓越，特別適用于各種汽車(chē)應(yīng)用，也在市場(chǎng)上或得了巨大的成功。

如今，英飛凌推出了新一代 AURIX? TC4x  系列。該系列采用新一代 TriCore?  1.8 內(nèi)核，并引入了增強(qiáng)性能的加速器套件，包括并行處理單元（PPU），為人工智能和實(shí)時(shí)控制應(yīng)用提供強(qiáng)大支持。主要面向電氣化領(lǐng)域（BMS、逆變器等）、區(qū)域控制、ADAS、底盤(pán)和車(chē)身控制領(lǐng)域，如下圖所示：

圖2

1.2 AURIX? TC4x功能概述

針對(duì)上述場(chǎng)景，TC4x 從功能安全、信息安全、高速內(nèi)部通信路由、內(nèi)核等方面做了進(jìn)一步提升，整體架構(gòu)如下圖所示：

圖3

與 TC3x 相比，TC4x 系列各方面進(jìn)一步升級(jí)：

1.CPU升級(jí)

●   TriCore?從 v1.6.2 升級(jí)到 v1.8，頻率從 300MHz 提升到 500MHz，最高支持 6 對(duì)鎖步核同時(shí)運(yùn)行，算力已逼近低端 SoC，例如 TC4Dx 系列算力可達(dá) 8000 DMIPS（雙核 A53 算力 7360 DMIPS）；

●   新增兩級(jí) MPU，引入虛擬化功能；

●   新增雙精度浮點(diǎn)運(yùn)算，滿(mǎn)足 IEEE754-2019；

●   新增 128bit loadstore 指令以提升效率。

2.NvM升級(jí)

●   容量上最高支持 25MB NVM，基于 TC3xx 的 AB SWAP 機(jī)制進(jìn)行迭代優(yōu)化，真正實(shí)現(xiàn)了零停機(jī)升級(jí)；

●   在后續(xù)產(chǎn)品中引入 RRAM 技術(shù)，該技術(shù)與臺(tái)積電共同研發(fā)已久，這對(duì)汽車(chē) OTA 格局是不小的沖擊。

3.新增加速引擎

●   PPU（Parallel Processing Unit) ：并行處理單元，旨在替 CPU 完成復(fù)雜信號(hào)處理和數(shù)學(xué)運(yùn)算 ，助力 AI 功能在 MCU 中的安全實(shí)現(xiàn)；

●   CSRM（Cyber Security Real-time Module）CSS（Cyber Security Satellite）：硬件密碼加速器；與 TC3x HSM 相比，TC4x 提供兩個(gè)不同的硬件加密模塊，支持的加密算法和加密性能得到進(jìn)一步提升，在后量子密碼時(shí)代獨(dú)樹(shù)一幟；

●   CRE（CAN Routing Engine）DRE（ Data Routing Engine) ：數(shù)據(jù)路由引擎；硬件層面實(shí)現(xiàn) CAN-CAN 、CAN-ETH 、CAN-MEM 數(shù)據(jù)的路由和轉(zhuǎn)發(fā)。

4.新增可擴(kuò)展高速通信接口

●   PCIe

●   CAN XL

●   5Gbps Ethernet

上述接口在區(qū)域控制器中以以太網(wǎng)環(huán)形網(wǎng)絡(luò)架構(gòu)中實(shí)現(xiàn)了高帶寬 、低延遲的效果。

接下來(lái)，我們就詳細(xì)解讀其關(guān)鍵技術(shù)。

#02

關(guān)鍵技術(shù)解讀

2.1 NvM

2.1.1 NvM容量

NvM 容量和 RWW（Read-while-Write）特性向來(lái)是 Tier 1 、OEM 在產(chǎn)品芯片選型時(shí)最關(guān)心的 Feature 之一。

為適應(yīng)新的區(qū)域控制器架構(gòu)要求，支持多應(yīng)用融合，TC4x 延續(xù)了 TC3x 的 NvM 設(shè)計(jì)精髓并做出優(yōu)化，每個(gè)內(nèi)核可通過(guò)獨(dú)立接口快速訪(fǎng)問(wèn) 2 個(gè) PFlash Bank，實(shí)現(xiàn)真正零待機(jī) SOTA；設(shè)計(jì)出獨(dú)立 Security PDFlash ，保證 Host 與 HSM 之間物理隔離，具體示意如下：

圖4

CPU 通過(guò) PFI 接口可以獨(dú)立訪(fǎng)問(wèn)與之關(guān)聯(lián)的 PFlash Bank，實(shí)現(xiàn)快速指令訪(fǎng)問(wèn)，并且由于 CPU 關(guān)聯(lián)兩塊 PFlash ，實(shí)現(xiàn)了 RWW，對(duì) SOTA 非常友好。

通過(guò) DMU 訪(fǎng)問(wèn) DFlash ；通過(guò) DMU 、FSI 對(duì) PD Flash 進(jìn)行操作；

Host 每個(gè) PFlash Bank 容量為 2MB， 最高支持 24MB(6 CPU*2 Bank*2 MB) ，Security PFlash 為 1MB， 總計(jì) 25MB；

DFlash0 最高 1MB，DFlash1 為 128KB，均用于 EEPROM。

從地址映射上，仍然延續(xù) TC3x 的 Cacheable 地址 8H，Non-Cacheable 地址 AH，這在使用習(xí)慣上是非常好的繼承。

然而隨著 MCU 算力要求不斷提高，倒逼工藝制造向先進(jìn)制程進(jìn)發(fā)，28nm、22nm 甚至 16nm 已經(jīng)被提上日程，但 eFlash 微縮化困難嚴(yán)重阻礙了進(jìn)程，該瓶頸亟待解決。

2.1.2 RRAM開(kāi)辟NvM新道路

據(jù)臺(tái)積電官網(wǎng)介紹，英飛凌與臺(tái)積電早已聯(lián)合研發(fā) RRAM(Resistive RAM) ，致力打破 22nm、 28nm 車(chē)規(guī) MCU 的 NvM 瓶頸。

RRAM 相比于 eFlash ，具有更高的擴(kuò)展性、更低的成本和更低的功耗。

作為結(jié)構(gòu)最簡(jiǎn)單的存儲(chǔ)技術(shù)，它看上去像一個(gè)三明治，絕緣介質(zhì)層（阻變層）被夾在兩層金屬之間，形成由上、下電極和阻變層構(gòu)成金屬-介質(zhì)層-金屬（ metal-insulator-metal ，簡(jiǎn)稱(chēng) MIM）三層結(jié)構(gòu)。

圖5

RRam 利用阻變?cè)韺?shí)現(xiàn)存儲(chǔ)等功能，基于阻變層中導(dǎo)電通路（一般稱(chēng)為 conductive filament, 導(dǎo)電細(xì)絲）實(shí)現(xiàn)，通過(guò)在上、下電極施加不同的脈沖電壓激勵(lì)，使介質(zhì)層發(fā)生阻變，產(chǎn)生物理性變化。

導(dǎo)電細(xì)絲會(huì)在阻變層中呈現(xiàn)導(dǎo)通或斷開(kāi)兩種狀態(tài)：非易失性的低阻態(tài)（Low Resistance State， LRS） 或高阻態(tài)（ High Resistance State， HRS），從而實(shí)現(xiàn)了“0”，“ 1”狀態(tài)的區(qū)分和存儲(chǔ)。

了解其原理后，作為軟件工程師最關(guān)心的還是怎么用，如果能做到軟件移植平滑，指令操作上比TC3xx更簡(jiǎn)單，這將在OEM/Tier1做區(qū)域控制器產(chǎn)品選型時(shí)是一個(gè)非常棒的加分項(xiàng)。

英飛凌與臺(tái)積電聯(lián)合開(kāi)發(fā) RRAM 已有十余年， 技術(shù)上是否有更進(jìn)一步的創(chuàng)新？ 未來(lái)會(huì)用在 TC4x 哪些產(chǎn)品型號(hào)，我們拭目以待。

2.2 SOTA

之前我們描述了 TC4x 關(guān)于 NvM 的排布，很明顯一顆 CPU 關(guān)聯(lián) 2 塊 PFlash Bank 是非常有利于 SOTA 實(shí)現(xiàn)。

在 TC3x 上面我們基于硬件做 AB SWAP，特別是 TC39x 系列，雖然說(shuō)存在異步域的情況，但在邏輯地址和物理 bank 的映射上還是存在讓人困惑的地方，如下圖：

圖6

可以看到，雖然邏輯地址沒(méi)有改變，但在不同地址映射模式下 PF01 與 PF23 切換，PF4 與 PF5 切換，最容易讓人迷糊的就是邏輯地址與物理 Bank 的映射問(wèn)題，鎖板子的事情常常發(fā)生。

這個(gè)問(wèn)題在 TC4x 系列有所緩解，在不使用硬件 SOTA 機(jī)制的情況下(這里暫時(shí)不聊 HSM PFlash)，最高可支持 6 核 24MB 線(xiàn)性地址訪(fǎng)問(wèn)(0x8000 0000-0x817F FFFF) ，如下圖：

圖7

那當(dāng)我們使用了SOTA機(jī)制，好玩的來(lái)了，如下圖：

圖8

地址做成了連續(xù)，該模式下 Host 最高支持 12MB，同時(shí)，為了不混淆，還特意將 Inactive Back 的地址往后挪了一點(diǎn)(0x8200 0000) ，這樣咱們?cè)谑褂蒙暇兔魑撕芏唷?/p>

TC4x 的 SOTA 支持兩種地址映射，上圖為 A 模式， B 模式下灰色和橙色 Bank 對(duì)調(diào)即可。

當(dāng)然 HSM 同理，雖然它只有一個(gè) 1MB 的 PFlash，仍然支持 AB SOTA，看來(lái)這個(gè) Flash IP 還重新規(guī)劃了 Bank 容量的。

在 SOTA 使能和配置方面，繼續(xù)使用 UCB 進(jìn)行 SOTA 的使能和 Bank 切換，經(jīng)典的 55h 對(duì)應(yīng) A 地址映射，AA 對(duì)應(yīng) B 地址映射。

總結(jié)下來(lái)，TC4x 應(yīng)該是總結(jié)了 TC3x 用戶(hù)反饋，并且基于區(qū)域控制器做了場(chǎng)景分析，從使用上來(lái)看更為方便，也更容易理解。

那么聊到了區(qū)域控制，就不可避免地要談多功能融合，而對(duì)于一顆 MCU 來(lái)說(shuō)芯片資源是有限的，因此資源競(jìng)爭(zhēng)資源隔離成為了區(qū)域控制器實(shí)現(xiàn)的關(guān)鍵技術(shù)路徑。

一般來(lái)講，應(yīng)基于硬件資源隔離是最可靠的方式，但是不能資源共享給應(yīng)用；于是虛擬化隔離出現(xiàn)了，接下來(lái)我們從虛擬化技術(shù)分類(lèi)開(kāi)始，掌握 TC4x 虛擬化的基本概念。

2.3 虛擬化

2.3.2 虛擬化技術(shù)

虛擬化技術(shù)按照虛擬化層次通?？梢苑譃橛布摂M化和操作系統(tǒng)虛擬化兩類(lèi)。

2.3.2.1 硬件虛擬化

硬件虛擬化依賴(lài) Hypervisor（虛擬機(jī)監(jiān)視器）和 CPU 的虛擬化擴(kuò)展，根據(jù) Hypervisor 部署方式，可進(jìn)一步細(xì)分為 Type1和 Type2兩類(lèi)；

●   Type1類(lèi)型的虛擬化

Hypervisor 直接運(yùn)行在裸硬件上，也叫作裸機(jī)虛擬化，如下圖，

圖9

該類(lèi)型的 Hypervisor 能夠直接操作控制硬件并管理多個(gè)虛擬機(jī)（ Guest VM）。每個(gè)虛擬機(jī)都有自己的操作系統(tǒng)和應(yīng)用程序，可以完全獨(dú)立運(yùn)行。

●   Tpye2類(lèi)型的虛擬化

與Type1類(lèi)型的虛擬機(jī)不一樣，Type2類(lèi)型虛擬化是指在已經(jīng)裝載好OS的硬件上運(yùn)行Hypervisor，這個(gè)軟件作為應(yīng)用程序管理多個(gè)Guest VM。

圖10

可以看到，Type 1 和  Type2 的虛擬化最大區(qū)別在于 Type 1 的 Hypervisor 可以直接操作硬件，沒(méi)有多余的開(kāi)銷(xiāo)，性能相對(duì)較高；Type2 的 Hypervisor 訪(fǎng)問(wèn)硬件資源，還必須經(jīng)過(guò) Host OS。

因此在汽車(chē)領(lǐng)域，由于對(duì)功能安全等級(jí)、實(shí)時(shí)性有較高要求，一般均使用 Type1 的 Hypervisor，Hypervisor 之上直接運(yùn)行多個(gè)客戶(hù)操作系統(tǒng)  (GuestOS)；

那么 Hypervisor 是如何來(lái)管理和隔離硬件資源，保證各個(gè)不同功能的應(yīng)用程序的資源使用安全和資源調(diào)度？

個(gè)人理解，資源安全需要從 vCPU 調(diào)度隔離、內(nèi)存隔離、存儲(chǔ)隔離、中斷虛擬化及隔離 、網(wǎng)絡(luò)隔離等方面來(lái)保證安全，如下圖：

圖11

在 vCPU 的調(diào)度中，常見(jiàn)的Armv8-R 架構(gòu)提供了 EL0-EL2的等級(jí)，每個(gè)等級(jí)可運(yùn)行的指令不一樣，通常EL0 運(yùn)行 APP，EL1 運(yùn)行 GuestOS，EL2 運(yùn)行Hypervisor（負(fù)責(zé) vCPU的上下文切換），實(shí)現(xiàn) GuestOS 和Hypervisor的隔離。

2.3.2.2 操作系統(tǒng)虛擬化

操作系統(tǒng)虛擬化一般就是指容器技術(shù)，由操作系統(tǒng)內(nèi)核提供的資源隔離和控制功能，創(chuàng)建出多個(gè)相互隔離但共享系統(tǒng)內(nèi)核的用戶(hù)空間實(shí)例，從而實(shí)現(xiàn)對(duì)多系統(tǒng)運(yùn)行能力的支持。

進(jìn)一步講，容器技術(shù)就是將操作系統(tǒng)所管理的計(jì)算機(jī)資源，包括進(jìn)程、文件、設(shè)備、網(wǎng)絡(luò)等分組，然后交給不同的容器使用。

容器中運(yùn)行的進(jìn)程只能看到分配給該容器的資源。從而達(dá)到隔離與虛擬化的目的。實(shí)現(xiàn)容器技術(shù)需要用到 Namespace 及 cgroups 技術(shù)。

典型代表就是 Docker 公司在 2013 推出的輕量級(jí)虛擬化技術(shù)--Docker 。結(jié)構(gòu)如下圖：

圖12

在這種虛擬化機(jī)制下，操作系統(tǒng)內(nèi)核被每個(gè)容器共享，每個(gè)容器使用相同的 OS，由 OS 來(lái)分配資源，不過(guò)正是因?yàn)檫@種多個(gè) App 共享內(nèi)核的機(jī)制，可能存在漏洞或攻擊風(fēng)險(xiǎn)。因此目前容器化場(chǎng)景在汽車(chē)中還沒(méi)看到實(shí)際應(yīng)用。

2.3.2 MCU 為什么要提虛擬化

在汽車(chē)行業(yè)里，虛擬化的概念最先由座艙域引入，目的是在同一顆 SoC 上實(shí)現(xiàn)儀表和中控兩個(gè)系統(tǒng)的功能，在 Hypervisor 的管理下基本可以不修改舊代碼就可移植到最新的硬件上，如下圖：

圖13

隨著區(qū)域控制器概念的提出，以前底盤(pán)、車(chē)身域控下掛節(jié)點(diǎn)的功能有可能會(huì)被整合或者直接移植到高性能的區(qū)域控制器 MCU 中，這種集成難度和整合工作難度不?。?/p>

試想，BCM、PowerControl、BMS 等功能即使在 OEM 里也是不同部門(mén)進(jìn)行開(kāi)發(fā)，在操作系統(tǒng)、硬件資源上差異可能很大，要想減輕集成難度，充分利用 MCU 資源，在沒(méi)有虛擬化的情況下勢(shì)必需要重新規(guī)劃軟硬件架構(gòu)；

再惡劣的情況，如果下掛子節(jié)點(diǎn)是由供應(yīng)商黑盒交付，OEM 想要完成集成工作，引入虛擬化是最省錢(qián)省事的方案，如下圖：

圖14

在上述示意中，我們通過(guò) VM(Virtual Machine，虛擬機(jī))來(lái)實(shí)現(xiàn)上述集成工作。虛擬機(jī)模擬了一個(gè)完整的計(jì)算機(jī)系統(tǒng)，包括處理器、內(nèi)存、存儲(chǔ)設(shè)備和其他硬件，這就意味著在同一臺(tái)物理計(jì)算機(jī)上可以同時(shí)運(yùn)行多個(gè)操作系統(tǒng)和應(yīng)用程序。

其中，VM0 用于運(yùn)行 Hypervisor，用于創(chuàng)建和管理虛擬化環(huán)境，例如 VM1-4，同時(shí)還負(fù)責(zé) VM1-4 的時(shí)間調(diào)度、資源管理、數(shù)據(jù)通信等；VM1 用于電池管理系統(tǒng)、VM2 涵蓋了 DC/DC 和充電功能 、VM3 集成了 Inverter 和 PDC，VM4 可以運(yùn)行車(chē)身控制，每個(gè) VM 都可以使用獨(dú)立的操作系統(tǒng)（ RTOS、AUTOSAR OS 等等），從某種意義上講，VM1-4 甚至都認(rèn)為自己獨(dú)占了整個(gè) MCU 資源。而從硬件角度，CPU0 里既包含了 VM1 還包含了 VM2，CPU1 里包含了 VM2 和 VM3，依次類(lèi)推。

2.3.3 TC4x 的虛擬化

由于 VMn 是基于時(shí)間片分時(shí)復(fù)用芯片資源，因此對(duì)于算力和硬件虛擬化特性都提出來(lái)以前 MCU 沒(méi)有的新需求。

TC4x 設(shè)計(jì)了 TC1.8 ，最高主頻可達(dá) 500MHz，算力上得到巨大增加。

同時(shí)支持虛擬化輔助功能，該功能可以根據(jù)需要進(jìn)行使能；

針對(duì)虛擬化，每個(gè)核有三套獨(dú)立硬件資源 HRHV 、HRA 、HRB，可支持最大 8 個(gè) VM，其中 VM0 運(yùn)行 hypervisor，VM1 運(yùn)行實(shí)時(shí)虛擬機(jī)，VM2-7 運(yùn)行其他 VM，如下圖所示：

圖15

●   HRVH–Hypervisor hardware resource（VM0）；

●   HRA–Real time virtual machine hardware resource (VM1)；

●   HRB–Other virtual machine hardware resource (VM2-7)。

MCU上電后，如果內(nèi)核支持虛擬化，那么所有 HRHV 里的資源均可以被訪(fǎng)問(wèn)了，這個(gè)時(shí)候啟動(dòng)代碼就可以開(kāi)始設(shè)置 Hypervisor 需要的狀態(tài)，這里面包含了虛擬化功能的使能、關(guān)于 NMI 處理層級(jí)的配置(Hypervisor 或者普通 VM 處理) 、目標(biāo) VM 的序號(hào)等等，如下圖：

圖16

既然每個(gè)核支持最大8個(gè)VM，那么針對(duì)中斷的處理也有對(duì)應(yīng) 8 套資源，那么就引發(fā)了幾個(gè)問(wèn)題：

●   假設(shè)被分配到的VM此時(shí)還沒(méi)有運(yùn)行怎么辦？

●   假設(shè)被分配到的VM此時(shí)正在處理中斷怎么辦？

我們按照正常物理中斷處理流程做出假設(shè)，VM之間也可以進(jìn)行搶占，得到如下：

正常時(shí)間片為 2000us，VM1 占用 500us，VM2 占用 1000us，VM3 占用 500us；

當(dāng) VM2 正在運(yùn)行時(shí)，此時(shí)來(lái)了一個(gè) VM1 的中斷，該中斷可以搶占 VM2 的時(shí)間，所以此時(shí) Hyperviosr 需要將 VM2 的上下文保存，并切換到 VM1，讓其完成 ISR 處理，然后恢復(fù)現(xiàn)場(chǎng) VM2 繼續(xù)運(yùn)行；

當(dāng) VM3 正在運(yùn)行時(shí)，此時(shí)來(lái)了一個(gè) VM2 的中斷，但它不可搶占 VM3 的時(shí)間，所以需要 VM3 運(yùn)行完畢后切換到 VM2 的 ISR 進(jìn)行處理，當(dāng)然這里也擠壓了 VM1 的時(shí)間。

TC4x是如何實(shí)現(xiàn)上述功能的呢？

在他們的設(shè)計(jì)中，每個(gè)中斷 SRN 都可以被拓展分配給 1 個(gè) VM；每個(gè) VM 都有自己獨(dú)立的中斷狀態(tài)控制寄存器，包括當(dāng)前 VM 中斷系統(tǒng)是否使能(簡(jiǎn)稱(chēng) VMIE) 、當(dāng)前 VM 的優(yōu)先級(jí)(簡(jiǎn)稱(chēng) VMCP) 、Pending 中斷優(yōu)先級(jí)(簡(jiǎn)稱(chēng) VMPIP)；

為了實(shí)現(xiàn)運(yùn)行 VM 在收到其他 VM 中斷時(shí)可被搶占，新增了搶占閾值寄存器，簡(jiǎn)稱(chēng) THR，好玩的就來(lái)了。

假設(shè)當(dāng)前正在運(yùn)行 VM1，此時(shí)來(lái)了一個(gè) VM0 的中斷，如果此時(shí)進(jìn)來(lái)的 Pending 中斷優(yōu)先級(jí)高于 VM0 配置的搶占閾值，同時(shí)高于 VM0 的當(dāng)前優(yōu)先級(jí)，那么 Hypervisor 就需要進(jìn)行上下文切換，返回到VM0 處理中斷，偽代碼如下：

if (INT.VM_coming == current VM){        if ((VMPIP > VM_coming.VMCP) && (VM_coming.IE )        {               isr_routine();          }        else        {                Keep INT Pending          }}else (INT.vm_coming == VM0 ){        if ((VMPIP > VM0.VMCP) && (VMPIP > VM0.THR)
        {            Switch to HRHV                isr_routine();        }        else        {            Keep INT Pending        }}

同理，如果當(dāng)前 VM0、VM1、VM2 同時(shí)運(yùn)行，也需要執(zhí)行上述步驟 。如 VM2 要搶占 VM1 時(shí)，由于 VM1 獨(dú)享 HRA，因此可直接切換到 HRB 讓 VM2 進(jìn)行中斷處理。

本質(zhì)上，這樣的機(jī)制和透?jìng)骱芟?，只是我們可以通過(guò) Hypervisor 配置每個(gè) VM 的中斷狀態(tài)控制器寄存器、搶占閾值寄存器來(lái)實(shí)現(xiàn)中斷實(shí)時(shí)性的控制，  例如：

當(dāng)我們把閾值配置為最大時(shí)，此時(shí)誰(shuí)也無(wú)法進(jìn)行搶占(Trap 除外)，只能得到時(shí)間片走完；如果閾值配置為最小，那就是直接透?jìng)鳎@時(shí)候性能最優(yōu)。

2.3.4 基于TC4x的Hypervisor

通過(guò) 2.3.3 小結(jié)，我們對(duì) TC4xx 的虛擬化有了一定的了解，也不難看出，其中最關(guān)鍵的還是運(yùn)行在裸板上的 Hypervisor 軟件。

目前已知的 關(guān)于MCU Hypervisor 軟件主要由基礎(chǔ)軟件供應(yīng)商提供，例如Vector 的 veHypervisor，基于 Type1Hypervisor 架構(gòu)實(shí)現(xiàn)，滿(mǎn)足 ASIL-D 要求，如下圖：

圖17

EB 與英飛凌聯(lián)合開(kāi)發(fā)基于 AURIX TC4x 的 AutoCore OS 和 EB tresos Embedded Hypervisor，支持 OEM 和 Tier 1 更輕松地開(kāi)發(fā)和部署基于  AUTOSAR Classic 標(biāo)準(zhǔn)的汽車(chē) E/E 架構(gòu)，助力下一代車(chē)輛的加速開(kāi)發(fā)：

圖18

ETAS RTA Lightweight Hypervisor

圖19

不管上述各家對(duì)于 Hypervisor 的描述如何變化，本質(zhì)上還是在強(qiáng)調(diào)在一顆 MCU 里多 VM 場(chǎng)景的并行運(yùn)行和資源隔離，不僅要支持不同操作系統(tǒng)，還要需要穩(wěn)定安全高效的時(shí)間調(diào)度機(jī)制來(lái)支持多 VM。

2.4 加速器

2.4.1 PPU

在 ADAS 領(lǐng)域里，大家很有默契地幾乎都用 TC39x 系列作為功能安全島，除此之外 MCU 還承接車(chē)內(nèi) CAN 報(bào)文收發(fā)，雷達(dá)數(shù)據(jù)等輔助處理，常見(jiàn)架構(gòu)如下：

圖20

根據(jù)雷達(dá)在汽車(chē)布局位置分為前雷達(dá)(Front Central Radar) 、側(cè)后雷達(dá)(Side-Rear Radar)以及泊車(chē)系統(tǒng)使用的超聲波雷達(dá)(Ultra Sonic Sensor)；

根據(jù)測(cè)距不同分為 24GHz 和 77GHz 雷達(dá)，可見(jiàn)信號(hào)處理上的復(fù)雜性；而在雷達(dá)數(shù)據(jù)的處理上通常都會(huì)用到快速傅里葉變換(FFT)用于頻率分析、波束形成等等，在數(shù)據(jù)處理上針對(duì)單個(gè)數(shù)據(jù)點(diǎn)使用標(biāo)量算法，針對(duì)多個(gè)數(shù)據(jù)點(diǎn)組合進(jìn)行向量運(yùn)算等，在波束形成時(shí)進(jìn)行矩陣運(yùn)算，在 TC3x 系列中，我們使用 RIF 和 SPU 來(lái)完成上述計(jì)算，如下圖：

圖21

而隨著智能駕駛邁向新的階段，復(fù)雜應(yīng)用模型需要更強(qiáng)大的計(jì)算能力，為此，TC4x 產(chǎn)品里設(shè)計(jì)出并行處理單元 PPU( Parallel Processing Unit) ，用于實(shí)現(xiàn)數(shù)據(jù)處理需求大或執(zhí)行時(shí)間要求快的模型，例如信號(hào)濾波、算法處理、模型預(yù)測(cè)控制等。

PPU其結(jié)構(gòu)如下：

圖22

●   標(biāo)量處理單元里包含了一顆 32bit 標(biāo)量核，它支持雙精度浮點(diǎn)運(yùn)算，用于執(zhí)行大量標(biāo)量運(yùn)算；

●   向量 DSP 處理單元，位寬 128~256bit ，支持 SIMD(單指令多數(shù)據(jù))指令，支持浮點(diǎn)向量運(yùn)算、專(zhuān)用信號(hào)處理，提高計(jì)算效率；

●   DMA、Memory：分別用于數(shù)據(jù)搬運(yùn)，輸入和輸出臨時(shí)存儲(chǔ)等。

除了智駕方面應(yīng)用，PPU 也可應(yīng)用在電機(jī)矢量控制上，在算法上坐標(biāo)變換使用三角函數(shù)、觀(guān)測(cè)器迭代、鎖相環(huán)鑒相等等操作是非常消耗 MCU 的計(jì)算資源，PPU 中的 Vector DSP 單元可以有效加速實(shí)時(shí)觀(guān)測(cè)計(jì)算，從而幫助 Tricore 提高運(yùn)行效率。

PPU 還可用于基于 AI 的電池診斷，包括鍍鋰層檢測(cè)，電池健康狀態(tài)(SoH)和老化軌跡預(yù)測(cè)，剩余使用壽命（RUL）預(yù)測(cè)等等。

在開(kāi)發(fā) PPU 時(shí)，我們可以結(jié)合相關(guān)應(yīng)用模型和 PPU 對(duì)應(yīng)軟件庫(kù)。

Mathworks 在官方提供了基于 TC4x 的 Tricore 與 PPU 通信的模型、基于 PPU 的電機(jī)矢量控制模型等；

新思科技為 TC4x 的 PPU 提供了豐富的軟硬件支持，在向量 DSP、神經(jīng)網(wǎng)絡(luò)處理、AUTOSAR 適配等提供了豐富的資源，例如 MetaWare Development Toolkit、MetaWare Neural Network SDK 用于基于 PPU 優(yōu)化的模型變異等等；

圖23

總體而言，PPU 主要是為了 Tricore 承接了 A I 、電機(jī)控制、區(qū)域控制等復(fù)雜的信號(hào)處理和數(shù)學(xué)運(yùn)算；由于 PPU 本身特性，在計(jì)算效率上更快，Tricore 則主要用于控制，這與現(xiàn)有異構(gòu) SoC 的設(shè)計(jì)理念已經(jīng)非常相似了；我想這也是未來(lái) MCU 的發(fā)展趨勢(shì)之一。

2.4.2 數(shù)據(jù)路由加速器

在整車(chē)中央計(jì)算平臺(tái)等架構(gòu)里的網(wǎng)絡(luò)通信概念通常以以太網(wǎng)為主干，它連接了中央計(jì)算平臺(tái)、各區(qū)域控制器；在區(qū)域控制器里使用其他通信網(wǎng)絡(luò)連接下掛節(jié)點(diǎn)。

架構(gòu)概念如下：

圖24

目前主流的車(chē)內(nèi)通信手段是以 CAN  CANFD 和車(chē)載以太網(wǎng)為主，區(qū)域控制器間通過(guò)以太網(wǎng)為通信，在區(qū)域內(nèi)仍以 CAN、CANFD 為主 。因此，不同域之間的 ECU 節(jié)點(diǎn)進(jìn)行通信，就必須要經(jīng)由 CAN->ETH->CAN 的通信路徑，所以這中間就存在如下問(wèn)題：

●   以太網(wǎng)應(yīng)該使用什么傳輸協(xié)議保證 CAN 的有效 paly load 不丟失；

●   CAN 是周期廣播形式，以太網(wǎng)多是點(diǎn)對(duì)點(diǎn)事件觸發(fā)，這需要做什么樣的優(yōu)化？

●   區(qū)域控制器承接部分網(wǎng)關(guān)作用，在數(shù)據(jù)路由上需要達(dá)到什么樣的性能？

對(duì)于網(wǎng)關(guān)來(lái)說(shuō)，最重要的就是路由數(shù)據(jù)一致性和時(shí)效性。在 AUTOSAR 技術(shù)視角里，報(bào)文的路由基本都會(huì)放在PduR層級(jí)進(jìn)行處理。以CANFD路由到CAN 為例，通常會(huì)經(jīng)過(guò) CAN0->CanIf->PduR->CanIf->CAN1 這樣一個(gè)路徑，其路由表在PduR 定義，顯而易見(jiàn)，這在數(shù)據(jù)延遲方面做不到性能最優(yōu)，我曾經(jīng)為了百 us 級(jí)的路由在 CanIf 層手?jǐn)]了一套定制化的PduR，頭大不已。因此一直在想如果在硬件設(shè)計(jì)這樣一套路由機(jī)制，將PduR中的路由表承接下來(lái)，那這數(shù)據(jù)路由的延遲將會(huì)大大降低，概念如下圖所示：

圖25

為此，英飛凌 TC4x 提出了 DRE、CRE 等等用于 CAN2ETH 、CAN2CAN 等數(shù)據(jù)路由硬件加速功能。

TC4x 芯片所有加速硬件的總體結(jié)構(gòu)如下：

圖26

我們主要介紹 CRE 和 DRE 兩個(gè)模塊。

●   CRE：位于 CAN 模塊內(nèi)部， 可用于路由 CAN 消息到模塊內(nèi)部其他節(jié)點(diǎn)。

TC4x 支持 5 個(gè) CAN 模塊，每個(gè) CAN 支持 4 個(gè)節(jié)點(diǎn)，總計(jì) 20 個(gè) CAN Channel。在每個(gè) CAN 模塊內(nèi)部有一個(gè) CRE(CAN Routing Engine) ， 用戶(hù)只需要配置相應(yīng)的路由表（寄存器），即可實(shí)現(xiàn)模塊內(nèi)部節(jié)點(diǎn)間的 CAN  路由，如下：

圖27

●   DRE：用于 CAN 和 Ethernet 的相互路由，和 CRE 完成 CAN 幀到不同 CAN 模塊的路由。DRE 最重要功能就是把 CAN 幀路由給 Ethernet 幀，這就涉及到我們前面提到的問(wèn)題：這種  CAN->ETH 應(yīng)該以什么樣的格式對(duì)數(shù)據(jù)進(jìn)行封裝？

在 DRE 里采用的是 ACF 格式對(duì) CAN 進(jìn)行封裝。ACF 全稱(chēng) AVTP Control Format，它是 AVTP 協(xié)議的子集，AVTP（Audio/Video Transport Protocol）里定義了 CANCANFD ACF message 數(shù)據(jù)格式，如下圖：

圖28

在兩個(gè)區(qū)域內(nèi)節(jié)點(diǎn)需要互相通信時(shí)，發(fā)送端通過(guò) DRE 將 CAN 報(bào)文封裝 ACF 格式數(shù)據(jù)，接收端接到以太報(bào)文后根據(jù)協(xié)議提取 CAN 報(bào)文。

除此之外，DRE 配合 CRE 可完成 CAN 報(bào)文路由到特定系統(tǒng) SRAM、指定其他 CAN 模塊的不同節(jié)點(diǎn)。