How can I optimize RAM, ROM, and stack usage in generated code?
显示 更早的评论
When generating C code from a Simulink model, I notice that the resulting RAM, ROM, or stack usage is higher than expected.
Which configuration options and modeling choices influence memory consumption, and how can I control them to reduce the overall footprint of the generated code?
采纳的回答
MathWorks Support Team
about 10 hours 前
0 个投票
Optimizing memory consumption in generated code is not a single switch or setting. RAM, ROM, and stack usage are influenced by a combination of code generation settings, data scoping decisions, and model structure. As a result, memory optimization is typically an iterative and model specific activity rather than a one time configuration step.
At a high level, memory consumption can be controlled by influencing
- Where and how variables are allocated, for example local versus global storage
- How data is passed to generated functions, such as via function arguments or shared data
- Which parts of the model actually result in executable code
Controlling RAM and stack usage
RAM and stack usage are strongly affected by how the code generator allocates data for signals, states, parameters, and temporary variables.
You can influence this behavior by configuring whether variables are defined locally within functions or globally across the generated code. Local variables typically consume stack space, while global variables consume RAM. In addition, data passing mechanisms between subsystem functions can increase memory usage if large data structures are copied rather than shared.
Configuration parameters that control signal storage reuse, function interfaces, and data visibility can significantly reduce the amount of memory required to store intermediate results and states.
Controlling ROM usage
ROM usage is primarily driven by the amount of generated code. The code generator already applies several optimizations automatically, such as
- Combining control flow constructs where possible
- Eliminating dead code paths
- Removing code for blocks that do not affect computational results
Further ROM reductions can often be achieved by disabling or removing generated code that is not required for the target application. Examples include initialization code, reset and disable functions, and defensive runtime checks that may not be needed in a production environment.
Model dependency
The following tables illustrate a selection of configuration settings and modeling-related changes, along with their typical effects on RAM, ROM, and stack usage. The intention is not to prescribe a fixed setup, but to highlight the levers available and the impact they can have.
Some, but not all of the information has been taken from: mathworks.com/help/ecoder/memory-usage.html
The exact outcome depends strongly on the model structure, data types, execution rates, and target environment. As a result, these settings should be evaluated in the context of a specific model, using code generation reports and memory metrics to validate their effect.
Please note that the table is non-exhaustive.
Configuration setting | Effect | Recommended Values |
Signal storage reuse(Enable local block outputs, Reuse local block outputs, Reuse global block outputs, Optimize global data access) | Decrease RAM and ROM usage | Change Optimize global data access to „Minimize global data access“ |
Conserves RAM consumption and increases code execution speed | Set Pass reusable subsystem outputs as to Individual arguments | |
Improves control flow, reduces code size and RAM consumption, increases execution speed | Set off | |
Conserves RAM and ROM usage, improves code execution speed | Set on | |
RAM efficient code for models containing referenced models | Set on | |
Accelerates model initialization, reduces ROM consumption, increases execution speed of generated code | Set the Code interface packaging parameter to Reusable function and select the Use dynamic memory allocation for model initialization | |
Improves execution speed and reduces ROM consumption | Select the Remove Disable Function and Remove Reset Function parameters | |
Reduces ROM and RAM consumption, improves execution speed. | Set Default parameter behavior to Inlined See also: Preserve Block Parameter Tunability | |
Reduces the amount of memory that stores state configuration variables OR reduces the amount of memory that stores Boolean variables. | Try both settings | |
Reduces RAM consumption. Can increase code size and execution time | Set on | |
Reduces RAM consumption | Set to single | |
Might improve ROM efficiency | Try setting to Bitwise operator | |
Improves code efficiency | Set on | |
Modeling approach | Effect | Recommended value |
Reduce global RAM for a nonreusable subsystem | Generate a function interface that passes data through arguments instead of global variables | |
Reduces RAM and ROM consumption, imrpves execution speed | Explicitly set data types for all block parameters (gains, constants, ...) | |
Minimize global data access trades global RAM/ROM for stack usage; limited stack can force globals, while allowing more stack enables more local reuse and lower global memory | Try varying | |
Reduce stack size by reducing the number of parameters in the parameter list of a generated function | Graphical function in Stateflow chart: set Function Inline Option to Inline | |
Reduces ROM and RAM consumption | Specify reusable storage class for Simulink.Signals | |
Reduces ROM usage by avoiding duplicate-generated code for identical subsystem instances across models. Can also reduce RAM usage by preventing duplicated data structures, depending on the function interface and model structure. | Configure library subsystems for reuse and generate code to shared utilities | |
Reduces ROM | Configure subsystems as atomic and set Function packaging to Reusable function or Auto to enable function reuse |
更多回答（0 个）
about 24 hours 前
about 14 hours 前
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
Translated by 
