How to control intermediate variables when Simulink generates C code, and how to control the index values and function names for 2D lookup tables.

Hello, I encountered some problems when using Simulink to generate C code. My model is shown in Figure 1, and the model optimization configuration is shown in Figure 2. I disabled signal storage reuse but disabled local output reuse; all other settings are default.

1、If I enable reusing local outputs, it will use a local variable multiple times, which makes the code less readable. Even if I disable reusing local module outputs, some local variables are still reused. I want to improve readability but don't want each module to output individually. How can this be resolved?

2、How should I control the generation of intermediate variables? Do I need to name all module names and signal names? Is it possible to know in advance where intermediate variable names will be generated?

3、In Figure 3, the two-dimensional lookup table I used has the same dimensions, and when generating code it will generate a shared index value called 'pooled.' How should this variable be controlled?

4、Currently, the lookup functions I generate for the code are placed in model.c. Can the functions generated by the lookup module be placed in a specified file?

5、Is it possible to generate a structure to control the breakpoints and table data of the lookup module? I can do this using the Struct storage class in Simulink, but the lookup data ends up appearing in model.c, which makes my model.c look messy.

6、3. In Figure 4, there is matrix multiplication in the model. I have named the intermediate signal lines and the modules before and after, so why does it still generate a tmp variable? Is this variable used for the loop operation in matrix addition?

There are corresponding file attachments at the end.

Answer 1

[Ayush]

Hi,

I understand your concerns about controlling variable names, storage, and code structure in Simulink C code generation, are closely related to how storage classes are used for signals and parameters.

You should refer to the following document to understand about storage classes for parameters:

https://www.mathworks.com/help/releases/R2024b/rtw/ug/storage-classes-for-parameters-and-signals-used-in-model-blocks.html

I have noted few points from this document which are relevant to your questions:

1. Variable Reuse and Readability:

Applying a storage class (other than Auto) to signals or parameters makes them appear as global variables in the generated code and prevents them from being optimized away or reused. This can help improve code readability and control variable reuse, but may increase memory usage.

2. Control Over Intermediate Variables and Naming:

You can use the Code Mappings editor or API to assign storage classes and influence how and where variables appear in the code. Naming signals and parameters in your model, and assigning appropriate storage classes, helps ensure they are visible and accessible as you intend. However, some intermediate (tmp) variables may still be generated for certain operations due to code optimization.

3. Lookup Table Data Sharing:

When lookup tables share the same breakpoint data, Simulink may generate a shared variable (like 'pooled'). This is a result of optimization for memory efficiency. To avoid sharing, assign unique breakpoint data to each table.

4. Lookup Function Placement:

While storage class and code mapping control where data appears, function placement (such as lookup functions) is generally managed by subsystem function packaging or custom code settings. For more control, consider using custom code integration features.

5. Structs for Lookup Data and Code Organization:

Using the Struct storage class can group lookup data, and setting storage classes like "ExportedGlobal" can help move data out of "model.c". Data dictionaries and the Code Mappings editor provide further control over code organization.

6. Matrix Multiplication and Temporary Variables:

Even with named signals, Simulink may generate temporary variables (e.g., tmp) for intermediate results, especially in matrix operations, for performance reasons. Storage classes and naming can influence variable visibility, but some optimization is automatic.

Hope it helps!