• 嵌入式
• RTOS
• 深度学习

CMSIS_5 仓库中的CMSIS/CoreValidation是一套用于验证 CMSIS-Core 各编译器、各内核实现正确性的自动化测试套件，它借助 Arm 固定虚拟平台（Fixed Virtual Platforms，VHT/FVP 系列仿真器）在纯软件环境中运行测试，覆盖 Cortex-M0 到 Cortex-M85、Cortex-A5/A7/A9 共 20 余种目标。读完本文，你可以完整掌握build.py的矩阵化构建/运行方法、测试矩阵三轴（编译器/设备/优化等级）的取值与底层映射、JUnit 报告的生成链路，以及如何定位到对应源码与配置文件继续深入。

一、CoreValidation 是什么

CMSIS/CoreValidation/README.md的开篇就定义了这套测试套件的定位：

This folder contains a test suite that validates CMSIS-Core implementations. It usesFixed Virtual Platformsto run tests to verify correct operation of the CMSIS-Core functionality on various Arm Cortex based processors.

也就是说，它不是针对某一款具体芯片的回归测试，而是面向CMSIS-Core 这一层内核抽象（NVIC、SysTick、MPU、Cache、核心指令、SIMD/DSP 指令、系统寄存器读写等）的兼容性验证：同一套测试用例，编译到不同编译器、不同内核、不同优化等级，再放到对应内核的 Arm 虚拟硬件模型上执行，只要全部用例通过，就说明 CMSIS-Core 在该组合下的行为是正确且稳定的。

测试用例入口在 cmsis_cv.h 中按目标架构声明：

• Cortex-M 侧：TC_CoreInstr_*（NOP、SEV、BKPT、ISB/DSB/DMB、REV/REV16/REVSH/ROR/RBIT/CLZ、SSAT/USAT/RRX、Load/Store Exclusive/Acquire 等 20 个指令类用例）、TC_CoreSimd_*（DSP/SIMD 指令）、TC_CoreFunc_*（IRQ 开关、中断优先级、PSP/MSP、PSPLIM/MSPLIM、PRIMASK/FAULTMASK/BASEPRI、FPUType/FPSCR 等）、TC_MPU_*（ARMv7/ARMv8-M 两套 MPU 实现）、TC_CML1Cache_*（L1 Cache 使能与按地址 Clean）；
• Cortex-A 侧：TC_CoreAFunc_*（CPSR、Mode、SP、FPEXC、ACTLR、CPACR、DFSR/IFSR、VBAR/MVBAR 等）、TC_GenTimer_*（通用定时器 CNTFRQ/CNTP_*）、TC_CAL1Cache_*（L1 Cache 使能、BTAC、全量 Invalidate/Clean/Clean+Invalidate）。

用例的启用/禁用以及输出格式由配置头 CV_Config.h 控制（Cortex-A 单独使用 ConfigA/CV_Config.h），例如PRINT_XML_REPORT决定测试结果是纯文本还是 XML（JUnit 报告依赖 XML 输出），BUFFER_ASSERTIONS为断言结果缓冲大小，每个用例都有形如TC_COREINSTR_NOP_EN的独立开关。此外，MPU 与 L1 Cache 用例会依据器件头文件中的能力宏自动裁剪：

#define RTE_CV_MPUFUNC (__MPU_PRESENT) #if defined __ICACHE_PRESENT || defined __DCACHE_PRESENT #define RTE_CV_L1CACHE (__ICACHE_PRESENT || __DCACHE_PRESENT) #endif

这解释了为什么不同内核组合的通过用例数不同（例如 CM3 组合在 README 示例中为 35/35）。

二、目录结构

README 给出的目录结构如下：

📂 CoreValidation ┣ 📂 Include Include files for test cases etc. ┣ 📂 Layer Layers for creating the projects. ┣ 📂 Project Solution and project files to build tests for various configurations. ┗ 📂 Source Test case source code.

结合仓库实际内容，四个目录的职责可以更具体地展开：

其中Layer/Target/<kernel>/目录名与build.py中-d参数的取值一一对应，例如CM3、CM7DP、CM33NS、CA5，每个目录还通过RTE/Device/ARMxx/携带该内核的启动文件与链接脚本（来自本仓库 Device/ARM 下的器件支持包）。

三、测试矩阵：编译器 × 设备 × 优化等级

README 的“Test matrix”一节是当前支持的全部构建配置，三轴定义如下。

3.1 编译器轴

1. Arm Compiler 6 (AC6)
2. GNU Compiler (GCC)
3. IAR Compiler (IAR)

build.py的CompilerAxis枚举中还额外保留了AC6LTM（Arm Compiler 6 长周期维护版，见仓库根目录的 cmsis_armclang_ltm.h 对应的编译器变体），但 README 矩阵中列出的默认支持面是上述三家。三家的产物后缀不同：build.py中image_ext将 AC6/AC6LTM 映射为.axf，GCC/IAR 映射为.elf。

3.2 设备轴

README 列出的设备及其变体：

这些变体在 build.py 中由DeviceAxis枚举精确表达：CM0、CM0plus、CM3、CM4/CM4FP、CM7/CM7SP/CM7DP、CM23/CM23S/CM23NS、CM33/CM33S/CM33NS、CM35P/CM35PS/CM35PNS、CM55S/CM55NS、CM85S/CM85NS、CA5/CA7/CA9（源码中另有一组被注释掉的CAXNEON变体，对应 NEON 场景暂未启用）。

设备轴在 Validation.csolution.yml 中映射为 target-types 与器件：例如

- type: CM33S device: ARMCM33_DSP_FP_TZ processor: trustzone: secure - type: CM33NS device: ARMCM33_DSP_FP_TZ processor: trustzone: non-secure

即 S/NS 变体共用同一_TZ器件、仅切换trustzone属性；CM4FP映射ARMCM4_FP，CM7SP/CM7DP映射ARMCM7_SP/ARMCM7_DP，与 README 的 FPU 变体描述完全一致。

TrustZone 场景还引入了 Bootloader 工程：build.py的has_bl()判定CM23NS、CM33NS、CM35PNS、CM55NS、CM85NS这 5 个 non-secure 目标需要先编译对应 secure 侧的 Bootloader（bl_device映射为CM23S/CM33S/CM35PS/CM55S/CM85S）；Validation.csolution.yml也据此把 Bootloader.cproject.yml 只挂到+CM23S、+CM33S、+CM35PS、+CM55S、+CM85S上下文上。运行时则通过两次-a参数把 secure 与 non-secure 两个镜像同时交给虚拟平台加载。

3.3 优化等级轴

README 定义的五个等级与三家编译器的实际命令行参数：

这些参数并不是build.py手工拼出来的，而是固化在Validation.csolution.yml的build-types中——每个“编译器_等级”组合是一个独立 build-type，如AC6_low、GCC_high、IAR_size，其misc段写入对应-O选项（IAR 变体额外附带--dlib_config DLib_Config_Full.h以启用完整 C 库）。build.py的OptimizationAxis枚举（low/mid/high/size/tiny）负责把用户输入的-o值转成Validation.<compiler>_<optimize>+<device>形式的 csolution 上下文名，例如-c GCC -o low -d CM3生成上下文Validation.GCC_low+CM3。

三轴组合后即得到完整测试矩阵：3 编译器 × 20 个设备变体 × 5 优化等级。README 示例中的35/35正是单组合（GCC+CM3+low）的用例通过数/总数。

四、环境准备

README 的“Prerequisites”一节列出了构建并运行 CoreValidation 所需的全部工具：

• CMSIS-Toolbox 1.3.0 或更高版本（提供csolution、cbuild等 CMSIS-Build 工具）
• CMake
• Ninja build
• Arm Compiler 6
• GNU Compiler
• IAR Compiler
• Python 3.8 或更高
• Arm Virtual Hardware Models（即VHT_MPS2_*、FVP_VE_*系列可执行文件）

并且要求所有可执行文件都在PATH中。然后安装build.py依赖的 Python 包：

CMSIS_5/CMSIS/CoreValidation/Project $ pip install -r requirements.txt

requirements.txt 只有两项依赖，分别支撑矩阵驱动与 XML 报告处理：

python-matrix-runner~=1.0 lxml~=4.8

python-matrix-runner提供matrix_axis/matrix_action/matrix_command等装饰器与JUnitReport等报告后端；lxml用于解析虚拟平台 stdout 中的 XML 报告（解析失败会触发build.py中 “No valid test report found in model output!” 报错）。

五、构建与运行

5.1 命令格式

对任意一个或多个“编译器 × 设备 × 优化等级”组合，统一使用如下命令行（README 原文）：

CMSIS_5/CMSIS/CoreValidation/Project $ ./build.py -c <compiler> -d <device> -o <optimize> [build] [run]

• -c <compiler>：编译器（AC6 / GCC / IAR）；
• -d <device>：设备变体（CM3、CM4FP、CM33NS……）；
• -o <optimize>：优化等级（low / mid / high / size / tiny）；
• build/run：动作参数，可只构建不运行，也可构建后运行。

矩阵框架支持轴值重复与通配，例如仓库 CI 配置 avh.yml 中就用一次命令批量覆盖多组合：

python build.py --verbose -c AC6 -c GCC -d "CM[047]*" -d "CM[23]3*" build run

5.2 README 完整示例

以 GCC + Cortex-M3 + low 优化为例，README 给出的完整执行过程：

CMSIS_5/CMSIS/CoreValidation/Project $ ./build.py -c GCC -d CM3 -o low build run [GCC][Cortex-M3]low csolution convert -s Validation.csolution.yml -c Validation.GCC_low+CM3 [GCC][Cortex-M3]low csolution succeeded with exit code 0 [GCC][Cortex-M3]low cbuild Validation.GCC_low+CM3/Validation.GCC_low+CM3.cprj [GCC][Cortex-M3]low cbuild succeeded with exit code 0 [GCC][Cortex-M3]low VHT_MPS2_Cortex-M3 -q --simlimit 100 -f ../Layer/Target/CM3/model_config.txt -a Validation.GCC_low+CM3/Validation.GCC_low+CM3_outdir/Validation.GCC_low+CM3.elf [GCC][Cortex-M3]low VHT_MPS2_Cortex-M3 succeeded with exit code 0 Matrix Summary ============== compiler device optimize build clean extract run ---------- --------- ---------- ------- ------- --------- ----- GCC Cortex-M3 low success (skip) (skip) 35/35

5.3 命令背后发生了什么

对照 build.py 的实现，一次build run实际串起四步：

1. csolution convert：csolution convert -s Validation.csolution.yml -c <project>把 csolution/cproject/clayer 组合展开为.cprj工程描述；TrustZone NS 目标会先对 Bootloader 上下文执行同样的转换；
2. cbuild：调用 Ninja 后端编译链接出.elf（GCC/IAR）或.axf（AC6）。特例是 GCC 编译 Cortex-A 时，会先用arm-none-eabi-gcc -xc -E预处理.ld.in生成链接脚本（build.py中preprocess动作）；
3. 归档：构建成功后把整个Validation.<context>/目录打包为Core_Validation-<Compiler>-<optimize>-<Device>-<时间戳>.zip，便于 CI 拉取产物；
4. model_exec：运行虚拟平台。MODEL_EXECUTABLE字典把设备轴映射到具体模拟器——Cortex-M 全部使用 VHT MPS2 系列（如VHT_MPS2_Cortex-M3、VHT_MPS2_Cortex-M33），Cortex-A 使用FVP_VE_Cortex-A5x1/A7x1/A9x1；统一附加-q --simlimit 100 -f <model_config.txt> -a <镜像>参数。

build.py中还定义了clean（对应cbuild -c）与extract（解压最新构建归档）动作，Matrix Summary表中每行的 build/clean/extract/run 状态即对应这四个动作。

5.4 虚拟平台参数：model_config.txt

每个目标目录下的model_config.txt是传给虚拟平台的-f参数文件，决定了仿真环境的硬件形态。以 CM55S/model_config.txt 为例，其中启用了 MVE 浮点扩展（cpu0.MVE=2）、TrustZone（cpu0.SECEXT=1）、8 个 Secure/Non-Secure MPU region（cpu0.MPU_S/cpu0.MPU_NS=0x8）、SAU region（cpu0.SAU=0x8）与 CPIF 协处理器接口，并统一关闭图形界面（fvp_mps2.mps2_visualisation.disable-visualisation=1）。而较简单的 CM3/model_config.txt 只配置了 semihosting（armcortexm3ct.semihosting-enable=1，SVC 号0xAB）——这正是测试程序能通过exit(0)经半主机服务正常退出的关键。

六、测试程序结构与结果报告

6.1 程序入口

Cortex-M 测试应用入口在 Validation_Cortex-M/main.c：

int main (void) { // System Initialization SystemCoreClockUpdate(); ... cmsis_cv(); #ifdef __MICROLIB for(;;) {} #else exit(0); #endif }

即：更新系统时钟 → 执行cmsis_cv()跑完所有被CV_Config.h启用的用例 → 通过半主机exit(0)退出（Microlib 下则死循环等待）。该文件还处理了两个架构特有点：当编译目标启用 CMSE 隔离（__ARM_FEATURE_CMSE == 3U）时，提供validationDummy这个cmse_nonsecure_entry假入口；Cortex-A 侧则实现了IRQ_Handler/PAbt_Handler/DAbt_Handler等异常骨架，任何未定义指令、Prefetch/Data Abort 都会走cmsis_cv_abort()报失败。

6.2 报告生成链路

README 指出：完整的测试报告会写入Core_Validation-<Compiler>-<optimize>-<Device>-<时间戳>.junit文件（README 示例中即Core_Validation-GCC-low-CM3-<timestamp>.junit）。从源码看其生成路径是：

1. 测试程序按PRINT_XML_REPORT=1通过半主机输出 XML 报告（CV_Framework.c/CV_Report.c生成，含//report/test/test_cases/tc结构与pass/fail/exec汇总）；
2. build.py的model_exec命令挂载了报告管线：ConsoleReport→CropReport（裁剪 XML 头尾）→TransformReport('validation.xsl')→JUnitReport；
3. validation.xsl 把每条tc映射为 JUnittestcase：PASSED通过、NOT EXECUTED标记为<skipped/>、其余状态进入<failure>并附module:line调试信息。

因此 Matrix Summary 的35/35表示该组合下 35 条用例全部执行并通过；若某目标缺少某类硬件（如无 MPU 的 CM0），相应用例会因TC_*_EN宏关闭而“NOT EXECUTED”，在 JUnit 中体现为 skipped 而非 failure。

七、适用前提与限制

• 所有可执行文件（csolution、cbuild、armclang/armcc、arm-none-eabi-gcc、IAR 工具链、VHT_MPS2_*/FVP_VE_*模型）必须在PATH上；虚拟硬件模型为 Arm 官方固定虚拟平台，需自行获取；
• CMSIS-Toolbox 要求 1.3.0 及以上，csolution 文件头部声明的 projmgr schema 为 1.3.0；avh.yml中 CI 实际拉取的是 1.5.0 发行版；
• 设备轴覆盖的是 README 矩阵所列组合，NEON 相关的 Cortex-A 变体在build.py中仍被注释未启用；
• 测试对象是本仓库自身的 CMSIS-Pack（Validation.csolution.yml通过packs: ARM::CMSIS, path: ../../../直接引用仓库本地 Pack），验证结论只对应当前树中的实现；
• 该目录代码遵循 Apache License 2.0（见 LICENSE.txt 与 README 的 License 一节）。

八、小结

CoreValidation用“一层声明式矩阵（csolution 的 build-type/target-type/clayer）+ 一个 Python 矩阵驱动（build.py）+ 一组虚拟平台参数（model_config.txt）”的组合，把 CMSIS-Core 的兼容性验证变成了可脚本化、可批量、可出 JUnit 报告的标准流程。掌握-c/-d/-o + build/run这条命令后，再沿Validation.csolution.yml（组合定义）→build.py（动作与模拟器调用）→Layer/Target/<kernel>/model_config.txt（仿真环境）→CV_Config.h/cmsis_cv.h（用例集）这条线索阅读源码，即可完整复现并扩展官方自身的 CI 验证流程。

• 嵌入式
• RTOS
• 深度学习