Main Content

Configure and Run SIL Simulation

There are three ways of running SIL and PIL simulations. You can use:

  • The top model.

  • Model blocks.

  • SIL and PIL blocks that you create from subsystems.

Simulation with Top Model

To configure and run a top-model SIL or PIL simulation:

  1. In the Simulink® Editor, open your model.

  2. On the Apps tab, click SIL/PIL Manager.

  3. In the Mode section, select SIL/PIL Simulation Only.

  4. In the Prepare section, set System Under Test to Top model.

  5. In the SIL/PIL Mode field, select either Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL). The option supports only ERT, GRT, or AUTOSAR system target files. See Model Configuration Parameters: Code Generation and Configure AUTOSAR Code Generation (AUTOSAR Blockset) for configuration information.

  6. To monitor component signals and state data and compare values from the model and SIL or PIL simulations:

    1. For each signal that you want to log:

      1. In the Simulink Editor, select the signal.

      2. On the SIL/PIL tab, click Monitor Signals. From the gallery, select these options:

        • Log Selected Signals

        • Make Selected Signals Testpoints

        • Signal Logging

    2. To log state data, from the Monitor Signals gallery, select State Logging.

    3. If the Language configuration parameter is C++ and Code interface packaging is C++ class, in the Code Mappings editor, set the Data Visibility for the signals, states, and internal data model element categories to public.

  7. If you are configuring a SIL simulation, specify the portable word sizes option. You can then switch seamlessly between the SIL and PIL modes. In the Configuration Parameters dialog box, select the Enable portable word sizes check box.

  8. If required, configure:

  9. In the Run section, in the Stop Time field, specify simulation time.

  10. Click Run SIL/PIL.

  11. At the end of the simulation, in the Results section, click Data Inspector to view simulation results.

Note

On a Windows® operating system, the Windows Firewall can potentially block a SIL or PIL simulation. To allow the simulation, use the Windows Security Alert dialog box. For example, in Windows 7, click Allow access.

You cannot:

  • Close the model while the simulation is running. To interrupt the simulation, in the Command Window, press Ctrl+C.

  • Alter the model during the simulation. You can move blocks and lines as long as it does not alter the behavior of the model.

You can run a top-model SIL or PIL simulation with the command sim(model). The software supports the sim command option SrcWorkspace for the value 'base'.

For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations.

Simulation with Model Blocks

To configure a Model block for a SIL or PIL simulation:

  1. Open your model, for example, SILModelBlock:

    openExample('ecoder/SILPILVerificationExample', ...
             supportingFile='SILModelBlock.slx')

  2. Right-click your Model block, for example, Counter A. In the context menu, select Block Parameters (ModelReference), which opens the Function Block Parameters dialog box.

  3. From the Simulation Mode drop-down list, select the required mode, for example, Software-in-the-loop (SIL).

  4. From the Code interface drop-down list, specify the code that you want to test, for example, Model reference.

  5. Click OK. The software displays the simulation mode as a block label.

    Top model contains two model blocks, one in SIL mode, the other in normal mode.

    If you select Top model, the software displays the block label (SIL: Top).

  6. If you are configuring a SIL simulation, specify the portable word sizes option. You can then switch seamlessly between the SIL and PIL modes. In the Configuration Parameters dialog box, select the Enable portable word sizes check box.

  7. On the Apps tab, click SIL/PIL Manager.

  8. In the Mode section, select SIL/PIL Simulation Only.

  9. In the Prepare section, set System Under Test to Model blocks in SIL/PIL mode.

  10. In the Top Model Mode field, select either Normal or Accelerator.

  11. If required, configure:

  12. In the Run section:

  13. At the end of the simulation, in the Results section, click Data Inspector to view simulation results.

Note

On a Windows operating system, the Windows Firewall can potentially block a SIL or PIL simulation. To allow the simulation, use the Windows Security Alert dialog box. For example, in Windows 7, click Allow access.

For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations.

Simulation with Subsystem Blocks

You can use one of these workflows:

  • Simulink Test™ harness with the SIL/PIL Manager—If you have a model that contains subsystems, you can use Simulink Test and the SIL/PIL Manager to perform unit tests on code generated from the subsystems. This workflow tests the generated subsystem code as part of the code generated from the parent model. For workflow details, see Unit Test Subsystem Code with SIL/PIL Manager.

    If this workflow does not support a subsystem, use the SIL or PIL block workflow as an alternative.

  • SIL or PIL block—Create a SIL or PIL block from the subsystem, and then run the block in an environment or test harness model that supplies test vectors or stimulus input. This workflow generates and tests new standalone code from the subsystem. For more information, see SIL or PIL Block Simulation.

For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations.

SIL or PIL Block Simulation

To create a SIL or PIL block from a subsystem and use this block to test the code generated from the subsystem:

  1. From the Configuration Parameters > Code Generation > Verification > Advanced Parameters > Create block drop-down list, select either SIL or PIL.

  2. If required, configure code execution profiling.

  3. Click OK.

  4. In your model window, right-click the subsystem that you want to simulate.

  5. Select C/C++ Code > Build This Subsystem, which starts the subsystem build process that creates a SIL or PIL block for the generated subsystem code.

  6. Add the generated block to an environment or test harness model that supplies test vectors or stimulus input.

  7. Run simulations with the environment or test harness model.

Note

On a Windows operating system, the Windows Firewall can potentially block a SIL or PIL simulation. To allow the simulation, use the Windows Security Alert dialog box. For example, in Windows 7, click Allow access.

You cannot create a SIL or PIL block if you do one of the following:

  • Disable the CreateSILPILBlock property.

  • Select a code coverage tool.

Create block appears dimmed.

Configure Hardware Implementation Settings

For a SIL simulation, you must configure hardware implementation settings, which enables generated code compilation for your development computer. These settings can differ from the hardware implementation settings that you use when building the model for your production hardware. Use one of these approaches.

ApproachDetails
Portable word sizes

Switch between SIL and PIL modes without regenerating code. You use the same generated source code files for the SIL simulation on your development computer and for production deployment on the target platform.

To configure a model to use portable word sizes, set:

  • ProdEqTarget to 'on'.

  • PortableWordSizes to 'on'.

When you generate code for a model with portable word sizes specified, the code generator conditionalizes data type definitions in rtwtypes.h:

#ifdef PORTABLE_WORDSIZES           /* PORTABLE_WORDSIZES defined */

…

#else                               /* PORTABLE_WORDSIZES not defined */

…

#endif                              /* PORTABLE_WORDSIZES */

The template makefile that you use to build code for your target must not contain the PORTABLE_WORDSIZES definition.

For the template makefile and toolchain approaches to building code, the software specifies -DPORTABLE_WORDSIZES for the compiler only for host-based builds.

For information about the template makefile and toolchain approaches to building code, see Configure Toolchain (ToolchainInfo) or Template Makefile Build Process.

Consider the case where your target uses code that your development computer cannot compile. When you switch from the PIL mode to the SIL mode and try to simulate the model, you see compilation errors. You can try to work around this problem by adding the source code files to the SkipForSil group in the build information object RTW.BuildInfo. The SIL build on the host platform does not compile source files present in the SkipForSil group. For information about how you add source code files to a group in the build information object, see:

Numerical results can differ between generated code executing in a SIL simulation and generated code executing on the production hardware under one of these conditions:

  • Your model contains blocks implemented in TLC, for which C integral promotion in expressions can behave differently between the MATLAB® host and the production hardware target. Normal and PIL simulation results match, but SIL simulation results can differ.

  • Your production hardware implements rounding to Floor for signed integer division, and divisions in your model use rounding mode Ceiling, Floor, Simplest, or Zero. Normal and PIL simulation results match, but SIL simulation results can differ.

  • The byte ordering for your production hardware is Big Endian. Normal and PIL simulation results match, but SIL simulation results can differ. For example, when generated code depends on byte order and generated production code is implemented with the aim that its behavior matches normal simulation behavior.

  • You use custom code with the Stateflow® product. In this case, type conversion statements are not inserted into the custom code, which target overflow behavior on the host can require. Normal and PIL simulation results match, but SIL simulation results can differ.

Test hardware

Use this approach only when you want to work around a limitation of portable word sizes.

Set:

  • PortableWordSizes to 'off'.

  • ProdEqTarget to 'off'.

  • TargetHWDeviceType to 'Custom Processor->MATLAB Host Processor'.

Production hardware

Use this approach only when the production hardware settings match your development computer architecture.

Set:

  • PortableWordSizes to 'off'.

  • ProdEqTarget to 'on'.

  • ProdHWDeviceType to match your development computer architecture.

For information about test and production targets, see Configure Run-Time Environment Options.

Log Signals of a Component

SIL and PIL component outputs are available for observation and comparison with other simulation mode outputs. If you want to examine an internal signal, you can enable internal signal logging for top-model or Model block SIL or PIL. With signal logging, you can:

  • Collect signal logging outputs during SIL/PIL simulations, for example, logsout.

  • Log the internal signals and the root-level outputs of a SIL/PIL component.

  • Manage the SIL/PIL signal logging settings with the Simulink Signal Logging Selector.

  • Use the Simulation Data Inspector to:

    • Observe streamed signals during normal, SIL, and PIL simulations.

    • Compare logged signals from normal, SIL, and PIL simulations.

To enable signal logging to the MATLAB workspace and signal streaming to the Simulation Data Inspector during SIL or PIL simulations:

  1. For each signal that you want to monitor:

    1. In the Simulink Editor, select the signal.

    2. On the SIL/PIL tab, click Monitor Signals. From the gallery, select these options:

      • Log Selected Signals

      • Make Selected Signals Testpoints

      • Signal Logging

  2. If the Language configuration parameter is C++ and Code interface packaging is C++ class, in the Code Mappings editor, set the Data Visibility for the signals, states, and internal data model element categories to public.

You can use other methods to examine internal signals of the SIL or PIL component:

  • Manually route the signal to the top level.

  • Use global data stores to access internal signals:

    1. Inside the component, connect a Data Store Write block to the required signal.

    2. Outside the component, use a Data Store Read block to access the signal value.

  • Use MAT-file logging. Note that:

    • MAT-file logging does not support signal logging. If signal logging is enabled, logsout is generated but not stored in the MAT-file.

    • For PIL, the target environment must support MAT-file logging.

For more information, see:

Prevent Code Changes in Multiple Simulations

Use Model block SIL/PIL or the SIL/PIL block with fast restart when you want to run multiple SIL or PIL simulations with:

  • Varying test vectors (parameter sets and input data).

  • Unchanged generated code, that is, none of the simulations regenerate or rebuild code after the initial build. For example, you want to avoid the incremental code generation that an initial value change can trigger.

For Model block SIL/PIL, you can also use one of these methods:

  • In your test harness model, in the Configuration Parameters dialog box, set Rebuild to Never. If the Model block Code interface parameter is Model reference, the software does not rebuild the referenced model code. (If the Code interface parameter is Top model, the software ignores the Rebuild setting.)

  • Create a protected model and generate source or binary code. Then, insert the protected model in your test harness model. With this method, you can verify top-model code (with the standalone code interface) or model reference code.

For the alternative methods of running Model block SIL/PIL, the following table summarizes code generation behavior after the initial build.

SIL and PIL ApproachCode Generation Behavior After Initial Build
Model blockRebuild configuration parameter of test harness model set to Never.

  1. Component (algorithm) code from initial build is not regenerated.

  2. Component code makefile is not called.

  3. SIL/PIL application files from initial build are not regenerated.

  4. SIL/PIL application makefile is called.

Model block (protected model)Source code from protected model.You observe the same behavior except for feature 2. In this case, the component code makefile is run. The component code is recompiled and linked to produce new object code.
Binary code from protected model.You observe features 1–4.

For more information, see:

Speed Up Testing

If your model has SIL/PIL blocks or Model blocks in SIL/PIL mode, you can speed up SIL/PIL testing by:

  • Running the top-model simulation in accelerator mode. This mode accelerates the simulation of model components that are not in SIL or PIL mode.

  • Turning on fast restart. After the first simulation, you can tune parameters and rerun simulations without model recompilation. The SIL/PIL Manager provides a Fast Restart button.

Note

The SIL and PIL simulation modes are not designed for the reduction of model simulation times. If you want to speed up the simulation of your model, use the rapid accelerator mode. For more information, see What Is Acceleration?.

Simulation with Function Calls

Use the Simulink Function block when you want to:

  • Generate code that makes a function-call to external code, for example, driver or legacy code.

  • Provide a subsystem that behaves like the external code in normal, SIL, or PIL simulations.

The example in Configure Calls to AUTOSAR NVRAM Manager Service (AUTOSAR Blockset) shows how you can configure client calls to Basic Software (BSW) NVRAM Manager (NvM) service interfaces from your AUTOSAR software component. In a simulation, Simulink implements the BSW NvM calls through Simulink Function and preconfigured Function Caller blocks. For the final system, you link function-call stubs with external BSW function code that runs in the AUTOSAR Runtime Environment (RTE).

For more information, see Simulink Function Blocks and Code Generation.

Related Topics