Embedded IDE Link™ CC

Using Processor in the Loop

Processor in the loop provides one powerful verification capability in your development process. This section discusses the following PIL topics:

Processor-in-the-Loop Overview

Processor-in-the-loop (PIL) cosimulation is a technique designed to help you evaluate how well a candidate algorithm, such as a control system, operates on the actual processor selected for the application.

The term cosimulation reflects a division of labor in which Simulink software models the plant, while code generated from the controller subsystem runs on the actual processor hardware.

During the Real-Time Workshop Embedded Coder software code generation process, you can create a PIL block from one of several Simulink software components including a model, a subsystem in a model, or subsystem in a library. You then place the generated PIL block inside a Simulink software model that serves as the test harness and run tests to evaluate the processor-specific code execution behavior.

Why Use Cosimulation?

PIL cosimulation is particularly useful for simulating, testing, and validating a controller algorithm in a system comprising a plant and a controller. In a classic closed-loop simulation, Simulink software and Stateflow^® model such a system as two subsystems with the signals transmitted between them, as shown in the following block diagram.

Your starting point in developing a plant/controller system is to model the system as two subsystems in closed-loop simulation. As your design progresses, you can use Simulink software external mode with standard Real-Time Workshop software processors (such as GRT or ERT) to help you model the control system separately from the plant.

However, these simulation techniques do not help you account for restrictions and requirements imposed by the hardware, such as limited memory resources, or behavior of processor-specific optimized code. When you finally reach the stage of deploying controller code on the processor hardware, you may need to make extensive adjustments to the controller system. After you make these adjustments, your deployed system may diverge significantly from the original model. Such discrepancies can create difficulties if you need to return to the original model and change it.

PIL cosimulation addresses these issues by providing an intermediate stage between simulation and deployment. In a PIL cosimulation, the processor participates fully in the simulation loop — hence the term processor-in-the-loop.

Definitions

PIL Algorithm

The algorithmic code, such as the control algorithm, to be tested during the PIL cosimulation. The PIL algorithm resides in compiled object form to allow verification at the object level.

PIL Application

The executable application to run on the processor platform. The PIL application is created by linking the PIL algorithm object code with some wrapper code (or test harness) that provides an execution framework that interfaces to the PIL algorithm.

The wrapper code includes the string.h header file so that the memcpy function is available to the PIL application. The PIL application uses memcpy to facilitate data exchange between Simulink software and the cosimulation processor.

Note   Whether the PIL algorithm code under test uses string.h is independent of the use of string.h by the wrapper code. It depends entirely on the implementation of the algorithm in the generated code.

How Cosimulation Works

In a PIL cosimulation, Real-Time Workshop software generates an executable application for the PIL algorithm. This code runs (in simulated time) on a processor platform. The plant model remains in Simulink software without the use of code generation.

During PIL cosimulation, Simulink software simulates the plant model for one sample interval and exports the output signals (ontn of the plant) to the processor platform via Code Composer Studio software. When the processor platform receives signals from the plant model, it executes the PIL algorithm for one sample step. The PIL algorithm returns its output signals (ontn of the algorithm) computed during this step to Simulink software in inn, via the CCS interface. At this point, one sample cycle of the simulation is complete and the plant model proceeds to the next sample interval. The process repeats and the simulation progresses.

PIL tests do not run in real time. After each sample period, the simulation halts to ensure that all data has been exchanged between the Simulink software test harness and object code. You can then check functional differences between the model and generated code.

Back to Top

PIL Block

The PIL cosimulation block is the Simulink software block interface to PIL and the interface between the Simulink software plant model and the executable application running on the processor. The Simulink software inputs and outputs of the PIL cosimulation block are configured to match the input and output specification of the PIL algorithm.

The block is a basic building block that enables you to perform these operations:

• Select a PIL algorithm

• Build and download a PIL application

• Run a PIL cosimulation

The PIL block inherits the shape and signal names from the parent subsystem, like those in the following example. This inheritance feature is convenient for copying the PIL block into the model to replace the original subsystem for cosimulation.

Back to Top

PIL Issues

• Data Types Must Be The Same Size on the Host and Processor

• Buses and MUX Signals Not Supported at PIL Component Boundary

• Signals with Custom Storage Classes Not Supported at PIL Component Boundary

• Continuous Sample Times Not Supported

• PIL with DSP/BIOS Enabled Does Not Support System Stack Profiling

• Real-Time Workshop grt.tlc-Based Targets Not Supported

Consider the following issues when you work with PIL blocks.

Data Types Must Be The Same Size on the Host and Processor

Only data types with the same size on the host and processor are supported 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 in MATLAB software is the same as the data type size on the processor.

• For Boolean, uint8, and int8, the size is 8 bits on the processor and in MATLAB software.

• For uint16 and int16, the size is 16 bits on processor and in MATLAB software.

• For uint32 and int32, the size is 32 bits on the processor and in MATLAB software.

• For single, the size is 32 bits on the processor and in MATLAB software.

• For double, the size is 64 bits on the processor and in MATLAB software.

For example, on C2000 processors, the boolean, uint8, and int8 MATLAB data types are not supported because the microcontroller uses 16–bit addressable words. No 8–bit data types.

To avoid data type problems, do not use the example data types in your model because the data type on the processor does not match the built-in MATLAB software data type.

Buses and MUX Signals Not Supported at PIL Component Boundary

Buses and MUX Signals are not supported at the PIL component boundary.

There is no resolution for this issue.

Signals with Custom Storage Classes Not Supported at PIL Component Boundary

Signals with Custom Storage Classes are not supported at the PIL component boundary.

There is no resolution for this issue.

PIL does support the standard storage classes, such as ExportedGlobal.

Continuous Sample Times Not Supported

Continuous sample times are not supported by PIL. If you encounter this you see the following error:

??? Processor-in-the-Loop (PIL) does not support continuous
time. Please uncheck "continuous time" in the RTW Interface
configuration set options or disable PIL.

You must use discrete sample times in your model configuration parameters when you use PIL.

PIL with DSP/BIOS Enabled Does Not Support System Stack Profiling

With DSP/BIOS enabled, the stack profiling option is disabled. To use stack profiling with PIL, disable DSP/BIOS™ in the model Target Preferences block and rebuild your project.

Real-Time Workshop grt.tlc-Based Targets Not Supported

Real-Time Workshop grt.tlc-based targets are not supported for PIL.

To use PIL, select the ccslink_ert.tlc target file provided by Real-Time Workshop Embedded Coder software.

Back to Top

Creating and Using PIL Blocks

Using PIL and PIL blocks to verify your processes begins with a Simulink model of your process. To see an example of one such model used to implement PIL, refer to the demo Comparing Simulation and processor Implementation with Processor-in-the Loop (PIL) (pilsumdiffdemo.mdl) in the demos for Embedded IDE Link CC.

To create and use a PIL block, perform the following tasks:

1. Develop the model of the process to simulate.

   Use Simulink software to build a model of the process to simulate. The blocks in the library ccslinklib can help you set up the timing and scheduling for your model.

   For information about building Simulink software models, refer to Getting Started with Simulink in the online Help system.

2. Convert your process to a masked subsystem in your model.

   For information about how to convert your process to a subsystem, refer to Creating Subsystems in Using Simulink or in the online Help system.

3. Open the new masked subsystem and add a Target Preferences block to the subsystem.

   The block library ccslinklib contains the Target Preferences block to add to your system. Configure the Target Preferences block for your processor. For details about the options on the Target Preferences block, refer to the Target Preferences block reference in the online Help system.

4. Configure your model to enable it to generate PIL algorithm code and a PIL block from your subsystem.

   1. From the model menu bar, go to Simulation > Configuration Parameters in your model to open the Configuration Parameters dialog box.

   2. Choose Real-Time Workshop from the Select tree. Set the configuration parameters for your model as required by Embedded IDE Link CC software. Get more information about setting the Real-Time Workshop software parameters in Setting Real-Time Workshop Software Parameters for TI Processors in the online Help system.

   3. Under Target selection, set the System target file to ccslink_ert.tlc (PIL requires Real-Time Workshop Embedded Coder software).

5. Configure the model to perform PIL building and PIL block creation.

   1. Select Embedded IDE Link CC on the Select tree.

   2. On the Build actionlist, select Create_processor_in_the_loop_project to enable PIL.

   3. From PIL block action

      , select Create_PIL_block_build_and_download from the list.

   4. Click OK to close the Configuration Parameters dialog box.

6. To create the PIL block, right-click the masked subsystem in your model and select Real-Time Workshop > Build Subsystem from the context menu.

   A new model window opens and the new PIL block appears in it.

   This step builds the PIL algorithm object code and a PIL block that corresponds to the subsystem, with the same inputs and outputs. Follow the progress of the build process in the MATLAB command window.

7. Copy the new PIL block from the new model to your model, either in parallel to your masked subsystem to cosimulate the processes, or replace your subsystem with the PIL block.

   To see the PIL block used in parallel to a masked subsystem, refer to the demo Comparing Simulation and Target Implementation with Processor-in-the Loop (PIL) (pilsumdiffdemo.mdl) in the demos for Embedded IDE Link CC software.

8. Click Simulation > Start to run the PIL simulation and view the results.

Back to Top

What Is Verification?

Real-Time Execution Profiling