2、多核架构基础：多核处理器分类与内存架构

好，咱们进入正题。多核架构，说白了就是在一个芯片里塞进多个CPU核心。听起来简单，但里面的门道可不少。我刚开始接触多核MCU时，也踩过不少坑。今天咱们就把这些基础概念掰开揉碎了讲清楚。

2.1 多核处理器分类：同构 vs 异构

多核处理器分两大类：同构多核和异构多核。这个分类，直接决定了你后续的软件架构怎么设计。

2.1.1 同构多核（Homogeneous）

同构，就是所有核心一模一样。同样的指令集，同样的性能，同样的外设访问权限。典型的例子就是Infineon TC3xx系列，里面几个TriCore核心完全一样。

特点：

  • 所有核心对称，任务可以任意分配
  • 负载均衡容易做
  • 调试相对简单

我个人的经验：同构多核最适合做「主从备份」或者「任务并行」。比如一个核心跑控制算法，另一个核心跑诊断和通信。但要注意，同构不代表没有坑——中断分配搞不好，两个核心抢同一个外设，那画面太美我不敢看。

2.1.2 异构多核（Heterogeneous）

异构，就是核心不一样。比如一个高性能核（如Cortex-R5F）搭配一个低功耗核（如Cortex-M4），或者一个主核加一个锁步核（Lockstep）。

典型场景：

  • 主核跑控制逻辑，辅核跑通信协议栈
  • 一个核跑实时任务，另一个核跑安全监控
  • 锁步核做故障检测（比如TC3xx的SMU）
注意：异构多核的难点在于——不同核心的启动顺序、内存映射、中断路由都不一样。我曾经在一个项目里，主核已经跑起来了，辅核还在等复位释放，结果通信超时。嗯，后来我加了个同步握手信号才解决。

2.2 多核内存架构：UMA vs NUMA

内存架构，说白了就是「核心怎么访问内存」。这个直接影响你的数据同步策略。

2.2.1 UMA（统一内存访问）

UMA架构下，所有核心访问内存的延迟是一样的。就像大家去同一个食堂打饭，距离一样，排队时间一样。

特点：

  • 内存控制器集中管理
  • 访问延迟一致
  • 适合小规模多核（2-4核）

实际例子：很多车载MCU的本地SRAM就是UMA架构。比如TC3xx的本地RAM（DLMU/SPLM），所有核心都能访问，延迟基本一致。

2.2.2 NUMA（非统一内存访问）

NUMA架构下，每个核心有自己的「本地内存」，访问本地内存快，访问别人的内存慢。就像你家楼下就有食堂，但去隔壁小区吃饭要多走5分钟。

特点：

  • 每个核心有私有内存（如本地SRAM）
  • 访问远程内存延迟高
  • 需要数据本地化策略

关键点：在NUMA架构下，如果你把数据放在Core0的本地内存里，Core1去读就会慢很多。我建议把频繁交互的数据放在共享内存区，或者用DMA搬运。

我踩过的坑：有一次我把一个全局变量放在Core0的本地RAM里，Core1轮询这个变量做状态同步。结果Core1每次访问都要跨总线，延迟大了好几倍，导致状态更新不及时。后来改成共享内存，问题解决。

2.3 缓存一致性协议

缓存一致性，这是多核编程里最头疼的问题之一。你想想看，Core0把变量X改成了5，但Core1的缓存里还是旧的3。那Core1读到的数据就是错的。

2.3.1 为什么需要缓存一致性？

现代MCU都有多级缓存（L1/L2）。每个核心有自己的L1缓存，但共享L2缓存。如果Core0修改了L1里的数据，Core1的L1里还是旧数据，那就乱套了。

典型问题：

  • 数据不一致：Core0写，Core1读，读到旧值
  • 伪共享（False Sharing）：两个核心修改同一个缓存行的不同变量，互相无效化

2.3.2 常见的缓存一致性协议

车载MCU里最常见的是MESI协议（Modified, Exclusive, Shared, Invalid）。

状态 含义 说明
M（Modified） 已修改 数据只在本核心缓存中，且已修改，与主存不一致
E（Exclusive） 独占 数据只在本核心缓存中，与主存一致
S（Shared） 共享 数据在多个核心缓存中，与主存一致
I（Invalid） 无效 数据无效，需要重新加载

工作原理：

  • Core0要写数据时，先发「读独占」信号
  • 其他核心收到信号后，把自己的缓存行置为Invalid
  • Core0修改数据，状态变为Modified
  • 其他核心再读时，Core0会把数据写回主存或直接转发

避坑指南：我曾经在调试时发现，两个核心共享一个全局变量，但Core1始终读不到Core0的最新值。查了半天，发现是缓存一致性协议没生效——因为变量没加volatile，编译器优化后直接从寄存器读了。记住：多核共享变量一定要加volatile，必要时用内存屏障（__sync_synchronize或AUTOSAR的Memory Barrier）。

2.3.3 伪共享（False Sharing）

伪共享是个隐蔽的坑。两个核心修改不同的变量，但这两个变量恰好在同一个缓存行（通常64字节）里。结果每次修改都导致缓存行无效化，性能急剧下降。

示例：

// 伪共享示例
struct {
    int core0_flag;  // Core0频繁修改
    int core1_flag;  // Core1频繁修改
} shared_data;  // 两个变量在同一个缓存行

解决方法：用填充（Padding）让变量对齐到不同缓存行。

// 修复伪共享
struct {
    int core0_flag;
    char padding[60];  // 填充到64字节
    int core1_flag;
} shared_data;  // 两个变量在不同缓存行

我的建议：在AUTOSAR多核开发中，尽量把每个核心的私有数据放在各自的本地内存里。共享数据用Spinlock或E2E保护。别指望缓存一致性协议能解决所有问题——它只能保证数据最终一致，但不能保证实时性。

2.4 小结

嗯，这一章内容不少。总结一下：

  • 同构多核：核心一样，任务好分配，但要注意中断和外设冲突
  • 异构多核：核心不同，适合分工，但启动和同步要小心
  • UMA：访问延迟一致，适合小规模多核
  • NUMA：本地内存快，远程慢，数据要本地化
  • 缓存一致性：MESI协议是基础，伪共享是常见坑，volatile和内存屏障不能少

下一章咱们聊「多核启动与同步机制」，到时候会讲Spinlock、Semaphore、Barrier这些实战工具。你想想看，没有这些同步机制，多核编程就是一场灾难。

个人经验：刚开始做多核项目时，我总想着「所有核心共享所有数据」，结果调试到崩溃。后来学乖了——能私有就私有，必须共享才共享，而且一定要加保护。这个原则，我建议你从一开始就记住。

← 上一章 📖 返回目录 下一章 →