SIL and PIL Simulation

About SIL and PIL Simulations

• Overview

• What are SIL and PIL Simulations?

• Why Use SIL and PIL

Overview

Embedded Coder supports software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations, which allow you to verify generated source code and compiled object code.

A SIL simulation involves compiling and running production source code on your host computer, while a PIL simulation involves cross-compiling and running production object code on a target processor or an equivalent instruction set simulator.

You can use SIL and PIL simulations to verify the numerical performance of your code, optimize your code, collect code metrics such as code coverage and execution profiling data, and achieve IEC 61508, ISO 26262, or DO-178 certification. See Why Use SIL and PIL.

For examples of SIL and PIL verification, see rtwdemo_sil_pil_script. For information about how you verify the configuration of your model for a SIL or PIL simulation, see Verifying a SIL or PIL Configuration.

What are SIL and PIL Simulations?

The Embedded Coder product supports software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations.

A SIL simulation involves compiling and running production source code on your host computer to verify the source code. SIL provides a convenient alternative to processor-in-the-loop (PIL) simulation as no target hardware (for example, an evaluation board or instruction set simulator) is required. For examples of SIL verification, see rtwdemo_sil_pil_script.

A PIL simulation involves cross-compiling and running production object code on a target processor or an equivalent instruction set simulator.

You can run a SIL or PIL simulation using:

• The Software-in-the-Loop (SIL) or Processor-in-the-Loop (PIL) simulation mode for top models and Model blocks

• A SIL or PIL block

For more information, see Choosing a SIL or PIL Approach.

The following features enable you to verify the generated code:

• Compare the output of regular simulation modes, for example, Normal or Accelerator, against the output of SIL and PIL simulation modes.

• Easily switch between regular simulation, SIL, and PIL modes.

You can model and test your embedded software component in Simulink and then reuse your test suites across simulation and compiled production code. This approach avoids the time-consuming process of leaving the Simulink software environment and verifying production code on a separate test infrastructure.

Why Use SIL and PIL

You can achieve early verification and fixing of defects when you use SIL and PIL. See V-Model for System Development.

The following table describes situations when you should use SIL and PIL.

Back to Top

How SIL and PIL Simulations Work

In a SIL/PIL simulation, code is generated for either the top model or part of the model. With SIL, this code is compiled for, and executed on the host computer. With PIL, the code is cross-compiled for the target hardware and runs on the target processor.

Through a communication channel, Simulink sends stimulus signals to the code on the host or target processor for each sample interval of the simulation:

• For a top model, Simulink uses stimulus signals from the base or model workspace.

• If you have designated only part of the model to simulate in SIL/PIL mode, then a part of the model remains in Simulink without the use of code generation. Typically, you configure this part of the model to provide test vectors for the software executing on the hardware. This part of the model can represent other parts of the algorithm or the environment model in which the algorithm operates.

When the host/target processor receives signals from Simulink, the processor executes the SIL/PIL algorithm for one sample step. The SIL/PIL algorithm returns output signals computed during this step to Simulink through a communication channel. At this point, one sample cycle of the simulation is complete and Simulink proceeds to the next sample interval. The process repeats and the simulation progresses. SIL/PIL simulations do not run in real time. At each sample period, Simulink and the object code exchange all I/O data. See also Verifying Internal Signals of a Component.

Back to Top

Comparison of SIL and PIL Simulation

Use SIL or PIL simulation to verify automatically generated code by comparing the results with a Normal mode simulation. With SIL, you can easily verify the behavior of production source code on your host computer. However, you cannot verify exactly the same code that is subsequently compiled for your target hardware because the code must be compiled for your host computer (that is, a different compiler and different processor architecture than the target). With PIL simulation, you can verify exactly the same code that you intend to deploy in production, and you can run the code on either real target hardware or an instruction set simulator. See What are SIL and PIL Simulations?.

You can use any of the following approaches to verification.

To decide which verification approach you want to use, see Choosing a SIL or PIL Approach .

Back to Top

Choosing a SIL or PIL Approach

• About Choosing a SIL or PIL Simulation

• When to Use Top-Model SIL or PIL

• When to Use Model Block SIL or PIL

• When to Use the SIL or PIL Block

About Choosing a SIL or PIL Simulation

This section describes how to choose the SIL or PIL verification approach for your needs.

For examples, see rtwdemo_sil_pil_script, which allow you to compare:

• SIL block for SIL Simulation

• SIL or PIL Simulation for Model Blocks

• SIL or PIL Simulation for Top Models

When to Use Top-Model SIL or PIL

Use the top-model approach if you want to:

• Verify code generated for a top model (standalone code interface).

• Load test vectors or stimulus inputs from the MATLAB workspace.

• Switch the entire model between normal, SIL, or PIL simulation modes.

For an example, see rtwdemo_sil_pil_script .

When to Use Model Block SIL or PIL

Use the Model block approach if you want to:

• Verify code generated for referenced models (model reference code interface).

• Provide a test harness model (or a system model) to generate test vector or stimulus inputs.

• Switch a Model block between normal, SIL, or PIL simulation modes.

See Modeling Scenarios with the Model Block.

Modeling Scenarios with the Model Block.  You can use the Model block to test single components or a whole hierarchy of model reference components. For example, you can select a single leaf component for SIL verification. Later in the development cycle, as your components become integrated into a larger system, you can select a hierarchy of components for SIL verification.

You must deploy your Model block component code as part of a standalone executable. The following examples show ways of testing your component.

You can test a model reference component or hierarchy of components by placing a Model block in a test harness model, as shown in model T1.

To test the component, for example, in SIL mode:

1. Set the simulation mode of component C to SIL mode.

2. Simulate the model to run component C in SIL mode, and test its model reference target.

   Note   If the model reference target code interface for component C does not already exist, simulating the model generates it. For more information about the model reference target code interface, see SIL and PIL Code Interfaces.

The following deployment scenarios reuse the model reference target of component C. This reuse allows you to test exactly the same object code that you deploy.

To generate code with the standalone interface for deployment, place a Model block inside an atomic subsystem, as shown by model D1.

To create standalone code, perform a subsystem build of D_Subsys. The standalone code calls the model reference target of component C.

To test the component, for example, in SIL mode:

1. Set the simulation mode of component C to SIL mode.

2. Simulate the model to run component C in SIL mode and test its model reference target.

You can place multiple Model blocks and other blocks into the model to deploy a whole system of components.

To generate code with the standalone interface for deployment, place the Model block inside a top model, as shown by model D2.

To create standalone code, perform a build of D2. The standalone code calls the model reference target of component C.

You can place multiple Model blocks and other blocks into the model to deploy a whole system of components.

To pass test inputs to component C (running in SIL mode):

1. Create a test harness model that references model D2 in Normal mode, as shown by model T2.

   

2. Simulate the T2 model to run component C in SIL mode and test its model reference target.

The Model Dependency Viewer shows the model reference hierarchy of T2 and the simulation modes of each Model block component.

When to Use the SIL or PIL Block

Use the SIL or PIL block if you want to:

• Verify code generated for a top model with a standalone code interface, or a subsystem with a (right-click build) standalone code interface. For more information about the standalone target code interface, see SIL and PIL Code Interfaces.

• Change the model and insert a SIL or PIL block to represent a component running in SIL or PIL mode, in a situation where a test harness model or a system model provides test vector or stimulus inputs.

  For example, you can replace the controller subsystem in the following model,

  

  with a SIL block (highlighted) that represents the controller.

  

  For information about how you create a SIL or PIL block, see Using a SIL or PIL Block.

  Note   If you compare a SIL or PIL block simulation with a top-model simulation, you see that you must perform two steps before you can run the simulation. First, you perform a right-click subsystem build to create the SIL or PIL block. Then, you replace the subsystem in the original model with the newly created SIL block.

Back to Top

Configuring a SIL or PIL Simulation

• Top-Model SIL or PIL Simulation

• Model Block SIL or PIL Simulation

• Using a SIL or PIL Block

• Verifying a SIL or PIL Configuration

• Compatible Models

Top-Model SIL or PIL Simulation

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

1. Open your model.

2. Select either Simulation > Software-in-the-Loop (SIL) or Simulation > Processor-in-the-Loop (PIL).

   Note   This option is available only if the model is configured for an ERT or AUTOSAR target. See Code Generation Pane: General and Generating Code for AUTOSAR Software Components for configuration information.

3. If you have not already done so, in the Configuration Parameters dialog box, on the Data Import/Export pane:

   • In the Input check box and field, specify stimulus signals (or test vectors) for your top model.

   • Configure logging for model outputs, using either output logging or signal logging:

     • In the Output check box and field, specify output logging.

     • In the Signal logging check box and field, specify signal logging.

       The software logs only signals that connect to root-level inports and outports. See Verifying Internal Signals of a Component. If the root outports of your model connect to bus signals, then output logging is not available. Use signal logging for bus signals that connect to root outports.

       If you name the signals, you can log signals that connect to inports or outports of the top model. If you select Signal logging but do not name signals that connect to inports or outports of the top model, then the signal logging object (for example, logsout) does not hold signal data.

   • Disable logging of Data Store Memory variables. The software does not support this option for this simulation mode. If you do not clear the Data stores check box, the software produces a warning when you run the simulation.

   For information about the Data Import/Export pane, see Importing and Exporting Simulation Data and Data Import/Export Pane.

4. If you are configuring a SIL simulation, specify one of the following:

   • Hardware implementation settings that correspond to the host machine. See Hardware Targets.

     For a SIL simulation, you do not have to specify a value for the Byte ordering field on the Hardware Implementation pane. The software uses the byte ordering that the host computer uses.

   • Portable word sizes. See Configuring Hardware Implementation Settings for SIL.

5. If required, configure:

   • Code coverage. See Code Coverage.

   • Code execution profiling. See Configuring Code Execution Profiling.

6. Start the simulation.

Note   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 using the command sim(model).

Note   The software supports the sim command options SrcWorkspace and DstWorkspace for only the following values: SrcWorkspace — 'base' DstWorkspace — 'base' or 'current' For more information on the sim command and its options, see Simulation in the Simulink documentation.

For information about how a simulation behaves when the top model contains a Model block (and this Model block is a parent Model block containing Model blocks at lower levels of its reference hierarchy), see Simulation Mode Override Behavior in Model Reference Hierarchy.

For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations. See Creating a Connectivity Configuration for a Target.

Model Block SIL or PIL Simulation

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

1. Open your model.

   

2. Right-click your Model block, for example, Counter A. In the context menu, select ModelReference Parameters to open the Model Reference Parameters dialog box.

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

   

4. If configuring a SIL simulation, select one of the following:

   • Hardware implementation settings that correspond to the host machine. See Hardware Targets.

     You do not have to specify a value for the Byte ordering field on the Hardware Implementation pane. The software uses the byte ordering that the host computer uses.

   • Portable word sizes. See Setting Up a Model to Generate Code for Host Simulations and Target Deployment

5. Configure code coverage, if required. See Code Coverage.

6. If you require code execution profiling for your Model block, then configure execution profiling for the top model. See Configuring Code Execution Profiling.

7. Start the simulation.

Note   For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations. See Creating a Connectivity Configuration for a Target.

Using a SIL or PIL Block

You can automatically create a SIL or PIL block from a complete model or a subsystem. You can use this block to test the code generated from your model:

1. In the Configuration Parameters dialog box, select Code Generation > SIL and PIL Verification.

2. From the Create block drop-down list, select either SIL or PIL.

3. If you want to enable code execution profiling for a PIL block:

   1. Select the Collect execution time measurements check box.

   2. In the Workspace variable field, specify a name.

   The software does not support code execution profiling in SIL blocks. For more information, see Code Execution Profiling.

4. Click OK.

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

6. Select Code Generation > Build Subsystem.

7. Click Build to start a subsystem build that generates a SIL or PIL block for the generated subsystem code.

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

9. Run simulations with the environment or test harness model to perform SIL or PIL tests.

10. Verify that the generated code captured in the SIL or PIL block provides the same result as the original subsystem.

Note   You cannot create a SIL or PIL block (Create block appears dimmed) if you do one of the following: Disable either the CreateSILPILBlock or GenerateErtSFunction property Select a code coverage tool

For a PIL simulation, you control the way code compiles and executes in the target environment through connectivity configurations. See Creating a Connectivity Configuration for a Target.

For an example of how the SIL block is used in testing, see rtwdemo_sil_pil_script.

For a description of the SIL block as an S-function wrapper, see Generating S-Function Wrappers.

Verifying a SIL or PIL Configuration

You might need to change model settings to configure the model for SIL or PIL. To find out what settings you must change, use the cgv.Config class. Using the cgv.Config class, you can review your model configuration and determine which settings you must change to configure the model for SIL or PIL. By default, cgv.Config changes configuration parameter values to the value that it recommends, but does not save the model. Alternatively, you can specify that cgv.Config use one of the following approaches:

• Change configuration parameter values to the values that cgv.Config recommends, and save the model. Specify this approach using the SaveModel property.

• List the values that cgv.Config recommends for the configuration parameters, but do not change the configuration parameters or the model. Specify this approach using the ReportOnly property.

Note   To execute the model in the target environment successfully, you might need to make additional modifications to the configuration parameter values or the model. Do not use referenced configuration sets in models that you are changing using cgv.Config. If the model uses a referenced configuration set, update the model with a copy of the configuration set. Use the Simulink.ConfigSetRef.getRefConfigSet method. If you use cgv.Config on a model that executes a callback function, the callback function might change configuration parameter values each time the model loads. The callback function might revert changes that cgv.Config made. When this change occurs, the model might no longer be set up for SIL or PIL. For more information, see Using Callback Functions.

For more information about the cgv.Config class, see cgv.Config.

How To Verify a SIL or PIL Configuration.  To verify that your model is configured for SIL or PIL:

1. Construct a cgv.Config object that changes the configuration parameter values without saving the model. For example, to configure your model for SIL:

   c = cgv.Config('vdp', 'connectivity', 'sil');

   Tip   You can obtain a list of changes without changing the configuration parameter values. When you construct the object, include the 'ReportOnly', 'on' property name and value pair. You can change the configuration parameter values and save the model. When you construct the object, include the 'SaveModel', 'on' property name and value pair.

2. Determine and change the configuration parameter values that the object recommends using the configModel method. For example:

   c.configModel();

3. Display a report of the changes that configModel makes. For example:

   c.displayReport();

4. Review the changes.

5. To apply the changes to your model, save the model.

Compatible Models

You can use the SIL simulation mode with any Simulink model, if:

1. The model specifies an ERT-based target.

2. The model specifies one of the following template makefiles:

   1. ert_default_tmf

   2. ert_unix.tmf

   3. ert_vc.tmf

   4. ert_vcx64.tmf

   5. ert_lcc.tmf

   The software does not support the Watcom compiler template makefile (ert_watc.tmf).

3. The host and target word sizes match. For example, if your host is a Windows XP computer, then you must specify, through the Hardware Implementation pane, a hardware device with the following word sizes (in bits):

   • char — 8

   • short — 16

   • int — 32

   • long — 32

   • native word size — 32

   See also Configuring Hardware Implementation Settings for SIL.

Back to Top

Running a Top Model as a SIL or PIL Simulation

With a top-model SIL or PIL simulation:

• Simulink generates and executes code that uses the same code interface produced by the standalone build process. See SIL and PIL Code Interfaces.

• You can specify external stimulus signals and log output signals, which allows you to verify object code generated from a complete model without creating a separate test harness model. Running the SIL or PIL simulation is a simple operation.

Top-model SIL simulation is an alternative to the block-based approach where you provide a test harness model that wraps a Model block (in SIL mode). Two differences between the block-based approach and top-model SIL simulation are:

• With Model block SIL simulation, the model reference target that is generated does not have the same interface as standalone code (see SIL and PIL Code Interfaces).

• With Model block SIL simulations, you cannot directly specify external stimulus signals or enable signal logging. You must use input and output blocks to feed signals into and out of your model. See Verifying Internal Signals of a Component and Choosing a SIL or PIL Approach.

To compare all SIL simulation options, see Choosing a SIL or PIL Approach.

For the top-model SIL approach, Simulink creates a hidden wrapper model. When you run a top-model SIL simulation, the software generates code for the model and creates a hidden wrapper model to call this code at each time step.

• If there are errors during a SIL simulation, you may see messages that refer to the wrapper model. For wrapper model error messages, the wrapper model is made visible to allow you to investigate the error.

• For signal logging, the software adds the suffix _wrapper to the block path for signals in logsout, as shown in the following example:

  >> logsout.SignalLogging
  
            Name: 'SignalLogging'
       BlockPath: 'sillogging_wrapper/sillogging'
       PortIndex: 1
      SignalName: 'SignalLogging'
      ParentName: 'SignalLogging'
        TimeInfo: [1x1 Simulink.TimeInfo]
            Time: [11x1 double]
            Data: [11x1 double]
  

• For output logging, if the save format is Structure or Structure with time, the software adds the suffix _wrapper to the block name for signals in yout, as shown in the following example:

  >> yout.signals
  
  ans = 
          values: [11x1 double]
      dimensions: 1
           label: 'SignalLogging'
       blockName: 'sillogging_wrapper/OutputLogging'
  

  If the save format is Array, then the software does not add a wrapper suffix.

Back to Top

Running a Referenced Model as a SIL or PIL Simulation

In addition to the regular simulation modes, Model blocks have a Software-in-the-loop (SIL) and Processor-in-the-loop (PIL) mode.

You can switch the Model block between regular, SIL, and PIL simulation modes. This allows you to easily verify the generated code by executing the referenced model as compiled code on the host computer or target platform. You can model and test your embedded software component in Simulink and you can reuse your regression test suites across simulation and compiled object code. This capability avoids the time-consuming process of leaving the Simulink software environment to run tests again on object code compiled for your production hardware.

The label (SIL) or (PIL) on the block indicates the mode of the Model block.

To understand how SIL or PIL works in the Model block, see the following information:

• Simulation Mode Override Behavior in Model Reference Hierarchy

• SIL and PIL Code Interfaces

• When to Use Model Block SIL or PIL

• Modeling Scenarios with the Model Block

For an introduction to the Model block, see the Model, Model Variants block section in the Simulink reference documentation.

Verifying Internal Signals of a Component

Outputs of the SIL or PIL component are available for verification. If you want to examine an internal signal, you can:

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

     See Working with Data Stores and Global Data Store Example in the Simulink documentation.

• Use MAT-file logging. See Logging. For PIL, target environment must support MAT-file logging.

For more information on signal support, see I/O Support.

Simulation Mode Override Behavior in Model Reference Hierarchy

This section describes simulation behavior when the top model contains a Model block. This Model may also be a parent block containing child Model blocks at lower levels of its reference hierarchy.

Note   You can view your model hierarchy in the Model Dependency Viewer. In the Referenced Model Instances view, the software displays Model blocks differently to indicate their simulation modes, for example, Normal, Accelerator, SIL, and PIL. In this view, the software does not indicate the simulation mode of the top model.

You can specify the simulation mode of a top model to be Normal, Accelerator, Rapid Accelerator, SIL, or PIL. With a Model block, you can specify all modes except Rapid Accelerator. The configured simulation mode of a Model block may be overridden by the parent simulation mode. The following table shows how the software determines the effective simulation mode of any Model block in the hierarchy.

The following list explains the different types of simulation behavior:

• Equivalent – Both parent and child Model block run in the same simulation mode.

• Compatible – If the simulation mode of the top model or parent block is Normal, then the software simulates the child block in the mode specified for it.

• Error – The simulation produces an error. For example, if a top model or parent Model block has simulation mode Accelerator but contains a child block in SIL or PIL mode, then running a simulation produces an error: the Accelerator mode can never override the SIL and PIL mode of child blocks. This behavior avoids the risk of "false positives", that is, the successful simulation of a model in Accelerator mode will never lead to the conclusion that generated source or object code of child Model blocks has been tested or verified.

• Override – The simulation mode of the top model or parent Model block overrides the simulation mode of the child block. For example, if a top model or parent Model block that is configured for a SIL simulation contains a child Model block with simulation mode Normal or Accelerator, then the software simulates the child block in SIL mode. This override behavior:

  • Allows a Model block anywhere in the reference hierarchy to have the SIL or PIL mode.

  • makes all lower-level referenced models execute in SIL or PIL mode if you simulate the top model or parent Model block in SIL or PIL mode, . You do not have to switch manually the simulation mode of every model component in the hierarchy.

For an example model hierarchy, see Modeling Scenarios with the Model Block.

Back to Top

SIL and PIL Code Interfaces

This section describes and compares the different code interfaces that the code generation products produce.

You generate standalone code when you perform a top-model or right-click subsystem build for a single deployable component. You can compile and link standalone code into a standalone executable or integrate it with other code. For more information on the standalone code interface, see Entry Point Functions and Scheduling.

When you generate code for a referenced model hierarchy, the software generates standalone executable code for the top model, and a library module called a model reference target for each referenced model. When the code executes, the standalone executable invokes the applicable model reference targets to compute the referenced model outputs. For more information, see Referenced Models.

Note   The model reference target does not have the same code interface as standalone code. If you intend to integrate automatically generated code with legacy code, use standalone code because the standalone code interface (for example, entry points) is fully documented.

SIL/PIL Feature	Standalone Code Interface	Model Reference Code Interface
Top-model	Yes	No (but you can include Model blocks inside your top model)
Model block	No	Yes
SIL or PIL block	Yes	No

Code Interface for Top-Model SIL or PIL

Top-model SIL or PIL generates the standalone code interface for the model.

When you run a top-model SIL or PIL simulation, the software calls the standalone code for the model if it already exists. The software generates the standalone code if it does not exist.

Code Interface for Model Block SIL or PIL

Model block SIL or PIL mode generates the model reference code interface.

When you run a simulation with a Model block in SIL or PIL mode, the software calls the model reference target for the Model block if it already exists, or generates the model reference target.

If the model reference target does not yet exist, you can generate it in one of three ways:

• Run the simulation.

• Press Ctrl+B to build the top model containing the Model block.

• Use the command slbuild, specifying the model reference option, for example:

    slbuild('model','ModelReferenceRTWTargetOnly')

You cannot use standalone code with the Model block. You can generate standalone code for a model referenced by a Model block by opening the model and performing a top-level build. However, you cannot use this standalone code with Model block SIL or PIL simulation.

For more information, see the table in Choosing a SIL or PIL Approach.

Back to Top

Configuring Hardware Implementation Settings for SIL

• Compiling Generated Code That Supports Portable Word Sizes

• Portable Word Sizes Limitations

Embedded Coder provides an option to specify portable word sizes. If you select this option for a model, you can use the same generated source code files for:

• Software-in-the-loop (SIL) simulation on the host computer

• Production deployment on the target platform

If you do not specify portable word sizes for a SIL simulation, you can configure the model to use an emulation hardware option. For integer and fixed-point operations, this option provides bit-true agreement between host computer simulation and target deployment. See Hardware Targets.

Note   If processor word sizes differ between host and target platforms, and you do not use any of the preceding options for SIL simulation, there are likely to be differences between host computer results and target execution results. When you use portable word sizes for SIL simulation, subtle differences in host and target processor behavior can still occasionally cause host simulation results to differ from target execution results. For more information, see Portable Word Sizes Limitations.

To configure a model to use portable word sizes, set the following model configuration parameters.

When you generate code for a model with the preceding parameter settings, the code generator conditionalizes data type definitions:

• tmwtypes.h supports SIL simulation on the host system

• Code generation types support deployment on the target system

For example, in the following generated code, the first two lines define types for SIL simulation on a host system. The bold lines define types for target deployment.

#ifdef PORTABLE_WORDSIZES    /* PORTABLE_WORDSIZES defined */
# include "tmwtypes.h"
#else                        /* PORTABLE_WORDSIZES not defined */
#define __TMWTYPES__
#include <limits.h>
...
typedef signed char int8_T;
typedef unsigned char uint8_T;
typedef int int16_T;
typedef unsigned int uint16_T;
typedef long int32_T;
typedef unsigned long uint32_T;
typedef float real32_T;
typedef double real64_T;
...
#endif                       /* PORTABLE_WORDSIZES */

For an example of how to configure a model to maintain bit-true agreement between host simulation and target deployment, and generate code that is portable between the host and target systems, see rtwdemo_sil_hardware_config.

Compiling Generated Code That Supports Portable Word Sizes

When you compile generated code that supports portable word sizes for SIL testing, pass the definition PORTABLE_WORDSIZES to the compiler.

For example:

-DPORTABLE_WORDSIZES

To build the same code for target deployment, compile the code without the PORTABLE_WORDSIZES definition.

Portable Word Sizes Limitations

The following limitations apply to using portable word sizes for SIL simulation:

• Numerical results might differ between generated code executing in a SIL simulation versus executing on the embedded hardware under one of the following conditions:

  • Your model contains blocks implemented in TLC, for which C integral promotion in expressions might behave differently between the MATLAB host and the embedded hardware target. Normal and PIL simulation results will match, but SIL simulation results might be different.

  • Your embedded hardware implements rounding to Floor for signed integer division, and divisions in your model use rounding mode Floor or Simplest. Normal and PIL simulation results will match, but SIL simulation results might be different.

  • The precision of floating-point operations differs between the MATLAB host and the embedded hardware target. In this case, Normal and SIL simulation results will match, but PIL simulation results might be different.

• Compilation warnings might occur for code generated using portable word sizes if all of the following conditions exist:

  • The combination of MATLAB host and embedded hardware target word sizes causes rtwtypes.h to redefine the word sizes using preprocessor macros. For example, when the embedded hardware has a 16-bit int data type and the MATLAB host has a 16-bit short data type, int16_T is redefined to be short on the host and int on the target.

  • The data types are used in pointer arguments to function calls.

  • The called functions are host-based precompiled functions (not compiled using rtwtypes.h).

  Under these conditions, the compiler typically issues a warning similar to the following:

  warning: passing argument 2 of 'frexp' from incompatible pointer type

  Executing the generated code on the MATLAB host could lead to memory corruption. For example, the function "double frexp (double value, int *exp);" expects 'int *' as the second argument, for which 'int16_T *' is passed in the generated code. But on the MATLAB host, int16_T is redefined to short, and during SIL execution, frexp will attempt to write 4 bytes to a 2 byte location.

  A potential workaround for the SIL workflow is to provide a custom Target Function Library (TFL) entry for functions that write to address locations obtained through pointer arguments. In the above example, the function frexp is called by the reciprocal square root operation (rSqrt) and rSqrt is replaceable using TFLs. Therefore, you can provide a custom version of rSqrt to support SIL execution. The replacement function would perform the change in memory allocation for the data accessed by the pointer variable, perhaps by introducing a temporary variable and transferring the data to and from that variable. For more information about TFLs, see Code Replacement.

Back to Top

Programming PIL Support for Third-Party Tools and Target Hardware

You can use the Processor-in-the-loop (PIL) Connectivity API to apply the power of PIL verification to object code compiled for your target processor. There are many custom or third-party tools for building, downloading, and communicating with an executable on a target environment. Use the API to integrate your tools for:

• Building the PIL application (an executable for the target hardware)

• Downloading and running the executable

• Communicating with the executable

You can use PIL with any target hardware or instruction set simulator, and any combination of tools that provide the required level of automation. For hardware cases that MathWorks does not support, see SIL and PIL Simulation Support and Limitations.

For instructions and demos on PIL and the Target Connectivity API, see:

• Configuring a SIL or PIL Simulation

• Creating a Connectivity Configuration for a Target

• Demos of the Target Connectivity API

Back to Top

Creating a Connectivity Configuration for a Target

• What Is a PIL Connectivity Configuration?

• Overview of the Target Connectivity API

• Creating a Connectivity API Implementation

• Registering a Connectivity API Implementation

• Demos of the Target Connectivity API

What Is a PIL Connectivity Configuration?

You can use PIL connectivity configurations and the target connectivity API to customize PIL to work with any target environment.

Use a connectivity configuration to define:

• A configuration name

• A connectivity API implementation

• Settings that define the set of Simulink models that the configuration is compatible with, for example, the set of models that have a particular system target file, template makefile, and hardware implementation.

You can use the API to integrate third party tools for:

• Building the PIL application, an executable for the target hardware

• Downloading and running the executable

• Communicating with the executable

A particular connectivity configuration name is associated with a single connectivity API implementation. Many different connectivity configurations can coexist and be available for use with PIL simulations. You register each connectivity configuration to Simulink by creating an sl_customization.m file and placing it on the MATLAB path.

To run a PIL simulation, the software must first determine which of the available connectivity configurations to use. The software looks for a connectivity configuration that is compatible with the model under test. If the software finds multiple or no compatible connectivity configurations, you see an error message describing how to resolve the problem.

For information on how you create a connectivity configuration for a target, see:

1. Overview of the Target Connectivity API

2. Creating a Connectivity API Implementation

3. Registering a Connectivity API Implementation

See also Example Custom Targets for information about running PIL simulations on specific targets.

Overview of the Target Connectivity API

• Target Connectivity API Components

• Communications rtiostream API

Target Connectivity API Components.  The following diagram shows what functions the Target Connectivity API components perform:

• Configuring the build process

• Controlling communication between Simulink and the target

• Downloading, starting, and stopping the application on the target

Communications rtiostream API.  

The communications part of the target connectivity API builds upon the rtiostream API, described in this section.

You can use the rtiostream API to implement a communication channel to enable exchange of data between different processes. This communication channel is required to enable processor-in-the-loop (PIL) on a new target.

PIL requires a host-target communications channel. This communications channel comprises driver code that runs on the host and target. The rtiostream API defines the signature of both target-side and host-side functions that must be implemented by this driver code.

The API is independent of the physical layer that sends the data. Possible physical layers include RS232, Ethernet, or Controller Area Network (CAN).

A full rtiostream implementation requires both host-side and target-side drivers. Code generation software includes host-side drivers for the default TCP/IP implementation (all platforms) as well as a Windows only version for serial communications. To use the TCP/IP rtiostream communications channel, you must provide, or obtain from a third party, target-specific TCP/IP device drivers. You must also do this if you require serial communications. For other communication channels and platforms, there is no default implementation provided by the code generation software. You must provide both the host-side and the target-side drivers.

The rtiostream API comprises the following functions:

• rtIOStreamOpen

• rtIOStreamSend

• rtIOStreamRecv

• rtIOStreamClose

You can use rtiostream_wrapper to test the rtiostream shared library methods from MATLAB code.

To see how the rtiostream functions fit into the workflow of creating a connectivity implementation, see the next section, Creating a Connectivity API Implementation.

Creating a Connectivity API Implementation

To create a target connectivity API implementation, you must create a subclass of rtw.connectivity.Config.

• You must instantiate rtw.connectivity.MakefileBuilder. This class configures the build process.

• You must create a subclass of rtw.connectivity.Launcher. This class downloads and executes the application using a third-party tool.

• Configure your rtiostream communications implementation:

  • On the target-side, integrate the driver code implementing rtiostream functions directly into the build process by creating a subclass of rtw.pil.RtIOStreamApplicationFramework.

  • On the host-side, compile the driver code into a shared library. You load and initialize this shared library by instantiating (or optionally, customizing) rtw.connectivity.RtIOStreamHostCommunicator.

• If you want to carry out code execution profiling and your target does not have built-in timer support, you must create a subclass of rtw.connectivity.Timer to generate a timer object. This timer object provides details of the hardware-specific timer and any associated source files.

See also:

• Creating Subclasses — Syntax and Techniques in MATLAB documentation.

• Processor-in-the-Loop for all classes, methods, and functions in the Target Connectivity API

• rtwdemo_custom_pil for a demo that helps you to create a target connectivity configuration using the Target Connectivity API

Registering a Connectivity API Implementation

Register the new connectivity API implementation to Simulink as a connectivity configuration, by creating or adding to an sl_customization.m file. By doing this, you also define the set of Simulink models that the new connectivity configuration is compatible with.

For details, see rtw.connectivity.ConfigRegistry.

Demos of the Target Connectivity API

For step-by-step examples, see the following demos:

• rtwdemo_custom_pil

  This demo shows you how to create a custom PIL implementation using the target connectivity APIs. You can examine the code that configures the build process to support PIL, a tool to use for downloading and execution, and a communication channel between host and target. Follow the steps in the demo to activate a full host-based PIL configuration.

• rtwdemo_rtiostream

  This demo shows you how to implement a communication channel for use with the Embedded Coder product and your embedded target. This communication channel enables exchange of data between different processes. PIL simulation requires this because it requires exchange of data between the Simulink software running on your host computer and deployed code executing on target hardware.

  The rtiostream interface provides a generic communication channel that you can implement in the form of target connectivity drivers for a range of connection types. The demo shows how to configure your own target-side driver for TCP/IP, to operate with the default host-side TCP/IP driver. The default TCP/IP communications allow high bandwidth communication between host and target, which you can use for transferring data such as video.

  The demo also shows how to implement custom target connectivity drivers, for example, using serial, CAN, or USB for both host and target sides of the communication channel.

Back to Top

SIL and PIL Simulation Support and Limitations

• About SIL and PIL Simulation Support and Limitations

• Code Source Support

• Block Support

• Configuration Parameters Support

• I/O Support

• Hardware Implementation Support

• Other Feature Support

About SIL and PIL Simulation Support and Limitations

Top-model and Model block software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulation modes, and SIL and PIL blocks are Embedded Coder features.

The following tables summarize the support provided for top-model SIL and PIL, Model block SIL and PIL and the SIL or PIL block. "Yes" indicates a supported feature.

Information on selected aspects of SIL and PIL is also provided, especially unsupported features and limitations.

Code Source Support

For more information on code interfaces, see SIL and PIL Code Interfaces.

Custom Code Interfaces.  MathWorks does not provide direct SIL/PIL support for code interfaces such as legacy code and MATLAB Coder. However, you can incorporate these interfaces into Simulink as an S-function (for example, using the Legacy Code Tool, S-Function Builder, or handwritten code), and then verify them using SIL/PIL.

SIL/PIL Does Not Check Simulink Coder Error Status.  SIL/PIL does not check the Simulink Coder error status of the generated code under test. This error status flags exceptional conditions during execution of the generated code.

The Simulink Coder error status can also be set by blocks in the model (for example, custom blocks developed by a user). It is a limitation that SIL/PIL cannot check this error status and report back errors.

Cannot Use Multirate Model Block SIL/PIL Inside Conditionally Executed Subsystem.  You see an error if you place your Model block (in either SIL or PIL simulation mode) in a conditionally executed subsystem and the referenced model is multirate (that is, has multiple sample times). Single rate referenced models (with only a single sample time) are not affected.

PIL Block Export Functions.  The PIL block does not support the export of functions from triggered subsystems. With the PIL block, you can export only function-call subsystems.

Block Support

Merge Block Issue.  If you connect SIL/PIL outputs to a Merge block, you see an error because S-function memory is not reusable.

Other Top-Model SIL/PIL Limitations.  SIL/PIL does not support the callbacks (model or block ) StartFcn and StopFcn.

Note   Top-model SIL/PIL supports the callback InitFcn.

Configuration Parameters Support

• Missing Code Interface Description File Errors

• Algebraic Loop Issues

Missing Code Interface Description File Errors.  SIL/PIL requires a code interface description file, which is generated during the code generation process for the component under test. If the code interface description file is missing, the SIL/PIL simulation cannot proceed and you see an error reporting that the file does not exist. This error can occur if you select these unsupported options in your configuration parameters:

• GRT compatible call interface

• Target Language option C++ encapsulated

Do not select these options.

Algebraic Loop Issues.  For more information on algebraic loops, see:

• Algebraic Loops in the Simulink documentation.

• The Algebraic Loops section in Modeling Semantic Considerations.

• The Introduction section in Subsystems.

There are three ways that PIL simulation can introduce algebraic loops that do not exist for a normal simulation:

If you generate code for a virtual subsystem, code generation treats the subsystem as atomic and generates the code accordingly. The resulting code can change the execution behavior of your model, for example, by applying algebraic loops, and introduce inconsistencies to the simulation behavior.

Declare virtual subsystems as atomic subsystems to enable consistent simulation and execution behavior for your model.

See Subsystems.

The "single output/update function" in code generation optimization can introduce algebraic loops because it introduces direct feedthrough via a combined output and update function.

This option is not compatible with the Minimize algebraic loop occurrences option (in the Subsystem Parameters dialog box and Model Referencing pane of the Configuration Parameters dialog box). This option allows code generation to remove algebraic loops by partitioning generated code between output and update functions to avoid direct feedthrough.

The S-function scheduling mechanism that the software uses to execute the SIL/PIL component has the following limitations:

• Direct feedthrough is always set to true.

• Separate output and update functions in the SIL/PIL component are always executed from the mdlOutputs S-function callback.

These limitations mean that SIL/PIL can introduce algebraic loops that do not exist in normal simulation, and you might get incorrect results. If this happens, you see a warning or error about the introduced algebraic loop and SIL/PIL results may differ from simulation results. You do not see or warning or error if the algebraic loop setting is "none" in the Configuration Parameters dialog box (under Diagnostics on the Solver pane).

A workaround is to break the algebraic loop by inserting a Unit Delay block so that the algebraic loop does not occur. You can then use SIL/PIL successfully.

I/O Support

• Tunable Parameters and SIL/PIL

• Global Data Store Support

• Imported Data Definitions

• GetSet Custom Storage Class

• Unsupported Implementation Errors

• Variable-Size Signals and SIL/PIL

• Fixed-Point Tool Data Type Override

• Data Type Overrides Unavailable for Most Blocks in Embedded Targets and Desktop Targets

• Data Type Replacement Limitation

• Top-Model SIL/PIL Bus Limitations

• PIL Block Virtual Bus Support Limitations

• PIL Block MUX Support Limitations

• Incremental Build for Top-Model SIL/PIL

• Top-Model SIL/PIL Logging Limitations

• Exported Functions in Feedback Loops

Tunable Parameters and SIL/PIL.  You can tune parameters during a SIL/PIL mode simulation the same way that you tune parameters during a Normal mode simulation.

For more information, see Global Tunable Parameters and Using Model Arguments in the Simulink documentation.

During a PIL block simulation, the software supports the tuning of tunable workspace parameters but not tunable block dialog parameters.

During a SIL/PIL simulation, the software cannot define, initialize, or tune the following types of tunable workspace parameters and produces warnings or errors.

If you select the configuration parameter Generate reusable code but do not select Inline parameters and the model contains parameters, then top-Model SIL/PIL and the PIL block can produce errors . If these conditions apply, then the software produces an error similar to the following:

Parameter Dialog:InitialOutput in 'rtwdemo_sil_topmodel/CounterTypeA/count' 
is part of the imported "rtP" structure in the generated code but cannot be 
initialized by SIL or PIL. To avoid this error, make sure the parameter 
corresponds to a tunable base workspace variable with a storage class such 
as SimulinkGlobal and is supported for dynamic parameter initialization / 
tuning with SIL/PIL.

Global Data Store Support.  SIL/PIL supports global data stores. PIL components that access global data stores must be single rate. If your SIL/PIL component has multiple sample times and accesses global data stores, you see an error. To avoid the error, either remove accesses to global data stores or make the component single rate.

Imported Data Definitions.   You can use signals, parameters, data stores, etc., that specify storage classes with imported data definitions.

The SIL/PIL application automatically defines storage for imported data associated with:

• Signals at the root level of the component (on the I/O boundary)

• Parameters. See Tunable Parameters and SIL/PIL Limitations.

• Global data stores

A limitation is that SIL/PIL does not define storage for other imported data storage. You must define the storage through custom code included by the component under test or through the PIL rtw.pil.RtIOStreamApplicationFramework API. For example, the PIL application does not define imported data storage for data associated with:

• Internal signals (not on the I/O boundary)

• Local data stores

Top-Model SIL/PIL and SIL/PIL Block.  

The top-model SIL/PIL or PIL block application automatically defines storage for imported data associated with:

• Signals at the root level of the component (on the I/O boundary)

• Global data stores

• Parameters. See Tunable Parameters and SIL/PIL Limitations.

A limitation is that SIL/PIL does not define storage for other imported data storage. You must define the storage through custom code included by the component under test or through the PIL rtw.pil.RtIOStreamApplicationFramework API. For example, the SIL/PIL application does not define imported data storage for data associated with:

• Internal signals (not on the I/O boundary)

• Local data stores

GetSet Custom Storage Class.  The software supports the GetSet custom storage class for all types of SIL and PIL simulations, with one limitation. GetSet behavior for the SIL block is different from top-model SIL/PIL, Model block SIL/PIL, and PIL block:

• SIL block — The C definitions of the Get and Set functions that you provide form part of the algorithm under test.

• Other types of SIL/PIL — The SIL/PIL test harness automatically provides C definitions of the Get and Set functions that are used during SIL/PIL simulations. In addition, the software supports only scalar signals, parameters and global data stores.

Unsupported Implementation Errors.  If you use a data store, signal, or parameter implementation that SIL/PIL does not support, you may see errors like the following:

The following data interfaces have 
implementations that are not supported by SIL or PIL.

data interfaces may be global data stores, inports, outports or parameters.

You see this error message because the model output port has been optimized through virtual output port optimization. See Using Virtualized Output Ports Optimization. The error occurs because the properties (for example, data type, dimensions) of the signal or signals entering the virtual root output port have been modified by routing the signals in one of the following ways:

• Through a Mux block

• Through a block that changes the signal data type. To check the consistency of data types in the model, display Port Data Types by selecting Format > Port/Signal Displays > Port Data Types.

• Through a block that changes the signal dimensions. To check the consistency of data types in the model, display dimensions by selecting Format > Port/Signal Displays > Signal Dimensions.

  Note   Dimension changes from scalar (1) to matrix [1x1], and, matrix [1x1] to scalar (1), can lead to this error. Furthermore, it is difficult to inspect the model for such changes because the Format > Port/Signal Displays > Signal Dimensions feature does not distinguish between (1) and [1x1] dimensions. The software shows both signals as scalar signals. Check your model and workspace objects carefully and see that scalar dimensions are specified consistently.

The following example illustrates a model that causes this error due to changing the output port signal data type.

Variable-Size Signals and SIL/PIL.  SIL/PIL treats variable-size signals at the I/O boundary of the SIL/PIL component as fixed-size signals, which can lead to errors during propagation of signal sizes. To avoid such errors, use only fixed-size signals at the I/O boundary of the SIL/PIL component.

There may be cases where no error occurs during propagation of signal sizes. In these cases, the software treats variable-size input signals as zero-size signals.

Fixed-Point Tool Data Type Override.  SIL/PIL does not support signals with data types overridden by the Fixed-Point Tool Data type override parameter at the SIL/PIL component boundary.

You may see an exception message like the following:

Simulink.DataType object 'real_T' is not in scope
from 'mpil_mtrig_no_ic_preread/TmpSFcnForModelReference_unitInTopMdl'.
 This error message is related to a hidden S-Function block. 

There is no resolution for this issue.

Data Type Overrides Unavailable for Most Blocks in Embedded Targets and Desktop Targets.  When you attempt to perform a datatype override on a block, you may get an error message similar to the following example:

Error reported by S-function 'sfun_can_frame_splitter' in 'c2000_host_CAN_monitor/CAN Message Unpacking/CAN Message Unpacking': Incompatible DataType or Size specified.

Data type overrides using the Fixed point tool are not available for those blocks in Simulink Coder > Desktop Targets and Embedded Coder > Embedded Targets libraries that support fixed-point.

There is no resolution for this issue.

Data Type Replacement Limitation.   The software does not support replacement data type names that you define for the built-in data type boolean if these names map to either the int or uint built-in data type.

Top-Model SIL/PIL Bus Limitations.  The software does not support grounded or unconnected signals at the outputs of a top model.

You must enable the strict bus mode for top-model SIL/PIL:

1. In the model window, select Simulation > Configuration Parameters > Diagnostics > Connectivity.

2. Set Mux blocks used to create bus signals to error.

PIL Block Virtual Bus Support Limitations.  The PIL block supports virtual buses except for the following cases:

• You see an error if the PIL component is a top model with a root level outport that is configured to output a virtual bus. A root level outport outputs a virtual bus, regardless of the type of the bus that drives it, if it specifies a bus object and the Output as nonvirtual bus in parent model check box is not selected.

• You see an error if a right-click subsystem build expands the bus into individual signals.

• For right-click subsystem builds only, the PIL block changes the output of outports driven by virtual buses (with associated bus objects) into nonvirtual buses. You do not see an error message in this case.

To avoid these limitations, use nonvirtual buses at the PIL component boundary.

PIL Block MUX Support Limitations.  The PIL block supports mux signals, except mixed data-type mux signals that expand into individual signals during a right-click subsystem build. You see an error for unsupported cases.

Incremental Build for Top-Model SIL/PIL.  When you start a top-model SIL/PIL simulation, the software regenerates code if it detects changes to your model. The software detects changes by using a checksum for the model. However, the software does not detect changes that you make to:

• The HeaderFile property of a Simulink.AliasType object

• Legacy S-functions

Therefore, if you make these changes, you must build (Ctrl-B) your model again before starting the next PIL simulation.

Top-Model SIL/PIL Logging Limitations.  

Exported Functions in Feedback Loops.  If your model has function-call subsystems and you export a subsystem that has context-dependent inputs (for example, feedback signals), then the results of a SIL/PIL simulation with the generated code may not match the results of the Normal mode simulation of your model. One approach to make SIL/PIL and Normal mode simulations yield identical results is to use Function-Call Feedback Latch blocks in your model. This approach allows you to make context-dependent inputs become context-independent.

Note   The software generates a warning identifying context-dependent inputs of exported function-call subsystems, regardless of your setting for the Context-dependent inputs field in the Configuration Parameters > Diagnostics > Connectivity pane. See also Context-dependent inputs in the Simulink Reference documentation.

Hardware Implementation Support

Hardware Implementation Settings.  PIL requires that, in the Simulink Configuration Parameters dialog box, you configure the right Hardware Implementation settings for the target environment.

Specify byte ordering for non-8-bit targets.

For more information, see the following sections:

PIL supports only data types that have the same size on the host and the target at the PIL I/O boundary.

The data types used at the PIL I/O boundary are restricted based on the following rule: PIL supports the data type only if the data-type size on the host (Simulink) is the same as the data-type size on the target.

• For boolean, uint8, and int8, the size is 8-bits.

• For uint16 and int16, the size is 16-bits.

• For uint32 and int32, the size is 32-bits.

• For single, the size is 32-bits.

• For double, the size is 64-bits.

Examples of unsupported data types are:

• single and double on targets with 24-bit floating-point types

• double on targets with 32-bit double, that is, the same size as single

Warning   PIL does not always detect unsupported data types (see Data Type Size Mismatch Issues (Embedded Coder) and Data Type Size Mismatch Issues (Embedded Targets)). In such cases, data transfer between host and target is incorrect and unexpected data transfer errors occur during the PIL simulation.

To resolve issues with Simulink data types that have different sizes on the host and target, do not use them at the PIL I/O boundary. Instead, use a Simulink data type that maps directly onto a target data type. This resolution is more efficient.

PIL mode makes the following assumptions about the target environment:

• The target is byte addressable.

• Sizes of data types on the host and target match.

• Word order of multiword data types on the target is the same as the target byte order.

Warning   PIL does not detect violations of these assumptions. If the settings for the target environment violate any of these assumptions, unexpected data transfer errors occur during the PIL simulation.

To resolve issues with Simulink data types that have different sizes on the host and target, do not use them at the PIL I/O boundary. Instead, use a Simulink data type that maps directly onto a target data type. This resolution is more efficient.

Some known violations with predefined hardware implementation settings are unsupported word addressable targets: TI's C2000, Freescale DSP563xx.

The embedded targets registers the following information about the target environment to Simulink:

• Whether the target is byte addressable.

• The sizes of data types on the target.

• The word order of multiword data types on the target.

This allows PIL to support target environments with unusual hardware characteristics.

PIL can detect data types used at the PIL component boundary that have a host/target data type size mismatch. In such cases, an error indicates that an unsupported data type is being used. This avoids unexpected data transfer errors during simulation.

To resolve issues with Simulink data types that have different sizes on the host and target, do not use them at the PIL I/O boundary. Instead, use a Simulink data type that maps directly onto a target data type. This resolution is more efficient.

Some target compilers allow the sizes of target data types to be changed from their default size. For example, an IEEE^® double data type is most likely 8 bytes by default, but an optimization option may be provided to treat it as a 4 byte IEEE single precision type instead. The registration of target data type sizes done by the embedded targets features is typically statically defined to match the compiler's default data type size, and therefore does not support changing the data type size from that default size.

Warning   If you use a nondefault compiler configuration, the target data type sizes registered by the embedded targets features and the actual target data type sizes may differ. In such cases, data transfer between host and target is incorrect and unexpected data transfer errors occur during the PIL simulation.

To resolve this issue, either:

• Do not use compiler options that change the default size of target data types.

• Use the single data type in Simulink rather than double, if your aim is to treat double-precision floating-point types (8 bytes) as single-precision floating-point types (4 bytes).

Other Feature Support

Back to Top

Programmatic Code Generation Verification

Code Coverage

Related Products & Applications

• Simulink
• Control Design
• Signal Processing & Communications
• Model-Based Design
• Physical Modeling
• Verification & Validation

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit