Main Content

Manage File Packaging of Generated Code Modules

The code generator produces code modules. The file packaging configuration controls where the code generator places code into code modules and header files.

To locate and examine the generated code files, use the Code view or the HTML code generation report. The code generation report provides hyperlinks in the comments that you can click to view the generated code in the MATLAB® Help browser. For more information, see Traceability in Generated Code.

Generated Code Modules

The code generator creates a build folder in your working folder to store generated source code. The build folder contains object files, a makefile, and other files created during the code generation process. The default name of the build folder is model_ert_rtw.

Code Modules and Header Files Affected by File Packaging summarizes the structure of source code that the code generator produces.

You can customize the generated set of files in several ways:

  • File packaging formats: Manage the number of source files generated for your model. Select model configuration parameter File packaging format. For more information, see Customize Generated Code Modules.

  • Nonvirtual subsystem code generation: Instruct the code generator to produce separate functions within separate code files for nonvirtual subsystems. You can control the names of the functions and of the code files. For more information, see Generate Subsystem Code as Separate Function and Files.

  • Storage classes: Define and use storage classes that partition generated data structures into different files based on file names that you specify. For more information, see Organize Parameter Data into a Structure by Using Struct Storage Class.

  • Module packaging: Direct the generated code into a required set of .c or .cpp and .h files, and control the internal organization of the generated files. For details, see Code Interface Configuration.

Code Modules and Header Files Affected by File Packaging


model.c or .cpp

By default, contains entry points for code implementing the model algorithm (for example, model_step, model_initialize, and model_terminate). For information about how to change the file packaging of entry-point functions, see Control File Packaging of Generated Entry-Point Functions and Simulink Functions.


Contains local macros and local data that the model and subsystems require. This file is included in the model.c file as a #include statement. You do not need to include model_private.h when interfacing handwritten code to the generated code of a model.


Declares model data structures and a public interface to the model entry-points and data structures. Provides an interface to the real-time model data structure (model_M) with accessor macros.

The code generator:

  • Produces a separate header file for each Simulink Function block in a model.

  • Includes model.h in the subsystem .c or .cpp files of a model.

If you interface handwritten code to generated code for one or more models, include model.h for each of those models.

model_data.c or .cpp

Contains (if conditionally generated) the declarations for the parameters data structure, the constant block I/O data structure, and any zero representations for the model structure data types. If the model does not use these data structures and zero representations, model_data.c or .cpp is not generated. These structures and zero representations are declared extern in model.h.


Provides forward declarations for the real-time model data structure and the parameters data structure. Function declarations of reusable functions can require these declarations. Provides type definitions for user-defined types that the model uses.


Defines data types, structures, and macros required by generated code. For more information, see Control Placement of rtwtypes.h for Shared Utility Code.


Contains type definitions for wide data types and their chunks. File is generated when multiword data types are used or when you select one or more of these model configuration parameters:

  • MAT-file logging

  • External mode


Contains type definitions for timing bridges. File is generated for a referenced model or a model containing Model blocks.


Defines an enumerated type corresponding to built-in data types. File is generated when your model contains a Stateflow® chart that uses messages or when you select one or more of these configuration parameters:

  • MAT-file logging

  • C API model configuration parameter

zero_crossing_types.h, rt_zcfcn.h, and rt_zcfcn.c

Contains zero-crossing definitions for models with triggered subsystems where the trigger is rising, falling, or either. Files are generated if required by the model.

ert_main.c or .cpp

(optional file) If you select model configuration parameter Generate an example main program, this file is generated. For more information, see Generate an example main program.


(optional file) If you clear model configuration parameter Generate an example main program, this file is generated. For more information, see Generate an example main program.

Contains #include directives required by the rt_main.c or rt_cppclass_main.cpp static main program module. Includes rtmodel.h to access model-specific data structures and entry points, because the static main program module is not created at code generation time.

For more information, see Static Main Program Module.

model_capi.c or .cpp


(optional file) Provides data structures that enable a running program to access model signals, states, and parameters without external mode. To learn how to generate and use the model_capi.c or .cpp and .h files, see Exchange Data Between Generated and External Code Using C API.

User-Written Code Modules

Code that you write to interface with generated model code usually includes a customized main module. Base this module on a main program produced by the code generator. This customized main module can also include interrupt handlers, device driver blocks and other S-functions, and other supervisory or supporting code. Steps to set up the development environment to support a customized main module include:

  1. Establish a working folder for your own code modules.

  2. Put your working folder on the MATLAB path.

  3. At minimum, inform the build process about the location of your source and object files with model configuration parameter Additional build information.

  4. Your development process could require generating code for a particular microprocessor or development board and deploying the code on target hardware with a cross-development system. To accomplish these goals, make more extensive modifications to the ERT-based system target file.

For information on how to customize your ERT-based system target file for your production requirements, see Custom Software for Target Hardware.

Customize Generated Code Modules

Model configuration parameter File packaging format specifies how the code generator packages generated source code into files. You can set the parameter to Modular, Compact (with separate data file), and Compact. This table describes the generated files and the removed files for each file packaging format.

Generated Files According to File Packaging Format

File Packaging FormatGenerated FilesRemoved Files
Modular (default)


subsystem files (optional)

user-defined files that contain Simulink functions and entry-point functions (optional)




model_data.c (conditional)


Compact (with separate data file)



model_data.c (conditional)


model_types.h (conditional, see Removed Files According to File Packaging Format)






model_types.h (conditional, see Removed Files According to File Packaging Format)

This table describes content placement from the removed files.

Removed Files According to File Packaging Format

Removed FileGenerated Content In File
model_private.hmodel.c and model.h

You can specify a different file packaging format for each referenced model.

Model configuration parameter Shared code placement interacts with file packaging operations. If you set Shared code placement to Shared location, the code generator produces separate files for utility code in a shared location, regardless of the file packaging format. If you set Shared code placement to Auto, the code generator generates code for utilities according to the file packaging format selection.

  • Modular: Some shared utility files are in the build folder.

  • Compact (with separate data file): Utility code is generated in model.c.

  • Compact: Utility code is generated in model.c.

File packaging formats Compact and Compact (with separate data file) generate model_types.h for models containing:

  • A Variant Subsystem block. The model_types.h file includes preprocessor directives defining the variant objects associated with a variant block.

  • Storage classes generating a separate header file.

File packaging formats Compact and Compact (with separate data file) are not compatible with:

  • A model containing a subsystem, which is configured to generate separate source files

  • A model containing a noninlined S-function

  • A model for which Shared code placement is set to Auto, which uses data objects for which Data scope is set to Exported


The File packaging format parameter does not impact Stateflow charts in which you select the Treat exported functions as globally visible parameter. These exported functions are global and shared by other source files. Therefore, the functions must produce headers with function declarations, which other source files can include.

Related Topics