Manage Build Process Files

To apply generated code source and header files from the build process, it is helpful to understand the files that the build process generates and the conditions that control file generation. This information provides access to generated code resources, such as:

  • Public interface to the model entry points

  • Enumerated types corresponding to built-in data types

  • Data structures that describe the model signals, states, and parameters

The code generator creates model.* files during the code generation and build process. You can customize the file names for generated header, source, and data files. For more information, see Customize Generated File Names (Embedded Coder). The code generator creates additional folders and dependency files to support shared utilities and model references. For more information about the folders that the build process creates, see Manage Build Process Folders. For an example that shows how to use a project to manage build process folders, see Generate Code and Simulate Models in a Project.

Depending on model architectures and code generation options, the build process for a GRT-based system target file can produce files that the build process does not generate for an ERT-based system target file. Also, for ERT-based system target files, the build process packages generated files differently than for GRT-based system target files. See Manage File Packaging of Generated Code Modules (Embedded Coder).


By default, the build process deletes foreign (not generated) source files in the build folder. It is possible to preserve foreign source files in the build folder by following the guidelines in Preserve External Code Files in Build Folder.

The table describes the principal generated files. Within the generated file names shown in the table, the model represents the name of the model for which you are generating code. The subsystem represents the name of a subsystem within the model. When you select the Create code generation report parameter, the code generator produces a set of HTML files. There is one HTML file for each source file plus a model_contents.html index file in the html subfolder within your build folder. The source and header files in the table have dependency relationships. For descriptions of other file dependencies, see Manage Build Process File Dependencies and Add Build Process Dependencies.



Defines an enumerated type corresponding to built-in data types.

A model build generates this file when one or more of these conditions apply:

  • Your model contains a Stateflow chart that uses messages.

  • Your model configuration enables MAT-file logging.

  • Your model configuration enables C API options in Code Generation > Interface.


Lists additional sources to include in the compilation.


Contains Windows® batch file commands that set the compiler environment and invoke the make utility.

For more information about using this file, see model.bat.



Corresponds to the model file.

The Target Language Compiler generates this C or C++ source code file. The file contains:

  • Include files model.h and model_private.h

  • Data, except data placed in model_data.c

  • Model-specific scheduler code

  • Model-specific solver code

  • Model registration code

  • Algorithm code

  • Optional GRT wrapper functions

model.exe (Windows platform)

model (UNIX® and Macintosh platforms)

Executable program file.

A model build generates this file unless you explicitly specify that the code generator produce code only. The build generates the executable in the current folder (not the build folder) under control of the make utility of your development system.


Defines 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_rtM) via access macros.

Subsystem .c or .cpp files in the model include model.h. This file includes:

  • Exported Simulink® data symbols

  • Exported Stateflow® machine parented data

  • Model data structures, including rtM

  • Model entry-point functions

For more information, see model.h.

Generated makefile that controls compiling and linking the generated code into the final binary file by the make utility of your development system.

If you set the MAKEFLAGS environment variable, do not select options with this variable that conflict with the current make utility used by the build process.


Represents the compiled model.

By default, the build process deletes this ASCII file when the build process is complete. You can choose to retain the file for inspection.



(optional files) Contain data structures that describe the model signals, states, and parameters without using external mode.

For more information, see Exchange Data Between Generated and External Code Using C API.


Contains (if conditionally generated) declarations for the parameters data structure and the constant block I/O data structure, and zero representations for structure data types that the model uses.

A model build generates this file when the model uses these data structures. The extern declarations for structures appear in model.h. When present, this file contains:

  • Constant block I/O parameters

  • Include files model.h and model_private.h

  • Definitions for the zero representations for user-defined structure data types that the model uses

  • Constant parameters


(optional file) Declares structures that contain data type and data type transition information for generated model data structures for supporting external mode.


Contains local define constants and local data for the model and subsystems.

The generated source files from the model build include this file. When you interface external code with generated code from a model, include model_private.h. The file contains:

  • Imported Simulink data symbols

  • Imported Stateflow machine parented data

  • Stateflow entry points

  • Simulink Coder™ details (various macros, enums, and so forth, that are private to the code)

For more information, see Manage Build Process File Dependencies.


Contains type definitions for timing bridges.

A model build generates this file for a referenced model or a model containing model reference blocks.


(optional file) Contains MATLAB® language commands that external mode uses to initialize the external mode connection.


Provides forward declarations for the real-time model data structure and the parameters data structure.

The generated header files from the model build include this file. Function declarations of reusable functions can use these structures.


Contains type definitions for multiple-word wide data types and their word-size chunks. If your code uses multiword data types, include this header file.

A model build generates this file when one or more of these conditions apply:

  • Your model uses multiword data types.

  • Your model configuration enables MAT-file logging.

  • Your model configuration enables Code Generation > Interface > External mode.







Declares and initializes global nonfinite values for inf, minus inf, and nan. Provides nonfinite comparison functions.

A model build generates these files when one or more of these conditions apply:

  • The model contains S-functions.

  • The generated code from the model requires nonfinite numbers.

  • Your model configuration enables MAT-file logging.

  • Your model configuration selects grt.tlc as the System target file and enables the Classic call interface.


Contains #include directives required by static main program modules such as rt_main.c.

The build process does not create these modules at code generation time. The modules include rtmodel.h to access model-specific data structures and entry points. If you create your own main program module, make sure to include rtmodel.h.


Provides the essential type definitions, #define statements, and enumerations.

For GRT-based system target files, rtwtypes.h includes simstruc_types.h which, in turn, includes tmwtypes.h.

For ERT-based system target files that do not generate a GRT interface and do not have noninlined S-functions, rtwtypes.h does not include simstruc_types.h.

For more information, see rtwtypes.h and Manage Build Process File Dependencies.



Marker files.

The build process generates these files to help the make utility determine when to recompile and link the generated code.


Contains type definitions for special mathematical constants (such as π and e) and defines the UNUSED_PARAMETER macro.

A model build generates this file when the generated code requires a mathematical constant definition or when the function body does not access a required model function argument.



(optional files) Provide functions that the noninlined S-functions use in a model.

The noninlined S-functions use functions rt_CallSys, rt_enableSys, and rt_DisableSys to call downstream function-call subsystems.


(optional file) Contains C source code for each noninlined nonvirtual subsystem or copy the code when the subsystem is configured to place code in a separate file.


(optional file) Contains exported symbols for noninlined nonvirtual subsystems.


This file contains Windows batch file commands that set the compiler environment and invoke the make utility.

If you are using the toolchain approach for the build process, you also can use this batch file to extract information from the generated makefile, The information includes macro definitions and values that appear in the makefile, such as CFLAGS (C compiler flags) and CPP_FLAGS (C++ compiler flags). With the folder containing model.bat selected as the current working folder, in the Command Window, type:

>> system('model.bat info')

On UNIX and Macintosh platforms, the code generator does not create the model.bat file. To extract information for toolchain approach builds from the generated makefile on these systems, in the Command Window, type:

>> system('gmake -f info')


The header file model.h declares model data structures and a public interface to the model entry points and data structures. This header file also provides an interface to the real-time model data structure (model_M) by using access macros. If your code interfaces to model functions or model data structures, include model.h:

  • Exported global signals

    extern int32_T INPUT;    /* '<Root>/In' */
  • Global structure definitions

    /* Block parameters (auto storage) */
    extern Parameters_mymodel mymodel_P;
  • Real-time model (RTM) macro definitions

    #ifndef rtmGetSampleTime
    # define rtmGetSampleTime(rtm, idx) 
  • Model entry point functions (ERT example)

    extern void mymodel_initialize(void);
    extern void mymodel_step(void);
    extern void mymodel_terminate(void);

The main.c (or .cpp) file includes model.h. If the model build generates the main.c (or .cpp) file from a TLC script, the TLC source can include model.h.

#include "%<CompiledModel.Name>.h"

If main.c is a static source file, you can use the fixed header file name rtmodel.h. This file includes the model.h header file:

#include "model.h"     /* If main.c is generated */


#include "rtmodel.h"   /* If static main.c is used */

Other external source files can require to include model.h to interface to model data, for example exported global parameters or signals. The model.h file itself can have additional header dependencies due to requirements of generated code. See System Header Files and Code Generator Header Files.

To reduce dependencies and reduce the number of included header files, see Manage Build Process File Dependencies.


The header file rtwtypes.h defines data types, structures, and macros required by the generated code. You include rtwtypes.h for GRT and ERT system target files, instead of including tmwtypes.h or simstruc_types.h.

Often, the generated code requires that integer operations overflow or underflow at specific values. For example, when the code expects a 16-bit integer, the code does not accept an 8-bit or a 32-bit integer type. The C language does not set a standard for the number of bits in types such as char, int, and others. So, there is no universally accepted data type in C to use for sized-integers.

To accommodate this feature of the C language, the generated code uses sized integer types, such as int8_T, uint32_T, and others, which are not standard C types. In rtwtypes.h, the generated code maps these sized-integer types to the corresponding C keyword base type using information in the Hardware Implementation pane of the configuration parameters.

The code generator produces the optimized version of rtwtypes.h for ERT-based system target files when these conditions apply:

  • Configuration Parameters > Code Generation > Interface > Advanced parameters > Classic call interface is not selected.

  • The model does not contain noninlined S-functions.

Include rtwtypes.h. If you include it for GRT system target files, for example, it is easier to use your code with ERT-based system target files.

For GRT and ERT system target files, the location of rtwtypes.h depends on whether the build process uses the shared utilities location. If it uses a shared location, the code generator places rtwtypes.h in slprj/target/_sharedutils; otherwise, it places rtwtypes.h in the build folder (model_target_rtw). See Specify Generated Code Interfaces.

Source files include the rtwtypes.h header file when the source files use code generator type names or other code generator definitions. A typical example is for files that declare variables by using a code generator data type, for example, uint32_T myvar.

A source file that the code generator and an S-function use can use the preprocessor macro MATLAB_MEX_FILE. The macro definition comes from the mex function:

#include "tmwtypes.h"
#include "rtwtypes.h"

A source file for the code generator main.c (or .cpp) file includes rtwtypes.h without preprocessor checks.

#include "rtwtypes.h"

Custom source files that the Target Language Compiler generates can also emit these include statements into their generated file.

See Control Placement of rtwtypes.h for Shared Utility Code.

Related Topics