The goals of generated code usually include compactness and speed. On the other hand, S-functions are run-time-loadable extension modules for adding block-level functionality to Simulink®. As such, the S-function interface is optimized for flexibility in configuring and using blocks in a simulation environment with capability to allow run-time changes to a block’s operation via parameters. These changes typically take the form of algorithm selection and numerical constants for the block algorithms.
While switching algorithms is a desirable feature in the design phase of a system, when the time comes to generate code, this type of flexibility is often dropped in favor of optimal calculation speed and code size. The Target Language Compiler is designed to allow the generation of code that is compact and fast by selectively generating only the code you need for one instance of a block’s parameter set.
You might decide not to inline C MEX S-functions that have:
Few or no numerical parameters.
One algorithm that is already fixed in capability. For example, it has no optional modes or alternate algorithms.
Support for only one data type.
A significant or large code size in the
Multiple instances of S-Function block in your models.
Whenever you encounter this situation, the effort of inlining the block might not improve execution speed and could actually increase the size of the generated code. The tradeoff is in the size of the block’s body code generated for each instance versus the size of the child SimStruct created for each instance of a noninlined S-function in the generated code.
Alternatively, you can use a hybrid inlining method known as a C MEX wrapped S-function, where the block target file simply generates a call to a custom code function that the S-function itself also calls. This approach might be the optimal solution for code generation in the case of a large piece of existing code. See Write Wrapper S-Function and TLC Files for the procedure and an example of a wrapped S-function.
The strategy for improving code from blocks centers on determining what part of a block’s operations are active and used in the generated code and what parts can be predetermined or left out.
In practice, this means the TLC code in the block target file will select an algorithm that is a subset of the algorithms contained in the S-function itself and then selectively hard-code numerical parameters that are not to be changed at run time. This reduces code memory size and results in code that is often much faster than its S-function counterpart when mode selection is a significant part of S-function processing. Additionally, function-call overhead is eliminated for inlined S-functions, as the code is generated directly in the body of the code unless there is an explicit call to a library function in the generated code.
The algorithm selections and parameters for each block are output in the initial phase
of the code generation process from the registered S-function parameter set or the
mdlRTW() function (if present), which results in entries in the
.rtw file for that block at code generation time. A file written
in the target language for the block is then called to read the entries in the
file and compute the generated
code for this instance of the block. This TLC code is contained in the block target
One special case for inlined S-functions is for the case of I/O blocks and drivers such
as A/D converters or communications ports. For simulation, the I/O driver is typically coded
in the S-function as a pure source, a pass-through, or a pure sink. In the generated code,
however, an actual interface to the I/O device must be made, typically through direct coding
with the common
_out() functions, inlined
assembly code, or a specific set of I/O library calls unique to the device and target
The Target Language Compiler uses the following search order to locate TLC files:
Locations specified by
%addincludepath directives. The compiler
%addincludepath directives from the
Locations specified by
-I options. The compiler evaluates
-I options from right to left.
For inlined S-function TLC files, the build process supports the following locations:
The folder where the S-function executable (MEX or MATLAB®) file is located.
S-function folder subfolder
./tlc_c (for C or C++ language
The current folder when the build process is initiated.
Note: Placing the inlined S-function TLC file elsewhere is not supported, even if the location is in the TLC include path.
The first target file encountered with the required name that implements the specified
language is used in processing the S-function
The compiler does not search the MATLAB path, and will not find a file that is available only on that path. The compiler searches only the locations described above.
S-functions can be written in MATLAB language, Fortran, C, and C++. TLC inlining of S-functions is available as indicated in this table.
Inline TLC Support by S-Function Type
|S-Function Type||Noninlining Supported||Inlining Supported|