芯片与架构

前言：为什么 MCU 也需要可信启动链 过去做单片机项目，很多团队把安全问题理解成“通信加个 TLS”“升级包做个 CRC”或者“调试口量产时关掉”。这些措施当然有价值，但如果设备会联网、会远程升级、会保存业务密钥，真正的风险往往出现在更早的启动阶段：攻击者能不能替换 Bootloader？能不能刷入旧版本固件重新打开已经修复的漏洞？能不能通过普通应用区读出密钥？能不能在升级断电后把设备卡成砖？ ARM Cortex-M23、Cortex-M33、Cortex-M35P、Cortex-M55 等内核引入的 TrustZone-M，正是为这些问题准备的一套硬件隔离基础设施。它不像服务器上的虚拟化那样厚重，也不是简单的软件权限判断，而是把整个地址空间、外设访问、中断入口和函数调用边界都划分成 Secure 与 Non-secure 两个世界。安全世界负责根信任、密钥、签名校验、回滚计数和少量可信服务；普通世界继续运行原有业务逻辑，例如传感器采集、协议栈、UI、云端连接和控制算法。 这篇文章不追求把 ARM 架构手册逐页复述，而是从一个真实产品视角出发，设计一条可落地的 TrustZone-M 安全启动与 OTA 链路。目标设备可以是带 Cortex-M33 的无线 MCU，也可以是安全要求较高的工业控制板。我们会讨论分区怎么切、密钥放在哪里、启动时校验什么、升级包如何设计、回滚防护如何做，以及调试和量产阶段最容易踩的坑。 一、TrustZone-M 的基本模型 TrustZone-M 的核心是“安全属性”。CPU 取指、读写内存、访问外设、响应中断时，硬件都会判断当前访问属于 Secure 还是 Non-secure。这个属性不是单靠软件变量维护，而是由 SAU（Security Attribution Unit）、IDAU（Implementation Defined Attribution Unit）以及厂商外设安全控制器共同决定。简单说，SAU 更像内核侧的安全地址表，IDAU 则是芯片厂商预先定义的安全属性，例如某些系统寄存器或 OTP 区域天然只能由 Secure 访问。 典型工程会把 Flash 分成 Secure Bootloader、Secure Service、Non-secure App、OTA Slot、Scratch 或 Trailer 几类区域。Secure Bootloader 最先运行，负责配置时钟、最小外设、安全属性和镜像验证；Secure Service 提供少量可被普通应用调用的安全接口，例如读取设备证书摘要、发起签名验签、获取随机数、更新回滚计数；Non-secure App 是业务主程序，绝大部分代码都放在这里；OTA Slot 保存待升级镜像；Scratch 或 Trailer 用来记录升级状态、断电恢复信息和镜像确认标志。 ...

前言：高性能 MCU 最隐蔽的坑，不是算力不够，而是数据“不一致” 很多人第一次从 Cortex-M3 / Cortex-M4 迁移到 Cortex-M7，感受非常直接：主频更高了，FPU 更强了，片上 SRAM 更大了，外设带宽也上来了。以 STM32H7、NXP i.MX RT、部分国产高性能 MCU 为例，系统里开始出现 I-Cache、D-Cache、AXI SRAM、多级总线矩阵、MDMA、ETH、SDMMC、DCMI、LTDC 这类过去在小 MCU 上不太需要认真处理的模块。代码还是 C，外设还是 DMA，调试器还是能单步，但一旦项目进入图像采集、以太网、文件系统、音频流或者屏幕刷新，问题会变得很诡异： DMA 明明已经写完了缓冲区，CPU 读到的还是旧数据； CPU 明明把发送包填好了，以太网 DMA 发出去的却是上一帧； 关掉 D-Cache 后系统稳定了，但吞吐掉了一大截； 加了一句 SCB_CleanDCache_by_Addr() 后偶尔好、偶尔坏； 同样的代码 Debug 版本正常，Release 版本或者换了优化等级就出错； 缓冲区长度不是 32 字节倍数时，旁边的变量被“莫名其妙”污染。 这些现象的根源通常不是外设驱动写错，也不是编译器“玄学”，而是 CPU、Cache、MPU、DMA 对同一段内存的理解不一致。Cortex-M7 的 D-Cache 提升了 CPU 访问速度，但 DMA 控制器通常不会经过 D-Cache，它直接从 SRAM 或外部 RAM 读写。于是同一个地址，在 CPU 看来可能是 Cache Line 里的新数据，在 DMA 看来却是内存里的旧数据；反过来，DMA 已经把新数据写入内存，CPU 仍然命中旧的 Cache Line。 ...

前言：为什么同一个模型在不同 NPU 上差距很大？ 做嵌入式 AI 部署时，很多人第一次拿到 NPU 板卡都会有一个误解：只要芯片宣传页写着 1TOPS、6TOPS 或 10TOPS，模型就应该按照这个数字线性变快。实际项目里经常不是这样。同样一个 YOLO、MobileNet 或语音关键词模型，在 A 芯片上跑得很顺，在 B 芯片上却卡在某几个算子；同样是 INT8 量化，有的模型精度几乎不掉，有的模型会出现明显误检；同样是官方转换工具，有的网络一键通过，有的网络需要反复改 ONNX 图、替换算子、拆分子图。 这些问题并不神秘，本质上是 NPU 的计算阵列、片上 SRAM、DMA、数据布局、编译器和运行时之间存在非常强的耦合。CPU 代码慢了，我们通常先看热点函数；GPU 程序慢了，会看 kernel occupancy、显存访问和线程块；NPU 部署慢了，也要有类似的分析框架：先判断瓶颈是算力、带宽、算子支持、量化误差，还是 CPU/NPU 之间的调度开销。 本文从工程视角拆解嵌入式 NPU 的典型架构，并围绕一个真实部署流程展开：模型导出、图优化、量化校准、算子映射、内存规划、运行时流水线和性能排查。文章不绑定某一家芯片，但会覆盖 RK、Amlogic、Kendryte、寒武纪边缘模块以及很多 MCU 级 NPU 都会遇到的共性问题。读完后，你应该能判断一个模型为什么没有跑满 NPU，也能知道该从哪里下手优化。 一、先把 TOPS 的含义说清楚 TOPS 是每秒万亿次操作数，通常用于描述 INT8 乘加能力。例如一个 2TOPS 的 NPU，理论上每秒可以完成 2 万亿次 8 bit 整数运算。问题在于，这个数字往往是理想条件下的峰值：输入输出都在合适的数据布局中，算子可以完全映射到矩阵乘阵列，片上缓存命中率足够高，DMA 搬运没有拖后腿，调度器没有频繁切换任务。 在实际模型里，真正能高效利用 NPU 的通常是卷积、深度卷积、全连接、矩阵乘、部分池化和激活函数。很多看起来不起眼的操作，例如 Reshape、Transpose、Slice、Gather、Resize、NonMaxSuppression，如果不能被 NPU 原生支持，就可能回退到 CPU。一次 CPU 回退不仅带来计算时间，还可能带来缓存同步、数据格式转换和内存拷贝。模型中只要有几个这样的“断点”，端到端延迟就会明显变差。 评估 NPU 时，比 TOPS 更有价值的是下面几个指标： ...

前言 做嵌入式 Linux 或边缘 AI 项目时，很多性能问题最后都会绕回一个朴素但容易被低估的事实：算力不等于吞吐，CPU、NPU、GPU 跑得再快，只要数据喂不上去，整机性能就会被内存系统卡住。 我第一次真正意识到 DDR 带宽的重要性，是在一块多核 ARM SoC 上做 4 路摄像头视频分析。算法同事看 NPU 利用率只有 40% 左右，以为模型还可以继续加大；系统同事看 CPU 使用率也不高，以为瓶颈不在软件。直到我们把 ISP、RGA、NPU、VPU 同时压起来，再去读 DDR 控制器计数器，才发现内存读写已经接近平台可持续带宽的上限。那一刻，所谓“还有很多算力没用上”，其实只是“大家都在等内存”。 这篇文章想把这个问题讲透一点：DDR 带宽不是一个孤立参数，它贯穿了 CPU Cache、AXI/NoC 互联、DMA burst、内存控制器调度、DRAM Bank 冲突、刷新开销以及 Linux 调度策略。很多项目里大家会直接跑一个 memcpy 或 stream，看到数字不错就认为内存没问题；但真实业务往往不是连续大块搬运，而是多个主设备同时访问、读写混合、缓存命中率波动、实时任务和后台任务互相抢总线。 本文会从 SoC 视角出发，拆解一条内存访问路径，并给出一套可以落地的排查和优化方法。示例代码以 Linux 用户态为主，兼顾裸机/RTOS 下的思路。目标不是把每个 DDR 时序参数都背下来，而是建立一个工程上有用的判断框架：什么时候该看 Cache Miss，什么时候该看 AXI outstanding，什么时候该怀疑 DDR controller 的 page policy，什么时候该从数据布局和 DMA burst 入手。 一、先把“带宽”这件事说清楚 DDR 厂商手册里常见的理论带宽计算很简单： 理论带宽 = 数据总线宽度 / 8 × 数据传输速率 例如 32-bit LPDDR4X，数据速率 4266 MT/s，理论峰值约为： ...

前言 如果你是一名嵌入式开发者或者系统程序员，可能会有这样的困惑：「我都用上 C/C++ 甚至 Rust 了，为什么还要学汇编语言？」 这个问题我被问过很多次。2018 年我在做一个手机相机 HAL 层的性能优化项目时，算法团队用 NEON intrinsics 写的图像处理函数在骁龙 845 上跑 12ms，离 8ms 的目标还差很远。我花了三天时间，把核心循环改成纯 AArch64 汇编，最终跑到了 6.8ms——这就是汇编的力量：你完全掌控了 CPU 的每一个周期、每一个寄存器。 今天，AArch64 已经无处不在：从你的智能手机到树莓派 4/5，从 AWS Graviton 服务器到 NVIDIA Jetson 开发板，甚至苹果 M 系列芯片本质上也是 AArch64 兼容架构。理解 AArch64 架构，不仅能让你写出更快的代码，更能让你真正理解现代 CPU 是如何工作的。 这篇文章不会教你「Hello World」级别的汇编入门。我要做的是：从架构设计哲学讲起，深入寄存器模型、指令集、寻址模式、函数调用约定，最后用实战项目教你如何写出高性能的 AArch64 汇编代码。 一、ARMv8-A 架构：从 32 位到 64 位的革命 1.1 ARM 架构演进简史 在深入 AArch64 之前，我们先快速回顾一下 ARM 架构的演进路线： ARMv4/v5 (1990s): 经典 ARM，32 位 ARM 状态 + 16 位 Thumb 状态 ARMv6 (2001): 引入 SIMD 媒体处理扩展、未对齐内存访问 ARMv7-A (2005): Cortex-A 系列诞生，NEON SIMD、虚拟化扩展 ARMv8-A (2011): 革命性的 64 位架构，AArch64 执行状态 ARMv8.1-A ~ ARMv8.5-A: 持续增强，加入 SVE、指针认证、内存标记等 ARMv9-A (2021): SVE2、机密计算架构 (CCA)、更多安全增强 很多人误以为 ARMv8-A 「就是 64 位的 ARMv7」——这是完全错误的。ARMv8-A 不是在 ARMv7 基础上「加了几根地址线」，而是几乎重新设计了整个指令集架构。 ...

前言 在嵌入式系统飞速发展的今天，GPU 早已不再仅仅是"游戏显卡"的代名词。从智能手机的流畅 UI 渲染，到车载娱乐系统的 3D 导航，从边缘设备的 AI 推理加速，到 AR/VR 设备的实时渲染，GPU 已经成为现代嵌入式 SoC 中不可或缺的核心组件。而在这个领域，ARM Mali GPU 无疑是占据统治地位的存在——全球超过 70% 的 Android 设备都搭载了 Mali GPU，从入门级的 Mali-G52 到旗舰级的 Mali-G720，Mali 架构覆盖了从低端到高端的完整产品线。 然而，尽管 Mali GPU 如此普及，真正深入理解其架构原理的开发者却并不多。大多数嵌入式工程师习惯于 CPU 的线性编程模型，面对 GPU 的并行计算架构和独特的渲染流水线时，往往感到无从下手。更重要的是，Mali GPU 采用的基于分片（Tile-Based）的渲染架构，与桌面端 NVIDIA/AMD 的立即模式渲染有着本质区别，如果不理解这种差异，写出的着色器代码往往会出现严重的性能问题。 我曾见过太多这样的案例：一个在 PC 上运行流畅的 OpenGL ES 应用，移植到嵌入式平台后帧率暴跌；一份看似合理的着色器代码，却在 Mali GPU 上出现了难以解释的带宽瓶颈；一个经过精心优化的渲染流程，实际性能却只有理论值的三分之一。这些问题的根源，往往都在于对 Mali GPU 架构的理解不够深入。 本文将从硬件架构出发，系统地讲解 Mali GPU 的工作原理。我们会从最基础的 Tiler 分片渲染机制讲起，深入到着色器核心的执行模型，分析内存层次结构的设计考量，最后给出一套完整的性能优化方法论。无论你是正在开发嵌入式图形应用的工程师，还是对 GPU 架构感兴趣的技术爱好者，这篇文章都能为你揭开 Mali GPU 的神秘面纱。 一、为什么嵌入式 GPU 需要不同的架构设计？ 在深入 Mali GPU 的具体架构之前，我们首先要回答一个根本性的问题：为什么嵌入式 GPU 不能直接沿用桌面 GPU 的设计？答案可以用三个关键词来概括：功耗、带宽、面积。 ...

前言 2026 年，芯片架构领域正在经历一场前所未有的变革。 过去三十年，ARM 架构凭借其低功耗、高效率的设计哲学，几乎垄断了整个移动设备和嵌入式市场。而 x86 架构则凭借强大的生态和软件兼容性，牢牢占据着桌面和服务器市场的主导地位。对于普通开发者来说，芯片架构似乎是一个遥不可及的话题——那是 Intel、ARM、高通这些巨头的游戏。 但一切都在 2010 年发生了改变。 加州大学伯克利分校的 Krste Asanović 教授带领他的团队，启动了一个看似疯狂的项目：从零开始设计一个全新的指令集架构（ISA），并且将其完全开源、免费授权。这个项目就是 RISC-V，读作 “Risk-Five”。 十五年后的今天，RISC-V 已经从一个学术项目成长为撼动整个芯片产业的力量。从最低端的 IoT 微控制器，到高性能服务器 CPU；从消费电子的 AI 加速卡，到超级计算机的计算节点——RISC-V 的身影无处不在。NVIDIA 的下一代 GPU 将集成 RISC-V 核心，Intel 的代工业务正在为客户生产 RISC-V 芯片，甚至连 ARM 自己都开始布局 RISC-V 相关业务。 为什么一个开源的指令集能够引发如此巨大的产业震动？RISC-V 到底解决了什么问题？它的技术优势在哪里？普通开发者又如何参与到这场架构革命中来？ 本文将带你从零开始，深入解析 RISC-V 架构的设计哲学、指令集细节、汇编编程、特权机制，最终实现一个简单的操作系统内核。无论你是嵌入式工程师、系统程序员，还是对芯片架构感兴趣的普通开发者，读完这篇文章，你都将对 RISC-V 有一个全面而深刻的理解。 一、为什么 RISC-V 能够撼动 ARM 的地位？ 在深入技术细节之前，我们需要先理解一个问题：在 ARM 和 x86 已经如此成熟的今天，为什么整个产业还要费心费力地去拥抱一个全新的架构？ 答案藏在三个关键词里：成本、控制权、创新。 1.1 授权费用的天壤之别 让我们先算一笔账。如果你想设计一款基于 ARM 架构的芯片，你需要支付哪些费用？ 首先是 架构授权费（Architecture License），这是使用 ARM 指令集本身的入门费。根据公开资料，ARM v8/v9 的架构授权费大约在 1000 万到 5000 万美元之间。注意，这只是让你"有权"设计兼容 ARM 指令集的 CPU，你还没有拿到任何实际的 CPU 设计。 ...

前言 2020 年代，AI 算力的需求呈现出爆炸式增长。从大语言模型的推理，到计算机视觉的实时处理，再到科学计算的海量数据处理，计算领域对数据并行处理能力的需求从未如此迫切。传统的标量 CPU 虽然通用，但面对海量重复运算时显得力不从心；GPU 虽然并行能力强大，但功耗和延迟问题使其难以在嵌入式和端侧场景中广泛应用。 正是在这样的背景下，RISC-V 向量扩展（RISC-V Vector Extension，简称 RVV） 应运而生。作为 RISC-V 指令集架构的官方标准扩展，RVV 提供了一套灵活、可扩展的向量处理机制，能够以远低于 GPU 的功耗和延迟，实现高效的数据并行计算。从低功耗的 IoT 设备，到高性能的服务器 CPU，RVV 正在成为 RISC-V 生态中最具变革性的技术之一。 RVV 的设计哲学与传统的 SIMD 扩展（如 x86 的 SSE/AVX、ARM 的 NEON/SVE）有着本质的不同。它不是简单地固定宽度的向量寄存器堆，而是引入了运行时可配置向量长度、向量寄存器分组、掩码操作等一系列创新设计，使得同一份 RVV 代码能够在不同硬件实现上高效运行，真正实现了"一次编写，处处加速"。 本文将从底层原理出发，带你深入理解 RVV 1.0 规范的设计精髓，通过完整的代码示例，手把手教你掌握 RVV 编程和优化技巧。无论你是芯片架构师、系统工程师，还是想要在 RISC-V 平台上优化算法性能的开发者，这篇文章都会为你提供完整的知识体系和实战指南。 一、为什么我们需要向量扩展？ 在深入探讨 RVV 的具体细节之前，让我们先回答一个最基本的问题：为什么 CPU 需要向量扩展？ 1.1 数据级并行的本质 现代计算任务中，绝大多数密集运算都具有一个共同的特征：对大量数据执行相同的操作。例如： 图像卷积：对每个像素点执行相同的乘加运算 矩阵乘法：大量的元素级乘累加操作 神经网络推理：张量之间的批量运算 信号处理：FFT、滤波等时域频域变换 这种"单指令，多数据"的模式，正是向量计算能够发挥巨大优势的场景。如果用传统的标量指令来处理这些任务，每个数据元素都需要取指、译码、执行一次，这会造成巨大的指令开销和控制开销。而向量指令可以在一条指令中处理数十甚至上百个数据元素，将指令吞吐量提升一个数量级。 1.2 传统 SIMD 的局限性 在 RVV 出现之前，主流 CPU 架构都有自己的 SIMD 扩展： ...