Generate Modular Function Code for Nonvirtual Subsystems

About Nonvirtual Subsystem Code Generation

By default, when producing code for a nonvirtual subsystem, the code generator places internal data associated with a nonvirtual subsystem in the same data structure as internal data for the parent model. This can make it difficult to trace and test code, particularly for nonreusable subsystems. Also, in large models containing nonvirtual subsystems, data structures can become large and potentially difficult to compile.

To generate modular function code for nonvirtual subsystems, including atomic subsystems and conditionally executed subsystems, use the subsystem block parameter Function with separate data. This block parameter instructs the code generator to produce a block I/O and DWork data structure for the nonvirtual subsystem function that is independent from the parent model data structures. As a result, generated code for the subsystem:

Is easier to trace.
Is easier to test.
Reduces the size of a model's global data structures.

To use the Function with separate data parameter,

Configure the model with an ERT-based system target file.
Configure the subsystem to be atomic or conditionally executed.
Set the subsystem block parameter Function packaging to Nonreusable function.

To configure your subsystem for generating modular function code, invoke the Subsystem Parameters dialog box and make a series of selections to display and enable the Function with separate data option. See Configure Subsystem for Generating Modular Function Code and Modular Function Code for Nonvirtual Subsystems for details. For limitations that apply, see Nonvirtual Subsystem Modular Function Code Limitations.

For more information about generating code for atomic subsystems, see Generate Subsystem Code as Separate Function and Files and Generate Code and Executables for Individual Subsystems.

Configure Subsystem for Generating Modular Function Code

Verify that the model containing the subsystem uses an ERT-based system target file.
Select the subsystem for which you want to generate modular function code and open the Subsystem Parameters dialog box. The dialog box for an atomic subsystem is shown below. (In the dialog box for a conditionally executed subsystem, the dialog box option Treat as atomic unit is greyed out, and you can skip Step 3.)
If the block parameter Treat as atomic unit is available for selection but not selected, the subsystem is neither atomic nor conditionally executed. Select the parameter Treat as atomic unit, which enables the Function packaging parameter on the Code Generation tab. Select the Code Generation tab.
For the Function packaging parameter, select Nonreusable function. After you make this selection, the Function with separate data parameter is displayed.
Before you generate code for the nonvirtual subsystem with the Function with separate dataparameter selected, consider generating function code with the parameter cleared and save the generated function .c and .h files in a separate directory for later comparison.
Select the Function with separate data parameter. Additional parameters appear.
To control the naming of the generated subsystem function and the subsystem files, modify subsystem parameters Function name options and File name options.
Save your subsystem parameter changes and exit the dialog box by clicking OK.
Generate code for the subsystem and examine the generated files, including the function .c and .h files named according to your subsystem parameter specifications.

For more information on generating code for nonvirtual subsystems, see Generate Subsystem Code as Separate Function and Files. For examples of generated subsystem function code, see Modular Function Code for Nonvirtual Subsystems.

Modular Function Code for Nonvirtual Subsystems

This example shows how to generate nonvirtual subsystem function code with the Function with separate data parameter cleared and selected and compares the results.

Open example model rtwdemo_atomic. Then, open the Embedded Coder app. Change the system target file to ert.tlc.
This model shows how to preserve the boundary of a virtual subsystem. When you select subsystem block parameter Treat as atomic unit, the code that the code generator produces for the subsystem executes as an atomic unit. When configured as atomic, you can specify how the code generator represents the subsystem by setting the Function Packaging parameter on the Code Generation tab. You can specify that the subsystem is translated to one of these types of implementation:
- Inline: Inlined subsystem code at call sites.
- Function: void/void function with I/O and internal data in the model global data structure.
- Reusable Function: Reentrant function with data passed in as function arguments.
- Auto: Code generator optimizes the implementation based on context.
Double-click the SS1 subsystem and examine the contents.
Then, close the subsystem window.
Right-click the SS1 subsystem, select Block Parameters (Subsystem) from the context menu, and examine the settings. Simulink^® and the code generator can avoid "artificial" algebraic loops when you make the subsystem atomic with subsystem parameter Minimize algebraic loop occurrences.
Create a variant of rtwdemo_atomic that shows function code without data separation.
1. In the Subsystem Parameters dialog box,
  - In the Main tab, select Treat as atomic unit.
  - In the Code Generation tab:
    
    Set Function packaging to Nonreusable function.
    Set Function name options to User specified.
    Set Function name to myfun.
    Set File name options to Use function name. This setting is optional but simplifies the later task of code comparison by causing the atomic subsystem function code to be generated into files myfun.c and myfun.h.
  Do not select the Function with separate data parameter.
2. Click Apply to apply the changes and click OK to exit the dialog box.
3. Save the model variant with a unique file name (for example, rtwdemo_atomic1) to a writable location.
Create a variant of rtwdemo_atomic that shows function code with data separation.
1. Open model rtwdemo_atomic.
2. Open the Embedded Coder app. Change the system target file to ert.tlc.
3. In the model canvas, right-click the SS1 subsystem and select Block Parameters (Subsystem). In the Subsystem Parameters dialog box,
  - In the Main tab, select Treat as atomic unit.
  - In the Code Generation tab:
    
    Set Function packaging to Nonreusable function.
    Set Function name options to User specified.
    Set Function name to myfun.
    Set File name options to Use function name.
    Select Function with separate data.
4. Click Apply to apply the change and click OK to exit the dialog box.
5. Save the model variant with a unique file name (for example, rtwdemo_atomic2) to a writable location.
Generate code for each model (for example, rtwdemo_atomic1 and rtwdemo_atomic2).
Compare the model.c/.h and myfun.c/.h files generated for the two models. For code comparison discussion, see H File Differences for Nonvirtual Subsystem Function Data Separation and C File Differences for Nonvirtual Subsystem Function Data Separation.
In this example, there are not significant differences in the generated variants of ert_main.c, model_private.h, model_types.h, or rtwtypes.h.

H File Differences for Nonvirtual Subsystem Function Data Separation

Selecting Function with separate data causes the code generator to place type definitions for subsystem data in the myfun.h file for rtwdemo_atomic2:

/* Block states (default storage) for system '<Root>/SS1' */
typedef struct {
  real_T Integrator_DSTATE;            /* '<S1>/Integrator' */
} DW_myfun_T;

For rtwdemo_atomic1, type definitions for subsystem data belong to the model and appear in rtwdemo_atomic1.h:

/* Block signals (default storage) */
typedef struct {
  real_T Sum;                          /* '<Root>/Sum' */
} B_rtwdemo_atomic_1_T;

/* Block states (default storage) for system '<Root>' */
typedef struct {
  real_T Integrator_DSTATE;            /* '<S1>/Integrator' */
} DW_rtwdemo_atomic_1_T;

Selecting Function with separate data generates the following external declarations in the myfun.h file for rtwdemo_atomic2:

/* Extern declarations of internal data for system '<Root>/SS1' */
extern DW_myfun_T myfun_DW;
extern void myfun_Update(void);
extern void myfun(void);

By contrast, the generated code for rtwdemo_atomic1 contains model-level external declarations for the subsystem BlockIO and D_Work data, in rtwdemo_atomic1.h:

/* Block signals (default storage) */
extern B_rtwdemo_atomic_1_T rtwdemo_atomic_1_B;

/* Block states (default storage) */
extern DW_rtwdemo_atomic_1_T rtwdemo_atomic_1_DW;

C File Differences for Nonvirtual Subsystem Function Data Separation

Selecting Function with separate data causes a separate subsystem initialize function, myfun_initialize, to be generated in the myfun.c file for rtwdemo_atomic2:

void myfun_initialize(void) {
  {
    ((real_T*)&rtwdemo_atomic2_myfunB.Integrator)[0] = 0.0;
  }
  rtwdemo_atomic2_myfunDW.Integrator_DSTATE = 0.0;
}

The subsystem initialize function in myfun.c is invoked by the model initialize function in rtwdemo_atomic2.c:

/* Model initialize function */

void rtwdemo_atomic2_initialize(void)
{
...

  /* Initialize subsystem data */
  myfun_initialize();
}

By contrast, for rtwdemo_atomic1, subsystem data is initialized by the model initialize function in rtwdemo_atomic1.c:

/* Model initialize function */

void rtwdemo_atomic1_initialize(void)
{
...
  /* block I/O */
  {
 ...
    ((real_T*)&rtwdemo_atomic1_B.Integrator)[0] = 0.0;
  }

  /* states (dwork) */

  rtwdemo_atomic1_DWork.Integrator_DSTATE = 0.0;
...
}

Selecting Function with separate data generates the following declarations in the myfun.c file for rtwdemo_atomic2:
```
/* Declare variables for internal data of system '<Root>/SS1' */
DW_myfun_T myfun_DW;
```
By contrast, the generated code for rtwdemo_atomic1 contains model-level declarations for the subsystems BlockIO and D_Work data, in rtwdemo_atomic1.c:
```
/* Block signals (default storage) */
B_rtwdemo_atomic_1_T rtwdemo_atomic_1_B;

/* Block states (default storage) */
DW_rtwdemo_atomic_1_T rtwdemo_atomic_1_DW;
```
Selecting Function with separate data generates identifier naming that reflects the subsystem orientation of data items. The references to subsystem data in subsystem functions, such as myfun and myfun_update, are in the model model_step function. For example, compare this code from myfun for rtwdemo_atomic2
```
/*  DiscreteIntegrator: '<S1>/Integrator' */
  rtwdemo_atomic_2_Y.Out1 = myfun_DW.Integrator_DSTATE;
```
to the corresponding code from myfun for rtwdemo_atomic1.
```
/* DiscreteIntegrator: '<S1>/Integrator' */
rtwdemo_atomic_1_Y.Out1 = rtwdemo_atomic_1_DW.Integrator_DSTATE;
```

Partition Functions in Generated Code

This example uses:

Open Live Script

This example shows how to associate subsystems in a model with function names and files.

Learn how to:

Specify function and file names in the generated code.
Identify the parts of the generated code that are required for integration.
Generate code for atomic subsystems.
Identify data that are required to execute a generated function.

For information about the example model and other examples in this series, see Prepare a Control Algorithm Model for C Code Generation.

Atomic and Virtual Subsystems

The example models in Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code use virtual subsystems. Virtual subsystems visually organize blocks but do not affect the model functionality. Atomic subsystems evaluate the blocks included in a model as a unit. With atomic subsystems, you can specify additional function partitioning information. In a model, atomic subsystems appear with a bold border.

View Changes in Model Architecture

Open the example model rtwdemo_PCG_Eval_P3.

Save a copy of the model to a writable folder.

This example shows how to replace the virtual subsystems with function-call subsystems. Function-call subsystems:

Are atomic subsystems
Enable you to control subsystem execution order
Execute when a function call signal triggers

By controlling the execution order of the subsystems, you can match the model with an existing system that has a specific execution order.

The figure identifies the function call subsystems (1) PI_ctrl_1, PI_ctrl_2, and Pos_Command_Arbitration.

This version of the model contains the new subsystem Execution_Order_Control (2), which contains a Stateflow® chart that models the calling functionality of a scheduler. The subsystem controls the execution order of the function call subsystems through function call signals (3). Later in this example, you examine how changing the execution order can change the simulation results.

This version of the model contains new Signal Conversion blocks (4) at the outputs of the PI controllers. With these additional blocks in place, the code generator can generate a single reentrant function for the PI controllers.

Control Function Location and File Placement in the Generated Code

In Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code, the code generator creates a single model_step function that contains the control algorithm code. However, many applications require a greater level of control over the file placement of functions. By modifying the parameters of atomic subsystems, you can specify multiple functions within a single model.

The figure shows the subsystem parameters for PI_ctrl_1.

Treat as atomic unit

Enables other submenus. For atomic subsystems, this parameter is automatically selected and disabled.

Sample time

Specifies a sample time for execution. Not available for function-call subsystems.

Function packaging options

Auto -- Determines how the subsystem appears in the generated code. This value is the default.
Inline -- Places the subsystem code inline with the rest of the model code.
Function -- Generates the code for the subsystem as a function.
Reusable function -- Generates a reusable (reentrant) function from the subsystem. The function passes all input and output data through formal parameters. The function does not directly access global variables.

Function name options

Selecting Function or Reusable function for Function packaging enables function name options.
Auto -- Determines the function.
Use subsystem name -- Bases the function on the subsystem name.
User specified -- Applies the specified file name.

File name options

Selecting Function or Reusable function for Function packaging enables file name options.
Auto -- Places the function definition in the module generated for the parent system, or, if the model root is the parent, in model.c.
Use subsystem name -- Generates a separate file. The name of the file is the name of the subsystem or library block.
Use function name -- Generates a separate file. The name of the file is the name that you specify with Function name options.
User specified -- Applies the specified, unique file name.

Function with separate data

Enabled when you set Function packaging to Function. When selected, the code generator separates the internal data of the subsystem (for example, signals) from the data of the parent model. The subsystem owns this separate data.

Generate Reentrant Code

Embedded Coder® supports reentrant code. Reentrant code is a reusable programming routine that multiple programs can use simultaneously. Reentrant code is used in operating systems and other system software that uses multithreading to handle concurrent events. Reentrant code does not maintain state data, so there are no persistent variables in the function. Calling programs maintain state variables and must pass the state data into the function. Multiple users or processes can share one copy of a reentrant function.

To generate reentrant code, you must first specify the subsystem as reusable by configuring the subsystem parameter Function packaging.

In some cases, the configuration of the model prevents reusable code. The table lists common issues.

Cause                                     Solution

Subsystem output feeds global signal      Add a Signal Conversion block between the 
data                                      subsystem and the global signal.

Generated function receives data          Select Configuration Parameters >
(formal parameters) through pointers      Model Referencing > Pass fixed-size scalar root
                                          inputs by value for code generation.

Subsystem uses global signal data         Use a port to pass the global data in and out 
in internal algorithm                     of the subsystem.

Use a Mask to Pass Parameter Values into Library Subsystem

To define algorithmic parameter data (such as a gain or coefficient) outside the scope of a reusable library block or subsystem, you can apply a mask to the block or subsystem and create a mask parameter. You can then specify a different parameter value for each instance of the block or subsystem. Each mask parameter appears in the generated code as a formal parameter of the reentrant function.

In this version of the model, the subsystems PI_ctrl_1 and PI_ctrl_2 are masked. In each mask, the values of the P and I gains are set by data objects such as I_Gain_2 and P_Gain_2.

Generate Code for Atomic Subsystem

In Prepare a Control Algorithm Model for C Code Generation and Configure Data Interface in the Generated Code, you generate code at the root level of the model. Alternatively, you can build a specific subsystem.

To initiate a subsystem build, use the context menu. You can choose from these options:

Build This Subsystem: Treats the subsystem as a separate mode and creates the full set of source C files and header files. This option does not support function-call subsystems.
Generate S-Function: Generates C code for the subsystem and creates an S-Function wrapper. You can then simulate the code in the original model. This option does not support function-call subsystems.
Export Functions: Generates C code without the scheduling code that comes with the Build This Subsystem option. Use this option to build subsystems that use triggers, such as function-call subsystems.

Alternatively, open the Embedded Coder app, select the subsystem and on the C Code tab, click Build.

Examine Generated Code

This example compares the files that are generated for the full system build with the files that are generated for exported functions. You also examine how the masked data appears in the code.

Run the build script for the three options. Then, examine the generated files by clicking the hyperlinks.

rtwdemo_PCG_Eval_P3.c

Full Build: Yes, Step function
PI_ctrl_1: No
Pos_Command_Arbitration: No

PI_ctrl_1.c

Full Build: No
PI_ctrl_1: Yes, Trigger function
Pos_Command_Arbitration: No

Pos_Command_Arbitration.c

Full Build: No
PI_ctrl_1: No
Pos_Command_Arbitration: Yes, Init and Function

PI_Ctrl_Reusable.c

Full Build: Yes
PI_ctrl_1: Yes
Pos_Command_Arbitration: No

ert_main.c

Full Build: Yes
PI_ctrl_1: Yes
Pos_Command_Arbitration: Yes

eval_data.c

Full Build: Yes(1)
PI_ctrl_1: Yes(1)
Pos_Command_Arbitration: No, Eval data not used in diagram

(1) eval_data.c has different content in the full and export function builds. The full build includes all of the parameters that the model uses. The export function contains only the variables that the subsystem uses.

Masked Data in the Generated Code

In the file rtwdemo_PCG_Eval_P3.c, the call sites of the reentrant function use the data objects P_Gain, I_Gain, P_Gain_2, and I_Gain_2 as arguments.

Effect of Execution Order on Simulation Results

By default, Simulink® executes the subsystems in this order:

PI_ctrl_1
PI_ctrl_2
Pos_Command_Arbitration

For this example, you can specify one of two alternative orders of execution. You can then use the test harness to observe the effect of the execution order on the simulation results. The subsystem Execution_Order_Control has two configurations that control the execution order. To choose a configuration, use the subsystem context menu.

Change the execution order and observe the results.

The simulation results (throttle position over time) vary slightly depending on the order of execution. You can see the difference most clearly when the throttle request changes.

For the next example in this series, see Call External C Code from Model and Generated Code.

Nonvirtual Subsystem Modular Function Code Limitations

Nonvirtual subsystem block parameter Function with separate data has the following limitations:

The parameter is available for models configured with an ERT-based system target file.
The nonvirtual subsystem to which the parameter is applied cannot have multiple sample times or continuous sample times; that is, the subsystem must be single-rate with a discrete sample time.
The nonvirtual subsystem cannot contain continuous states.
The nonvirtual subsystem cannot output function call signals.
The nonvirtual subsystem cannot contain noninlined S-functions.
The generated files for the nonvirtual subsystem will reference model-wide header files, such as model.h and model_private.h.
The parameter is incompatible with the Classic call interface parameter. Selecting both parameters generates an error.
The parameter is incompatible with the Reusable function setting for model configuration parameter Code interface packaging. Selecting both parameters generates an error.

When you select the parameter for a subsystem, the model that contains the subsystem cannot contain a Data Store Memory block with Share across model instances selected. See Data Store Memory.