FPGA 专家 25：软核处理器——给 FPGA 装一颗可裁剪的 CPU
本文是
fpga/专家层第 28 篇。Zynq 硬核 PS/PL 见 专家 12，FPGA 上嵌入式软件概览见 进阶 29，AXI 数据通路见 进阶 16。
一、为什么需要软核
纯 RTL 擅长快、确定的数据通路；但配置管理、协议解析、人机接口、异常慢路径写成状态机很痛苦。放一个可编程 CPU：硬件做快路径，软件做慢路径，是 FPGA 里的经典分工。
| 软核 | 硬核（Zynq 等） | |
|---|---|---|
| 形态 | RTL 综合进 PL | 硅片固化 |
| 资源 | 占 LUT/FF/BRAM | 不占 PL |
| 性能 | ~100–300MHz，小存储 | 数百 MHz–GHz，带 MMU |
| 软件 | 裸机 / FreeRTOS | Linux 都行 |
| 数量/裁剪 | 任意多核、按需配置 | 固定 |
二、主流软核与配置项
- 厂商：MicroBlaze（AMD/Xilinx）、Nios II / Nios V（Intel，RISC-V 化）。
- 开源 RISC-V：PicoRV32（极小）、NEORV32（外设齐全）、VexRiscv（SpinalHDL 插件化，性能上限高）。
- 关键裁剪：流水线级数、TCM 紧耦合内存（确定低延迟）、I/D Cache、FPU、MPU/MMU、中断/调试模块。配置越大越吃资源；最小核几千 LUT 就能跑。
三、系统集成：内存映射 + AXI
┌────────── AXI4 指令/数据 ──────────┐
软核 CPU ──LMB──► 本地 BRAM（TCM/代码） │
│ ▼
└──AXI4(Lite)──► 交叉互联 ─► UART/SPI/I2C/GPIO/DDR 控制器
│
AXI-Stream/FSL ─► 用户协处理器
AXI4 master(+DMA) ─► 硬件加速器IP Integrator / Qsys 图形连线后，软件侧只看到一段段地址：写寄存器配硬件、读状态拿结果，裸机里就是指针读写或 BSP 驱动。
四、三档加速方式与取舍
- AXI-Lite 寄存器外设——配置/控制，几十周期访问可接受。
- 流式协处理 / 自定义指令——热点小算子，数据就近时一指令换数十周期；估算公式：净收益 = 软件周期 −（硬件执行 + 总线往返）。
- AXI 主设备 + DMA——大流量数据通路，CPU 只发命令不搬数据。
控制面与数据面分离是铁律；让数据流经 CPU 寄存器的"加速器"往往更慢。
五、软件与调试
- BSP/裸机：standalone + newlib、中断、驱动；上层可上 FreeRTOS。
- 调试：JTAG 接 MDM/jtag_debug 模块，GDB 单步、看变量、同时用 ILA 看硬件波形，软硬件协同定位。
- RISC-V 软核：标准 GCC 工具链 + OpenOCD，跨厂商可移植。
六、软核微架构深水区：流水线、冒险与那些“面积换不回的周期”
把一颗软核真正用起来，绕不开对其内部微架构的理解。以一条经典五级流水线（取指、译码、执行、访存、写回）为参照，软核与桌面 CPU 的差距不在“有没有流水线”，而在“为了省 LUT 牺牲了哪些高级机制”。多数轻量软核（PicoRV32、最小配置的 MicroBlaze）顺序发射、顺序提交，没有分支预测器或只有静态预测（比如总假设向后跳转成立），没有乱序执行，乘法可能是多周期迭代单元，除法更是十几个周期的状态机。这意味着同样一段 C 代码，在软核上的实际 IPC（每周期指令数）常常只有 0.3~0.6，而不是理想的 1，分支密集或除法密集的代码还会更低。数据冒险靠插入气泡或简单的旁路（forwarding）解决，工具链会在你用 mul、div、访问外设这些“多周期操作”时自动插入等待，但这种等待对程序员不可见，于是性能预估最容易在这里翻车。
分支与跳转是第一个要建立直觉的地方。没有预测器时，一次错误预测（或无条件跳转）要清空流水线，付出等于流水线深度的周期惩罚。五级核就是约 5 个周期。因此在软核上，紧凑的循环（短到能被循环缓冲缓存住）远比“到处是函数指针和虚函数”的写法高效；switch-case 若分支稀疏，编译成跳转表会引入一次内存读取，分支密集时改成判断链或查表要实测对比。这不是要程序员手写汇编，而是要理解：软核的性能优化单位是“减少不可预测的控制流”和“减少多周期指令”，而不是主频。
第二个深水区是存储层次与总线仲裁的相互作用。软核的取指和访存若共用一条总线（冯·诺依曼结构的小核），取指和 load/store 会互相阻塞，一条从慢速外设读数据的指令会让整条流水线停摆等总线；带独立 I/D 总线（哈佛结构）的核可以让取指与数据访问并行，但一旦两者最终都汇聚到同一个 AXI 互联、争抢同一块 BRAM/DDR，仲裁策略又会引入不确定的等待。TCM（紧耦合内存）之所以关键，正是因为它挂在核的本地总线上（如 MicroBlaze 的 LMB），单周期或确定两周期可达、不经仲裁——中断服务程序、实时任务、关键数据结构放 TCM，性能和确定性同时得到保证；而放在 DDR 里的代码，实际执行时间会被 Cache 命中/缺失和总线拥塞显著拉长且难以预测。
第三个要破除的迷思是“加了 Cache 就一定快”。软核的 Cache 通常很小（几 KB 到几十 KB）、相联度低，且在没有 MMU 的裸机环境里，Cache 与 DMA、与外设内存之间的一致性要软件自己维护：DMA 要从 DDR 读一块数据给硬件前，软件得先 clean（把脏的 Cache 行写回）；DMA 写完内存、软件要读结果前，得先 invalidate（作废旧 Cache 行）。忘记这一步，会出现“单步调试正常、连续运行出错”“复位后第一次对、第二次错”这类极难排查的一致性 bug。很多团队为此干脆把 DMA 缓冲区和外设地址段配置成 non-cacheable，用可预测性换掉一部分平均性能，这在控制面为主的软核系统里通常是正确取舍。
理解这些之后，对软核的性能预期会变得现实：它不是“慢一点的 ARM”，而是一台结构极简、延迟确定、但每个高级特性都要你显式付出面积或软件代价的机器。好的软核设计不是把核配到最大，而是反过来——从软件的实时性需求出发，决定哪些代码必须进 TCM、哪些缓冲必须 non-cacheable、哪些热点值得做成自定义指令，让核的配置恰好覆盖需求而不过度。
七、从需求到配置：软核系统的选型决策方法论
选软核、定配置，最常见的失败是“先把核例化出来，再想软件干什么”，结果要么资源严重浪费，要么跑到一半发现 TCM 不够、中断延迟超标、没有 FPU 导致浮点仿真拖垮性能。正确顺序是先写清软件画像，再反推硬件配置。软件画像至少回答六件事：代码与只读数据的体积（决定 BRAM/Flash/DDR 映射）、动态内存需求（决定堆放在 TCM 还是 DDR、要不要 MMU）、是否有浮点密集计算（决定要不要 FPU，还是干脆定点化）、有多少中断源和最坏情况中断延迟要求（决定中断控制器深度、是否要延迟入口加锁的快速中断）、是否要跑网络协议栈或文件系统（决定要不要硬核/Linux）、以及软件团队熟悉哪套工具链（决定厂商核还是 RISC-V）。
决策树的第一道分叉是“控制面还是数据面”。如果 FPGA 里这颗处理器只负责上电时序、寄存器配置、命令解析、状态上报、慢路径异常处理——典型代码量几十到几百 KB、实时要求在微秒级、没有大流量数据穿过 CPU——软核是最优解，且应该配成够用的最小形态：浅流水线、小容量或无 Cache、适量 TCM、按需加 FPU。反过来，只要出现“要跑 Linux/标准 TCP/IP 协议栈/大型中间件/大量第三方 C++ 代码/需要高单线程吞吐/需要进程隔离和虚拟内存”中的任意两条，就应该直接转向 Zynq 之类的硬核 SoC，而不是试图给软核挂 MMU 和大内存硬撑——软核跑 Linux 的工程代价（启动慢、上下文切换贵、内存带宽紧张、驱动适配）通常远超省下的一颗芯片钱。
第二道分叉是厂商核还是开源 RISC-V 核。决策变量包括：是否需要跨厂商/国产化/多供货源（RISC-V 占优）、团队是否有能力维护一套非厂商集成的工具链和调试链（没有则厂商核占优）、是否要深度定制流水线或加自定义扩展（RISC-V + SpinalHDL/Chisel 占优）、项目对“可审计 RTL、没有黑盒”的合规要求（RISC-V 占优）、以及交付时间压力（厂商核在自家 IDE 里图形化搭建、BSP 一键生成，占优）。一个务实的中间策略是：早期用厂商核快速把系统跑通、验证软硬件分工，同时把与 CPU 紧耦合的用户 IP 全部做成标准 AXI 接口（而非厂商私有的 FSL），这样将来迁移到 RISC-V 时数据通路 IP 可以原样复用，只换核与工具链，锁定风险被限制在最小范围。
第三道分叉是单核还是多核、同构还是异构。多个独立的慢路径任务（比如一个核管前面板通信、一个核管整机状态机）用两颗小软核，通过共享内存 + 信箱/自旋锁通信，往往比在一颗核上塞 RTOS 更简单、隔离性更好；但多核共享 AXI/DDR 会引入竞争和内存一致性问题，没有缓存一致性总线的软核多核，一致性要完全靠软件（共享数据 non-cacheable 或显式维护）。异构则是“一颗主控软核 + 若干专用硬件加速器”的形态，这才是 FPGA 里最常见也最高效的结构——主控核做决策与调度，把数据面卸载给可并行的 RTL。把“多个通用核堆算力”当加速手段，在 FPGA 里几乎总是错的，通用核的能效比远不如专用数据通路。
最后要有资源预算的闭环。软核不是“免费的灵活性”：一颗带 Cache、FPU、几级流水线的核轻松吃掉几千到上万 LUT 和若干 BRAM/DSP，在资源利用率已经很高的设计里，加软核可能把时序和布线拥塞推过临界点。正确做法是在项目早期就把“CPU 子系统”当作一个有明确资源配额的模块纳入预算，核配置、Cache/TCM 容量、AXI 互联和 DMA 引擎都计入其中，并在每次综合后核对这部分的实际占用，而不是临到收尾才发现“放个 CPU 把片子塞爆了”。
八、内存映射、启动流程与链接脚本：软件如何看见硬件
软核系统里，软件与硬件的契约浓缩在两样东西里：地址映射表和链接脚本（linker script）。硬件工程师在 IP Integrator/Qsys 里每接一个外设、每挂一块存储，都占用一段地址空间；软件工程师看到的不是“UART”“DMA”“BRAM”，而是 0x40600000、0x40400000 这样的地址。BSP（板级支持包）会根据硬件导出的描述文件（Xilinx 的 .xsa、Intel 的 .sopcinfo）自动生成头文件，把地址定义成宏、把寄存器包成结构体或驱动函数。理解这层映射的意义在于：当驱动行为异常时，你要能在“硬件连线地址”和“软件访问地址”之间双向核对——最常见的低级 bug 就是硬件改了地址忘了重新导出 BSP，软件还在敲旧地址。
启动流程是另一个必须吃透的黑盒。上电后，FPGA 先加载比特流配置好 PL（包括软核本身和所有外设），软核才从复位向量开始取指。复位入口通常是一段引导程序（bootloader/bootrom），它可能直接跳到 TCM 里的裸机程序，也可能先从 Flash/SD 卡把代码拷到 DDR、初始化 Cache 和 BSS 段，再跳转到 main。理解这个顺序能解释很多现象：为什么“烧了新软件没反应”可能其实是 FPGA 没重配、为什么代码必须显式初始化 .data/.bss（裸机环境没有操作系统帮你做）、为什么全局指针寄存器（gp）和栈指针（sp）的初始化在进入 C 世界之前必须完成。带 MMU 跑 Linux 的系统则多了 SPL/u-boot/内核/设备树的完整链条，设备树里对软核外设的描述必须与实际地址一致，这正是硬核/大软核系统里最容易出错的接缝。
链接脚本决定了每一段代码和数据落在哪块物理存储上，这是软核实时性的关键抓手。一个典型脚本会把中断向量和启动代码放在起始地址、把实时代码和热数据放进 TCM（用 section 属性把特定函数标注进 TCM 段）、把堆栈放在确定的高速存储、把大块 DMA 缓冲放在 DDR 且标记为 non-cacheable 区域、把常量和代码放进 Flash 或 DDR。很多“偶发实时超时”的根因，最终都能追溯到链接脚本：中断服务程序被链接到了 DDR，第一次执行时 Cache 缺失加上总线繁忙，最坏响应时间暴涨。掌握链接脚本，等于掌握了“用物理位置换确定性”的开关。
地址映射还要考虑对齐、位宽和字节使能。AXI 外设寄存器通常要求 32 位对齐访问，软件用字节指针敲一个非对齐地址可能触发总线错误或得到意外结果；窄位宽外设接到宽总线上时，地址的低位用于选通字节，寄存器在字内的偏移必须和硬件一致；写一个只读状态位、读一个只写控制位的行为都由硬件定义（往往读回 0 或写入被忽略），驱动不能假设读回等于写入。这些细节在“读写一个寄存器”的抽象下完全看不见，却占据了 bring-up 阶段相当比例的调试时间，因此硬件工程师在交付 IP 时附带一份寄存器映射手册（地址、复位值、读写属性、位域含义、副作用、中断清除方式）是专业与业余团队的分水岭。
最后，内存保护常被低估。没有 MPU/MMU 的裸核上，任何一行野指针代码都能敲到任何外设（包括时钟控制器和 DDR 控制器），一个软件 bug 可能让整片 FPGA 挂死且无法自愈。带 MPU 的软核可以把代码段设为只读可执行、把外设区间限权访问、把任务栈设为不可越界，虽不如 MMU 强大，但足以把多数软件 bug 拦成可定位的异常，而不是神秘的整机死机。对功能安全相关的设计，这种隔离甚至是标准明确要求的，应在选型阶段就把 MPU 列为必需配置。
九、中断、异常与实时性：软核为什么能做控制却不能赌实时
软核做控制面的核心价值之一是对硬件事件的快速响应，但“响应快”是设计出来的，不是软核白送的。中断延迟由几段构成：从外设发出中断请求，到中断控制器仲裁、到当前指令执行完（或被支持嵌套的机制打断）、到硬件自动压栈/跳转、再到中断服务程序（ISR）里执行真正的处理。轻量软核的裸奔中断延迟可以做到十几个周期且上界确定，这是它相对跑 Linux 的硬核（调度延迟可能微秒到毫秒级且上界不确定）的独特优势；但一旦启用了复杂 RTOS、中断嵌套、或在 ISR 里调用了会关中断的驱动，这个延迟就会膨胀且变得难以分析。
实时性的第一原则是“让最坏情况，而不是平均情况，可分析”。具体做法包括：中断控制器对每个中断源提供独立使能和优先级（关键中断设为高优先级、可抢占低优先级 ISR）；ISR 保持极短——只做“确认中断、把数据从硬件取走、唤醒处理任务”，重逻辑放到下半部/任务里；ISR 代码和它访问的数据放进 TCM，避免 Cache 缺失和总线等待；ISR 里绝不做可能阻塞的总线访问（比如敲一个正被别的主设备占用、或本身会挂起的外设）。此外要计算中断风暴：多个高频中断同时到来时，软件处理速度若跟不上中断到达速度，系统会在中断上下文里永久满转、低优先级任务饿死。设计时要给每个中断源评估最高频率 × 单 ISR 周期数的总开销，给 CPU 留出足够裕量（经验上中断处理占用不超过六七成）。
软核与硬件加速器之间的同步机制有一个从简到繁的谱系，选型直接影响实时性和复杂度。最轻的是轮询：软件定期读状态寄存器，简单、确定，但浪费 CPU 且响应受轮询周期限制，适合慢速、不紧急的状态。其次是中断/门铃：硬件完成一批处理后敲一个中断，软件被唤醒处理，适合事件稀疏的场景。再重是描述符环 + 中断聚合：软件预先排好一串工作描述符，硬件自动逐个消费，每完成 N 个或超时才中断一次，把每包一次的高频率中断压下去，这是高速 DMA/网络通路的标准做法。最重的是让加速器自己做 AXI 主设备批量搬数，CPU 完全退出数据面，只在整批完成时收到一次完成通知。从轮询到批量卸载，本质是在“响应即时性”和“每事件 CPU 开销”之间做交换。
异常与错误处理是软核系统的“安全带”，却最常被省略。除了外部中断，软核通常还能在以下情况陷入异常：未对齐访问、访问未实现地址（总线错误/解码错误）、非法/未实现指令、除零、MPU 违例、（带 MMU 时）缺页。很多裸机程序根本没挂异常向量或挂了个死循环，于是一旦出现野指针，系统表现为“静默卡死”，没有任何线索。专业的做法是给每类异常挂处理程序，记录异常类型、出错 PC、关键寄存器和总线错误地址，再决定重启子系统还是整机复位；配合一个看门狗，软件死锁时由硬件超时复位恢复。这套机制平时没用，却是现场设备“挂了之后还能远程定位和自愈”的唯一指望。
最后要清醒认识软核实时性的边界：它适合微秒级、上界可分析、中断数量有限的控制；不适合需要硬实时保证到亚微秒、或要在复杂软件栈里保证确定性的场合。真正对时序有硬性要求的行为（高速协议状态机、精确时序的脉冲产生、纳秒级响应）应当下沉到 RTL 用硬件实现，软核只负责配置参数和处理非实时异常。把本该硬件保证的实时性赌在“希望 CPU 响应够快”上，是软核系统最危险、也最常见的架构错误。
十、自定义指令与协处理器的接口工程：什么时候值得动刀
给软核加一条自定义指令或挂一个协处理器，是 FPGA 软核独有的“特权”——你可以改变 CPU 本身的指令集。但这项能力的门槛常被低估：它同时改动硬件（核的数据通路或接口）、工具链（编译器要认识新指令，通常靠内联函数/intrinsic 或汇编）、汇编器、调试器和可移植性，是一笔跨三层的工程投资。因此正确的问题不是“能不能加”，而是“profiler 是否证明了这里值得加、加了之后净收益有多大、这笔工程量能否摊薄”。
先看收益模型。一条自定义指令的净收益 ≈ 软件实现该操作所需周期（包含取指、译码、循环、访存等开销）减去（自定义指令的执行周期 + 把操作数送进协处理器并取回结果的往返延迟）。当操作数已经在 CPU 寄存器里、结果一两个周期就能算出来时（位域操作、小查表、单轮加密、CRC 一步、定点饱和运算），自定义指令几乎是纯赚，一条指令替掉十几条；但如果数据不在寄存器、要先经总线写到协处理器、再轮询等待、再读回，几十周期的往返延迟和总线占用会轻易吃掉加速比，这种粒度更适合做成独立的内存映射外设甚至 DMA 加速器。一个实用判据：操作本身的计算时间必须显著大于数据往返时间，否则不值得做成指令。
接口层面有三种主流接法。其一是核厂商提供的专用快速接口（如 MicroBlaze 的 FSL/FSRL、Nios 的自定义指令接口），数据直接在寄存器与自定义执行单元之间传递，延迟最低，但绑定厂商、不可移植。其二是标准的 AXI4-Stream 点对点通道，协处理器挂在核旁作为流接口外设，可移植性好，适合连续流入流出的数据（逐块加解密、流式校验）。其三是 RISC-V 生态下的 custom instruction / 处理器扩展（自定义 opcode 或标准向量/位操作扩展），配合可配置核（VexRiscv 用插件、NEORV32 用 custom instruction 单元）实现，跨厂商可移植、生态最现代，但要求团队理解 RISC-V 的编码空间和工具链配置。选型上，单一平台、极致省延迟用专用接口；跨平台、面向未来用 RISC-V 扩展或标准 AXI-Stream。
工程上更常见、也更稳妥的其实不是自定义指令，而是三档卸载的中间和最重档：内存映射的寄存器协处理器（AXI4-Lite 从设备，软件写命令、读状态，适合配置和触发）以及 AXI4 主设备加速器（自己经 DMA 从内存取数、算完写回，软件只发一个门铃）。这里的设计纪律是控制面与数据面分离、数据绝不经过 CPU 寄存器搬运。一个典型反模式是：加速器算得很快，但软件为了喂它，逐字节把数据从内存读进 CPU、再写进加速器寄存器，数据两次穿过总线和 CPU，整体比纯软件还慢。正确做法是让大数据块留在内存/DDR，加速器用 DMA 直接寻址，CPU 与加速器之间只交换描述符指针、长度和完成状态这类几十字节的控制信息。
验证与可维护性是动刀前必须想清楚的后半本账。自定义执行单元是 RTL，要单独写测试台验证；它与核的接口协议（有效/就绪握手、时序、异常行为）要核厂商文档逐项对齐；软件侧要封装成薄薄一层 HAL，把内联指令藏在一个 C 函数背后，上层代码只调用这个函数——这样将来若换核、换工具链，只需重写这一层而不是满工程找汇编。还要评估软件可移植性损失：同一份算法若还要跑在硬核、PC 或别的处理器上做参考，就应保留一份纯 C 的功能实现，自定义指令版只作为加速后端，并保证两者 bit-true 一致（见 专家 33 的验证链）。把“可移植 C 参考 + 硬件加速 + 一致性测试”作为标准模式，自定义指令才不会变成绑死一颗芯片、无人敢动的技术债。
最后给一个决策顺序：先用纯 C 跑通并用 profiler 找到真正的热点（往往不是你以为的那处）；再问热点能否通过算法优化、定点化、查表、编译器选项解决（零硬件成本）；若仍不够，评估数据粒度——小且数据就近→自定义指令/流式协处理器，大且批量→DMA 主设备加速器；最后才投入 RTL、工具链、验证三件套。按这个顺序，自定义指令会成为压垮性能瓶颈的精准一刀，而不是早期炫技却拖累全生命周期的负担。
十一、典型坑对照与上板自检清单
软核项目的问题往往不在“核能不能跑”，而在系统接缝、实时性和一致性这些第二眼才看得见的地方。下面把高频坑按现象归类，作为 bring-up 和评审时的对照清单。
地址与 BSP 类：现象是软件敲寄存器完全无效、或敲 A 外设却影响了 B。多半是硬件改了地址映射后没有重新导出 .xsa/.sopcinfo、BSP 里的地址宏过期；也可能是位域偏移、字节使能、非对齐访问的问题。做法是固化“硬件地址一改，必须重新生成 BSP 并全量重编软件”的流程，bring-up 第一周先逐个做“写-读回”寄存器探活，确认每个外设在软件地址空间里真的存在且可读写。
Cache 一致性类：现象极具迷惑性——单步正常、连跑出错，第一次对、第二次错，加个延时反而好了。根因几乎总是 DMA/硬件与 CPU 共享内存时没做 clean/invalidate，或共享区可缓存。做法是 DMA 缓冲、共享描述符、外设内存段一律配成 non-cacheable，或在每次 DMA 前后显式维护一致性；把这条写进 DMA 驱动而非依赖每个程序员记得。
启动与存储类：现象是“程序在调试器里能跑，拔掉 JTAG 上电就不跑”“改了代码没变化”。根因多为启动模式/复位向量配置错、代码没正确烧进启动介质、FPGA 没重配导致软核和外设还是旧版本、或 .data/.bss/段初始化与链接脚本不匹配。做法是明确“先配 FPGA、后跑软件”的上电顺序，检查 boot 介质和复位地址，确认链接脚本里各段位置与实际存储一致，并在启动早期就让一个 LED/串口心跳可观测，区分“核没起来”还是“起来后卡在某处”。
中断与实时类：现象是偶发丢中断、高频事件下整机卡死、关键响应时快时慢。根因包括 ISR 里做了重活或阻塞访问、中断频率超过 CPU 处理能力、ISR/数据放在可缓存 DDR 导致最坏延迟不可控、低优先级中断被高优先级永久抢占。做法是 ISR 极短化、热代码进 TCM、给每中断源做频率×开销预算、中断适度聚合成批量通知、并用一个独立硬件定时器测量实际中断响应时间做在线监控。
野指针与健壮性类：现象是无规律死机、总线挂死、只能整板断电恢复。根因是没有 MPU、没有异常处理、没有看门狗，一个软件 bug 敲挂时钟/DDR/AXI 总线。做法是开启 MPU 做段保护、挂齐所有异常向量并记录 PC/总线错误地址、加独立看门狗实现挂死自愈、对所有外部输入做合法性检查。
资源与时序类：现象是加了软核后资源爆红、关键路径时序变差、综合时间暴涨。根因是把核配到最大、Cache/TCM/互联/DMA 全没做预算。做法是早期给 CPU 子系统划资源配额，按需最小配置，每次综合核对该子系统占用与时序，不要等收尾。
自检清单（上板前逐项过）：①每个内存映射外设写读回探活通过；②DMA 共享内存一致性策略已在驱动层固化；③链接脚本中实时代码/数据确在 TCM、堆栈位置确定；④所有中断源有独立使能、频率×开销预算达标、ISR 内无阻塞；⑤异常向量与看门狗就位、能触发一次假异常验证处理路径；⑥复位向量与启动介质正确、脱离调试器可独立冷启动；⑦CPU 子系统资源占用与时序在预算内；⑧软硬件版本通过寄存器互相可读（见 20 比特流烧录与四方版本一致 manifest/门禁 的版本治理思想），现场问题可追溯到具体 commit 与比特流。把这份清单作为每次软硬件联调的入场券，软核系统绝大多数“玄学问题”都能被挡在现场之前。
总结
软核是用 PL 资源换软件灵活性：小控制面选可裁剪软核（厂商核求省事、RISC-V 求自主），跑 Linux/重协议上硬核；集成按"寄存器配置→流式指令→DMA 主设备"三档选择，数据面绝不让 CPU 搬数。