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 filenames 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).

Note

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 filenames 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.

File Description

File	Description
`builtin_typeid_types.h`	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.
`model.bat`	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.
`model.c` `model.cpp`	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.
`model.h`	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 Model data structures, including `rtM` Model entry-point functions, except those for which you specify a filename in the Embedded Coder Dictionary. For more information, see Control File Packaging of Generated Entry-Point Functions and Simulink Functions (Embedded Coder). For more information, see model.h.
`model.mk`	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.
`model.rtw`	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.
`model_capi.h` `model_capi.c`	Contain data structures that describe the model signals, states, and parameters without using external mode. For more information, see Write External Code to Access Generated C API Code.
`model_data.c`	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
`model_dt.h`	Declares structures that contain data type and data type transition information for generated model data structures for supporting external mode.
`model_private.h`	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 Stateflow^® entry points Simulink Coder™ details (various macros, `enum`s, and so forth, that are private to the code) For more information, see Manage Build Process File Dependencies.
`model_reference_types.h`	Contains type definitions for timing bridges. A model build generates this file for a referenced model or a model containing model reference blocks.
`model_targ_data_map.m`	Contains MATLAB^® language commands that external mode uses to initialize the external mode connection.
`model_types.h`	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.
`multiword_types.h`	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.
`rtGetInf.c` `rtGetInf.h` `rtGetNaN.c` `rtGetNaN.h` `rt_nonfinite.c` `rt_nonfinite.h`	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.
`rtmodel.h`	Contains `#include` directives required by static main functionth 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`.
`rtwtypes.h`	Provides type definitions, `#define` statements, and enumerations. For ERT system target files, the code generator creates `rtwtypes.h` only if one of these conditions applies: Data type replacement (Embedded Coder) is set to `Use coder typedefs`. Data type replacement (Embedded Coder) is set to `Use C data types with fixed-width integers` and Coder typedefs compatibility (Embedded Coder) is selected. If you use legacy custom code or static source files (under `matlabroot`) that require Simulink Coder data type definitions, the settings force the generation of `rtwtypes.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.
`rtw_proj.tmw` `sl_proj.tmw`	Marker files. The build process generates these files to help the `make` utility determine when to recompile and link the generated code.
`rt_defines.h`	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.
`rt_sfcn_helper.h` `rt_sfcn_helper.c`	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.
`subsystem.c`	Contains C source code for each noninlined nonvirtual subsystem when the subsystem is configured to place code in a separate file.
`subsystem.h`	Contains exported symbols for noninlined nonvirtual subsystems.
`__cf_model.h`	Serves as a constant obfuscator and is generated when: `slbuild` uses the `ObfuscateCode` name-value argument. You build a model that references a protected model, previously created by using Protected Model Creator with Content type set to `Obfuscated source code` or `Binaries`. The obfuscated code uses random identifiers to disguise constants. The file contains `#define` statements that correspond to the random identifiers, which links the identifiers to the constant values.

builtin_typeid_types.h

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.

model.bat

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.

model.c

model.cpp

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.

model.h

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
Model data structures, including rtM
Model entry-point functions, except those for which you specify a filename in the Embedded Coder Dictionary. For more information, see Control File Packaging of Generated Entry-Point Functions and Simulink Functions (Embedded Coder).

For more information, see model.h.

model.mk

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.

model.rtw

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.

model_capi.h

model_capi.c

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

For more information, see Write External Code to Access Generated C API Code.

model_data.c

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

model_dt.h

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

model_private.h

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
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.

model_reference_types.h

Contains type definitions for timing bridges.

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

model_targ_data_map.m

Contains MATLAB^® language commands that external mode uses to initialize the external mode connection.

model_types.h

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.

multiword_types.h

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.

rtGetInf.c

rtGetInf.h

rtGetNaN.c

rtGetNaN.h

rt_nonfinite.c

rt_nonfinite.h

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.

rtmodel.h

Contains #include directives required by static main functionth 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.

rtwtypes.h

Provides type definitions, #define statements, and enumerations.

For ERT system target files, the code generator creates rtwtypes.h only if one of these conditions applies:

Data type replacement (Embedded Coder) is set to Use coder typedefs.
Data type replacement (Embedded Coder) is set to Use C data types with fixed-width integers and Coder typedefs compatibility (Embedded Coder) is selected. If you use legacy custom code or static source files (under matlabroot) that require Simulink Coder data type definitions, the settings force the generation of rtwtypes.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.

rtw_proj.tmw

sl_proj.tmw

Marker files.

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

rt_defines.h

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.

rt_sfcn_helper.h

rt_sfcn_helper.c

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.

subsystem.c

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

subsystem.h

Contains exported symbols for noninlined nonvirtual subsystems.

__cf_model.h

Serves as a constant obfuscator and is generated when:

slbuild uses the ObfuscateCode name-value argument.
You build a model that references a protected model, previously created by using Protected Model Creator with Content type set to Obfuscated source code or Binaries.

The obfuscated code uses random identifiers to disguise constants. The file contains #define statements that correspond to the random identifiers, which links the identifiers to the constant values.

`model`.bat

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, model.mk. 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 model.mk info')

`model`.h

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) 
((rtm)->Timing.sampleTimes[idx])
#endif

Model entry-point functions (ERT example)

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

To generate model entry-point functions in files other than model.h and model.c, use a function customization template in the Embedded Coder Dictionary. For more information, see Configure Default C Code Generation for Categories of Data Elements and Functions (Embedded Coder).

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 filename 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.

rtwtypes.h

When the configuration parameter Data type replacement is set to Use coder typedefs, the generated code includes rtwtypes.h. The header file rtwtypes.h defines data types, structures, and macros required by the generated code.

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 and int.

Note

Before the creation of the C99 language standard, there was no universally accepted data type for sized integers. The C99 standard provides the header files stdint.h and stdbool.h. The stdint.h file contains sized-integer implementations that were previously unavailable.

To accommodate this feature of the C language, the generated code uses sized integer types, such as int8_T and uint32_T, 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 dialog box.

The code generator produces an optimized version of rtwtypes.h for ERT-based system target files when the model does not contain noninlined S-functions. The optimized rtwtypes.h file contains definitions that are specific to the hardware configuration of the model.

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 and Control Placement of rtwtypes.h for Shared Utility Code (Embedded Coder).

Source files include the rtwtypes.h header file when the source files use code generator type names or other code generator definitions. For example, files that declare variables by using a code generator data type:

uint32_T myvar

In some cases, an S-function, custom source file is compiled, first, by the mex command, and second, by the code generation build. During mex compilation, rtwtypes.h is typically unavailable. To obtain the definitions normally supplied by rtwtypes.h, the custom source file can conditionally (through the MATLAB_MEX_FILE macro definition) include tmwtypes.h:

#ifdef  MATLAB_MEX_FILE
#include "tmwtypes.h"
#else
#include "rtwtypes.h"
#endif

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 the include statements into their generated file.

If the Data type replacement configuration parameter is set to Use C data types with fixed-width integers, the code generator does not create rtwtypes.h because the generated code does not require definitions from rtwtypes.h. If the generated code uses static files under matlabroot that require Simulink Coder data type definitions, the software generates a simplified version of rtwtypes.h. If you have custom code that includes rtwtypes.h, you can force the generation of the simplified version of rtwtypes.h by selecting the Coder typedefs compatibility check box.

Simplified rtwtypes.h