The Advantages of Inlining S-Functions

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.

When To Avoid Inlining

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 mdlOutputs() function.
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.

Inlining Process

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 model’s .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 model.rtw file and compute the generated code for this instance of the block. This TLC code is contained in the block target file.

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 _in(), _out() functions, inlined assembly code, or a specific set of I/O library calls unique to the device and target environment.

Search Algorithm for Locating TLC Files

The Target Language Compiler uses the following search order to locate TLC files:

Current folder.
Locations specified by %addincludepath directives. The compiler evaluates multiple %addincludepath directives from the bottom up.
Locations specified by -I options. The compiler evaluates multiple -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 targets).
The current folder when the build process is initiated.
Note
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 model.rtw file entry.

Note

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.

Availability for Inlining and Noninlining

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
MATLAB language	No	Yes
Fortran MEX	No	Yes
C	Yes	Yes
C++	Yes	Yes