3. 代码生成配置对一致性的影响

在 Simulink 模型与生成代码的一致性验证中，模型本身只是等式的一边，另一边由 Embedded Coder 的配置参数决定。同一张模型，换一套配置，生成的 C 代码可能在函数签名、数据类型、存储位置、循环结构甚至数值结果上完全不同。因此，理解关键配置项如何影响代码形态，是判断“模型与代码是否一致”的前提。本节围绕系统目标文件、代码风格、优化选项、存储类和接口配置五类配置展开，说明它们各自改变什么、为什么会影响一致性，以及验证时应当关注哪些具体差异。

系统目标文件：决定代码的“骨架”

系统目标文件（System target file，STF）是代码生成的总开关，它决定了生成代码的整体框架、调度方式和运行时环境。常见选择包括 ert.tlc（Embedded Coder 通用嵌入式目标）、grt.tlc（通用实时目标）以及各类处理器专用目标（如 cortex_m.tlc）。选择 ert.tlc 时，生成的是以 model_step() 为核心的紧凑嵌入式代码，通常不包含操作系统调度；而 grt.tlc 会生成带 main()、rt_OneStep() 的完整可执行框架，包含定时器与中断管理。

这一差异直接影响一致性验证的比对范围。若模型验证时使用 grt.tlc，而实际交付代码使用 ert.tlc，则 main()、调度逻辑、rtw_ 系列运行时函数都不应作为一致性比对对象，否则会产生大量“合理差异”。正确做法是：先确认目标文件，再据此确定哪些函数属于模型算法本体、哪些属于目标框架。算法本体（如 model_step 内的计算）才是模型与代码一致性的核心比对区域。

代码风格与优化选项：改变“写法”而非“语义”

代码风格配置主要影响可读性，包括是否生成注释、是否使用 static 关键字、括号与缩进风格、标识符命名规则等。这些选项通常不改变数值语义，但会改变文本比对结果。例如开启“生成注释”后，代码中会插入模型路径、模块参数等注释块，若用文本 diff 工具逐行比对，注释差异会被误判为不一致。因此一致性验证应优先比对语义等价性，而非纯文本。

优化选项则可能真正改变代码结构，需要格外谨慎。典型选项包括：

• 内联参数（Inline parameters）：将模型参数直接以常量形式写入代码，而非保留为可调变量。开启后，原本通过标定变量访问的参数变成字面量，若验证脚本仍按变量名查找，会找不到对应符号。
• 表达式折叠（Expression folding）：将多个模块的计算合并为一条复合表达式，减少临时变量。这会让代码行数与模型模块数不再一一对应，但数值结果应保持一致。
• 循环展开与复用：对向量运算，可能生成 for 循环，也可能完全展开为逐元素赋值。两者语义相同，但结构差异明显。
• 删除冗余代码：消除未被使用的信号与分支，可能使某些中间变量消失。

验证时，若模型与代码在优化选项上不一致，应重点比对最终输出信号的计算结果，而不是中间变量数量或表达式形态。一个实用的判断依据是：在相同输入激励下，模型仿真输出与代码执行输出在数值容差内一致，即可认为算法语义一致，即使代码结构因优化而不同。

存储类：决定变量“住在哪里”

存储类（Storage Class）配置控制信号、参数和状态变量在生成代码中的声明方式与存储位置。常见存储类包括 Auto、ExportedGlobal、ImportedExtern、ImportedExternPointer、Model default 等。选择 Auto 时，变量通常被优化为局部变量或直接内联；选择 ExportedGlobal 时，会生成全局变量并在头文件中声明 extern。

存储类对一致性的影响体现在两个层面。第一，符号可见性：若模型中某信号被配置为 ExportedGlobal，代码中必须存在同名全局变量，验证脚本可据此定位；若配置为 Auto，该信号可能被优化掉，验证时不能强求其存在。第二，数据生命周期：全局变量在多次步进之间保持值，而局部变量每步重新计算。若模型依赖上一时刻的状态，存储类配置错误可能导致代码行为与模型不符。因此，验证前应核对关键信号与参数的存储类设置，确保模型与代码在变量作用域上对应。

接口配置：函数签名与数据交换

接口配置决定生成代码如何与外部交互，包括步进函数名称、参数传递方式、端口数据类型与维度。典型配置项有：

• 步进函数名：默认 model_step，可自定义。验证脚本需按实际名称调用。
• 参数传递：可选择通过全局变量、函数参数或指针传递。若模型验证时假设参数为全局可调，而代码生成配置为按值传递，则标定接口不一致。
• 根级 I/O 配置：输入输出端口可生成为全局变量、函数参数或结构体。这直接影响代码与外部系统的对接方式。
• 数据类型：定点、浮点、枚举等类型映射，必须与模型中的数据类型设置一致，否则数值精度和范围会偏离。

接口配置不一致往往导致“代码能编译但行为不对”。例如模型中使用 single 类型，而代码生成配置将 single 映射为 double，虽然数值计算仍可运行，但精度与溢出特性改变，一致性验证会失败。因此，接口配置应与模型数据类型、信号维度严格对齐。

配置差异如何转化为验证结论

把上述配置影响落到验证流程中，可以得到一个清晰的判断框架。首先，确认模型与代码生成所用的配置是否一致；若不一致，先区分差异属于“合理差异”还是“真实缺陷”。合理差异包括：目标文件不同导致的调度框架差异、优化选项不同导致的表达式形态差异、注释与命名风格差异。真实缺陷则包括：数据类型映射错误导致精度偏离、存储类配置错误导致变量作用域不符、接口配置错误导致函数签名或参数传递方式不匹配。

其次，针对算法本体进行数值比对。建议在模型仿真与代码执行中使用同一组输入激励，记录关键输出信号，按容差判断是否一致。对于浮点运算，容差可取相对误差 1e-6 量级；对于定点运算，应允许量化误差，容差按最低有效位（LSB）的若干倍设定。若数值一致，则即使代码结构因优化而不同，也可判定算法语义一致。

最后，建立配置基线。将系统目标文件、优化选项、存储类、接口配置和数据类型映射记录为一份配置清单，作为模型与代码一致性验证的基准。每次代码生成前核对清单，避免因配置漂移引入难以定位的差异。下表给出一个配置基线的示例字段，可作为实际项目的参考模板。

总结来看，Embedded Coder 的关键配置项从五个方向影响生成代码：系统目标文件决定框架，代码风格与优化选项改变写法，存储类决定变量位置，接口配置决定交互方式，数据类型映射决定数值语义。一致性验证不是逐行文本比对，而是在明确配置基线的前提下，对算法语义、接口符号和数值结果进行分层比对。掌握这些配置项的作用路径，才能在模型与代码之间建立可靠的对应关系。