英飞凌AURIX™ TC4x最详技术解读

作者：纾为时间：2025-04-10 来源：汽车电子与软件

加入技术交流群
- 扫码加入
  和技术大咖面对面交流
  海量资料库查询

本文引用地址：https://www.eepw.com.cn/article/202504/469290.htm

在 6 月 28 日的第二届英飞凌汽车创新峰会上，英飞凌科技正式发布了采用28 纳米工艺技术生产的 AURIX™ TC4x 系列微控制器（MCU），进一步增强其 AURIX™ 微控制器家族的产品阵容。

图1

#01

产品 Overview

1.1 AURIX™ TC4x 产品总览

2014 年，英飞凌推出了第一代 AURIX™ TC2x 系列，首次在单片机中集成多达三个 TriCore™ 内核，为汽车电子带来了前所未有的多核处理能力。

2018 年，第二代 AURIX™ TC3x 系列推出，进一步将多核处理能力提升到新高度，集成多达六个 TriCore™ 内核。该系列在实时性能、功能安全（最高等级 ASIL-D）、信息安全等方面表现卓越，特别适用于各种汽车应用，也在市场上或得了巨大的成功。

如今，英飞凌推出了新一代 AURIX™ TC4x 系列。该系列采用新一代 TriCore™ 1.8 内核，并引入了增强性能的加速器套件，包括并行处理单元（PPU），为人工智能和实时控制应用提供强大支持。主要面向电气化领域（BMS、逆变器等）、区域控制、ADAS、底盘和车身控制领域，如下图所示：

图2

1.2 AURIX™ TC4x功能概述

针对上述场景，TC4x 从功能安全、信息安全、高速内部通信路由、内核等方面做了进一步提升，整体架构如下图所示：

图3

与 TC3x 相比，TC4x 系列各方面进一步升级：

1.CPU升级

● TriCore™从 v1.6.2 升级到 v1.8，频率从 300MHz 提升到 500MHz，最高支持 6 对锁步核同时运行，算力已逼近低端 SoC，例如 TC4Dx 系列算力可达 8000 DMIPS（双核 A53 算力 7360 DMIPS）；

● 新增两级 MPU，引入虚拟化功能；

● 新增双精度浮点运算，满足 IEEE754-2019；

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

2.NvM升级

● 容量上最高支持 25MB NVM，基于 TC3xx 的 AB SWAP 机制进行迭代优化，真正实现了零停机升级；

● 在后续产品中引入 RRAM 技术，该技术与台积电共同研发已久，这对汽车 OTA 格局是不小的冲击。

3.新增加速引擎

● PPU（Parallel Processing Unit) ：并行处理单元，旨在替 CPU 完成复杂信号处理和数学运算，助力 AI 功能在 MCU 中的安全实现；

● CSRM（Cyber Security Real-time Module）CSS（Cyber Security Satellite）：硬件密码加速器；与 TC3x HSM 相比，TC4x 提供两个不同的硬件加密模块，支持的加密算法和加密性能得到进一步提升，在后量子密码时代独树一帜；

● CRE（CAN Routing Engine）DRE（ Data Routing Engine) ：数据路由引擎；硬件层面实现 CAN-CAN 、CAN-ETH 、CAN-MEM 数据的路由和转发。

4.新增可扩展高速通信接口

● PCIe

● CAN XL

● 5Gbps Ethernet

上述接口在区域控制器中以以太网环形网络架构中实现了高带宽、低延迟的效果。

接下来，我们就详细解读其关键技术。

#02

关键技术解读

2.1 NvM

2.1.1 NvM容量

NvM 容量和 RWW（Read-while-Write）特性向来是 Tier 1 、OEM 在产品芯片选型时最关心的 Feature 之一。

为适应新的区域控制器架构要求，支持多应用融合，TC4x 延续了 TC3x 的 NvM 设计精髓并做出优化，每个内核可通过独立接口快速访问 2 个 PFlash Bank，实现真正零待机 SOTA；设计出独立 Security PDFlash ，保证 Host 与 HSM 之间物理隔离，具体示意如下：

图4

CPU 通过 PFI 接口可以独立访问与之关联的 PFlash Bank，实现快速指令访问，并且由于 CPU 关联两块 PFlash ，实现了 RWW，对 SOTA 非常友好。

通过 DMU 访问 DFlash ；通过 DMU 、FSI 对 PD Flash 进行操作；

Host 每个 PFlash Bank 容量为 2MB，最高支持 24MB(6 CPU*2 Bank*2 MB) ，Security PFlash 为 1MB，总计 25MB；

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

从地址映射上，仍然延续 TC3x 的 Cacheable 地址 8H，Non-Cacheable 地址 AH，这在使用习惯上是非常好的继承。

然而随着 MCU 算力要求不断提高，倒逼工艺制造向先进制程进发，28nm、22nm 甚至 16nm 已经被提上日程，但 eFlash 微缩化困难严重阻碍了进程，该瓶颈亟待解决。

2.1.2 RRAM开辟NvM新道路

据台积电官网介绍，英飞凌与台积电早已联合研发 RRAM(Resistive RAM) ，致力打破 22nm、 28nm 车规 MCU 的 NvM 瓶颈。

RRAM 相比于 eFlash ，具有更高的扩展性、更低的成本和更低的功耗。

作为结构最简单的存储技术，它看上去像一个三明治，绝缘介质层（阻变层）被夹在两层金属之间，形成由上、下电极和阻变层构成金属-介质层-金属（ metal-insulator-metal ，简称 MIM）三层结构。

图5

RRam 利用阻变原理实现存储等功能，基于阻变层中导电通路（一般称为 conductive filament, 导电细丝）实现，通过在上、下电极施加不同的脉冲电压激励，使介质层发生阻变，产生物理性变化。

导电细丝会在阻变层中呈现导通或断开两种状态：非易失性的低阻态（Low Resistance State， LRS）或高阻态（ High Resistance State， HRS），从而实现了“0”，“ 1”状态的区分和存储。

了解其原理后，作为软件工程师最关心的还是怎么用，如果能做到软件移植平滑，指令操作上比TC3xx更简单，这将在OEM/Tier1做区域控制器产品选型时是一个非常棒的加分项。

英飞凌与台积电联合开发 RRAM 已有十余年，技术上是否有更进一步的创新？未来会用在 TC4x 哪些产品型号，我们拭目以待。

2.2 SOTA

之前我们描述了 TC4x 关于 NvM 的排布，很明显一颗 CPU 关联 2 块 PFlash Bank 是非常有利于 SOTA 实现。

在 TC3x 上面我们基于硬件做 AB SWAP，特别是 TC39x 系列，虽然说存在异步域的情况，但在逻辑地址和物理 bank 的映射上还是存在让人困惑的地方，如下图：

图6

可以看到，虽然逻辑地址没有改变，但在不同地址映射模式下 PF01 与 PF23 切换，PF4 与 PF5 切换，最容易让人迷糊的就是逻辑地址与物理 Bank 的映射问题，锁板子的事情常常发生。

这个问题在 TC4x 系列有所缓解，在不使用硬件 SOTA 机制的情况下(这里暂时不聊 HSM PFlash)，最高可支持 6 核 24MB 线性地址访问(0x8000 0000-0x817F FFFF) ，如下图：

图7

那当我们使用了SOTA机制，好玩的来了，如下图：

图8

地址做成了连续，该模式下 Host 最高支持 12MB，同时，为了不混淆，还特意将 Inactive Back 的地址往后挪了一点(0x8200 0000) ，这样咱们在使用上就明晰了很多。

TC4x 的 SOTA 支持两种地址映射，上图为 A 模式， B 模式下灰色和橙色 Bank 对调即可。

当然 HSM 同理，虽然它只有一个 1MB 的 PFlash，仍然支持 AB SOTA，看来这个 Flash IP 还重新规划了 Bank 容量的。

在 SOTA 使能和配置方面，继续使用 UCB 进行 SOTA 的使能和 Bank 切换，经典的 55h 对应 A 地址映射，AA 对应 B 地址映射。

总结下来，TC4x 应该是总结了 TC3x 用户反馈，并且基于区域控制器做了场景分析，从使用上来看更为方便，也更容易理解。

那么聊到了区域控制，就不可避免地要谈多功能融合，而对于一颗 MCU 来说芯片资源是有限的，因此资源竞争资源隔离成为了区域控制器实现的关键技术路径。

一般来讲，应基于硬件资源隔离是最可靠的方式，但是不能资源共享给应用；于是虚拟化隔离出现了，接下来我们从虚拟化技术分类开始，掌握 TC4x 虚拟化的基本概念。

2.3 虚拟化

2.3.2 虚拟化技术

虚拟化技术按照虚拟化层次通常可以分为硬件虚拟化和操作系统虚拟化两类。

2.3.2.1 硬件虚拟化

硬件虚拟化依赖 Hypervisor（虚拟机监视器）和 CPU 的虚拟化扩展，根据 Hypervisor 部署方式，可进一步细分为 Type1和 Type2两类；

● Type1类型的虚拟化

Hypervisor 直接运行在裸硬件上，也叫作裸机虚拟化，如下图，

图9

该类型的 Hypervisor 能够直接操作控制硬件并管理多个虚拟机（ Guest VM）。每个虚拟机都有自己的操作系统和应用程序，可以完全独立运行。

● Tpye2类型的虚拟化

与Type1类型的虚拟机不一样，Type2类型虚拟化是指在已经装载好OS的硬件上运行Hypervisor，这个软件作为应用程序管理多个Guest VM。

图10

可以看到，Type 1 和 Type2 的虚拟化最大区别在于 Type 1 的 Hypervisor 可以直接操作硬件，没有多余的开销，性能相对较高；Type2 的 Hypervisor 访问硬件资源，还必须经过 Host OS。

因此在汽车领域，由于对功能安全等级、实时性有较高要求，一般均使用 Type1 的 Hypervisor，Hypervisor 之上直接运行多个客户操作系统 (GuestOS)；

那么 Hypervisor 是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？

个人理解，资源安全需要从 vCPU 调度隔离、内存隔离、存储隔离、中断虚拟化及隔离、网络隔离等方面来保证安全，如下图：

图11

在 vCPU 的调度中，常见的Armv8-R 架构提供了 EL0-EL2的等级，每个等级可运行的指令不一样，通常EL0 运行 APP，EL1 运行 GuestOS，EL2 运行Hypervisor（负责 vCPU的上下文切换），实现 GuestOS 和Hypervisor的隔离。

2.3.2.2 操作系统虚拟化

操作系统虚拟化一般就是指容器技术，由操作系统内核提供的资源隔离和控制功能，创建出多个相互隔离但共享系统内核的用户空间实例，从而实现对多系统运行能力的支持。

进一步讲，容器技术就是将操作系统所管理的计算机资源，包括进程、文件、设备、网络等分组，然后交给不同的容器使用。

容器中运行的进程只能看到分配给该容器的资源。从而达到隔离与虚拟化的目的。实现容器技术需要用到 Namespace 及 cgroups 技术。

典型代表就是 Docker 公司在 2013 推出的轻量级虚拟化技术--Docker 。结构如下图：

图12

在这种虚拟化机制下，操作系统内核被每个容器共享，每个容器使用相同的 OS，由 OS 来分配资源，不过正是因为这种多个 App 共享内核的机制，可能存在漏洞或攻击风险。因此目前容器化场景在汽车中还没看到实际应用。

2.3.2 MCU 为什么要提虚拟化

在汽车行业里，虚拟化的概念最先由座舱域引入，目的是在同一颗 SoC 上实现仪表和中控两个系统的功能，在 Hypervisor 的管理下基本可以不修改旧代码就可移植到最新的硬件上，如下图：

图13

随着区域控制器概念的提出，以前底盘、车身域控下挂节点的功能有可能会被整合或者直接移植到高性能的区域控制器 MCU 中，这种集成难度和整合工作难度不小；

试想，BCM、PowerControl、BMS 等功能即使在 OEM 里也是不同部门进行开发，在操作系统、硬件资源上差异可能很大，要想减轻集成难度，充分利用 MCU 资源，在没有虚拟化的情况下势必需要重新规划软硬件架构；

再恶劣的情况，如果下挂子节点是由供应商黑盒交付，OEM 想要完成集成工作，引入虚拟化是最省钱省事的方案，如下图：

图14

在上述示意中，我们通过 VM(Virtual Machine，虚拟机)来实现上述集成工作。虚拟机模拟了一个完整的计算机系统，包括处理器、内存、存储设备和其他硬件，这就意味着在同一台物理计算机上可以同时运行多个操作系统和应用程序。

其中，VM0 用于运行 Hypervisor，用于创建和管理虚拟化环境，例如 VM1-4，同时还负责 VM1-4 的时间调度、资源管理、数据通信等；VM1 用于电池管理系统、VM2 涵盖了 DC/DC 和充电功能、VM3 集成了 Inverter 和 PDC，VM4 可以运行车身控制，每个 VM 都可以使用独立的操作系统（ RTOS、AUTOSAR OS 等等），从某种意义上讲，VM1-4 甚至都认为自己独占了整个 MCU 资源。而从硬件角度，CPU0 里既包含了 VM1 还包含了 VM2，CPU1 里包含了 VM2 和 VM3，依次类推。

2.3.3 TC4x 的虚拟化

由于 VMn 是基于时间片分时复用芯片资源，因此对于算力和硬件虚拟化特性都提出来以前 MCU 没有的新需求。

TC4x 设计了 TC1.8 ，最高主频可达 500MHz，算力上得到巨大增加。

同时支持虚拟化辅助功能，该功能可以根据需要进行使能；

针对虚拟化，每个核有三套独立硬件资源 HRHV 、HRA 、HRB，可支持最大 8 个 VM，其中 VM0 运行 hypervisor，VM1 运行实时虚拟机，VM2-7 运行其他 VM，如下图所示：

图15

● HRVH–Hypervisor hardware resource（VM0）；

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

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

MCU上电后，如果内核支持虚拟化，那么所有 HRHV 里的资源均可以被访问了，这个时候启动代码就可以开始设置 Hypervisor 需要的状态，这里面包含了虚拟化功能的使能、关于 NMI 处理层级的配置(Hypervisor 或者普通 VM 处理) 、目标 VM 的序号等等，如下图：

图16

既然每个核支持最大8个VM，那么针对中断的处理也有对应 8 套资源，那么就引发了几个问题：

● 假设被分配到的VM此时还没有运行怎么办？

● 假设被分配到的VM此时正在处理中断怎么办？

我们按照正常物理中断处理流程做出假设，VM之间也可以进行抢占，得到如下：

正常时间片为 2000us，VM1 占用 500us，VM2 占用 1000us，VM3 占用 500us；

当 VM2 正在运行时，此时来了一个 VM1 的中断，该中断可以抢占 VM2 的时间，所以此时 Hyperviosr 需要将 VM2 的上下文保存，并切换到 VM1，让其完成 ISR 处理，然后恢复现场 VM2 继续运行；

当 VM3 正在运行时，此时来了一个 VM2 的中断，但它不可抢占 VM3 的时间，所以需要 VM3 运行完毕后切换到 VM2 的 ISR 进行处理，当然这里也挤压了 VM1 的时间。

TC4x是如何实现上述功能的呢？

在他们的设计中，每个中断 SRN 都可以被拓展分配给 1 个 VM；每个 VM 都有自己独立的中断状态控制寄存器，包括当前 VM 中断系统是否使能(简称 VMIE) 、当前 VM 的优先级(简称 VMCP) 、Pending 中断优先级(简称 VMPIP)；

为了实现运行 VM 在收到其他 VM 中断时可被抢占，新增了抢占阈值寄存器，简称 THR，好玩的就来了。

假设当前正在运行 VM1，此时来了一个 VM0 的中断，如果此时进来的 Pending 中断优先级高于 VM0 配置的抢占阈值，同时高于 VM0 的当前优先级，那么 Hypervisor 就需要进行上下文切换，返回到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        }}

同理，如果当前 VM0、VM1、VM2 同时运行，也需要执行上述步骤。如 VM2 要抢占 VM1 时，由于 VM1 独享 HRA，因此可直接切换到 HRB 让 VM2 进行中断处理。

本质上，这样的机制和透传很像，只是我们可以通过 Hypervisor 配置每个 VM 的中断状态控制器寄存器、抢占阈值寄存器来实现中断实时性的控制，例如：

当我们把阈值配置为最大时，此时谁也无法进行抢占(Trap 除外)，只能得到时间片走完；如果阈值配置为最小，那就是直接透传，这时候性能最优。

2.3.4 基于TC4x的Hypervisor

通过 2.3.3 小结，我们对 TC4xx 的虚拟化有了一定的了解，也不难看出，其中最关键的还是运行在裸板上的 Hypervisor 软件。

目前已知的关于MCU Hypervisor 软件主要由基础软件供应商提供，例如Vector 的 veHypervisor，基于 Type1Hypervisor 架构实现，满足 ASIL-D 要求，如下图：

图17

EB 与英飞凌联合开发基于 AURIX TC4x 的 AutoCore OS 和 EB tresos Embedded Hypervisor，支持 OEM 和 Tier 1 更轻松地开发和部署基于 AUTOSAR Classic 标准的汽车 E/E 架构，助力下一代车辆的加速开发：

图18

ETAS RTA Lightweight Hypervisor

图19

不管上述各家对于 Hypervisor 的描述如何变化，本质上还是在强调在一颗 MCU 里多 VM 场景的并行运行和资源隔离，不仅要支持不同操作系统，还要需要稳定安全高效的时间调度机制来支持多 VM。

2.4 加速器

2.4.1 PPU

在 ADAS 领域里，大家很有默契地几乎都用 TC39x 系列作为功能安全岛，除此之外 MCU 还承接车内 CAN 报文收发，雷达数据等辅助处理，常见架构如下：

图20

根据雷达在汽车布局位置分为前雷达(Front Central Radar) 、侧后雷达(Side-Rear Radar)以及泊车系统使用的超声波雷达(Ultra Sonic Sensor)；

根据测距不同分为 24GHz 和 77GHz 雷达，可见信号处理上的复杂性；而在雷达数据的处理上通常都会用到快速傅里叶变换(FFT)用于频率分析、波束形成等等，在数据处理上针对单个数据点使用标量算法，针对多个数据点组合进行向量运算等，在波束形成时进行矩阵运算，在 TC3x 系列中，我们使用 RIF 和 SPU 来完成上述计算，如下图：

图21

而随着智能驾驶迈向新的阶段，复杂应用模型需要更强大的计算能力，为此，TC4x 产品里设计出并行处理单元 PPU( Parallel Processing Unit) ，用于实现数据处理需求大或执行时间要求快的模型，例如信号滤波、算法处理、模型预测控制等。

PPU其结构如下：

图22

● 标量处理单元里包含了一颗 32bit 标量核，它支持双精度浮点运算，用于执行大量标量运算；

● 向量 DSP 处理单元，位宽 128~256bit ，支持 SIMD(单指令多数据)指令，支持浮点向量运算、专用信号处理，提高计算效率；

● DMA、Memory：分别用于数据搬运，输入和输出临时存储等。

除了智驾方面应用，PPU 也可应用在电机矢量控制上，在算法上坐标变换使用三角函数、观测器迭代、锁相环鉴相等等操作是非常消耗 MCU 的计算资源，PPU 中的 Vector DSP 单元可以有效加速实时观测计算，从而帮助 Tricore 提高运行效率。

PPU 还可用于基于 AI 的电池诊断，包括镀锂层检测，电池健康状态(SoH)和老化轨迹预测，剩余使用寿命（RUL）预测等等。

在开发 PPU 时，我们可以结合相关应用模型和 PPU 对应软件库。

Mathworks 在官方提供了基于 TC4x 的 Tricore 与 PPU 通信的模型、基于 PPU 的电机矢量控制模型等；

新思科技为 TC4x 的 PPU 提供了丰富的软硬件支持，在向量 DSP、神经网络处理、AUTOSAR 适配等提供了丰富的资源，例如 MetaWare Development Toolkit、MetaWare Neural Network SDK 用于基于 PPU 优化的模型变异等等；

图23

总体而言，PPU 主要是为了 Tricore 承接了 A I 、电机控制、区域控制等复杂的信号处理和数学运算；由于 PPU 本身特性，在计算效率上更快，Tricore 则主要用于控制，这与现有异构 SoC 的设计理念已经非常相似了；我想这也是未来 MCU 的发展趋势之一。

2.4.2 数据路由加速器

在整车中央计算平台等架构里的网络通信概念通常以以太网为主干，它连接了中央计算平台、各区域控制器；在区域控制器里使用其他通信网络连接下挂节点。

架构概念如下：

图24

目前主流的车内通信手段是以 CAN CANFD 和车载以太网为主，区域控制器间通过以太网为通信，在区域内仍以 CAN、CANFD 为主。因此，不同域之间的 ECU 节点进行通信，就必须要经由 CAN->ETH->CAN 的通信路径，所以这中间就存在如下问题：

● 以太网应该使用什么传输协议保证 CAN 的有效 paly load 不丢失；

● CAN 是周期广播形式，以太网多是点对点事件触发，这需要做什么样的优化？

● 区域控制器承接部分网关作用，在数据路由上需要达到什么样的性能？

对于网关来说，最重要的就是路由数据一致性和时效性。在 AUTOSAR 技术视角里，报文的路由基本都会放在PduR层级进行处理。以CANFD路由到CAN 为例，通常会经过 CAN0->CanIf->PduR->CanIf->CAN1 这样一个路径，其路由表在PduR 定义，显而易见，这在数据延迟方面做不到性能最优，我曾经为了百 us 级的路由在 CanIf 层手撸了一套定制化的PduR，头大不已。因此一直在想如果在硬件设计这样一套路由机制，将PduR中的路由表承接下来，那这数据路由的延迟将会大大降低，概念如下图所示：