Notes for Working on TargetLink® Models
TargetLink models can also be edited using MoRe. Some actions are specialized for TargetLink, i.e. they may behave differently for TargetLink parts of the model compared to pure Simulink® parts of the model. These special features are explained below. In addition, some actions have limitations on TargetLink models, which is also explained below.
Contents
Use of TargetLink Port Blocks
Many actions of MoRe create port blocks. For certain subsystems within a TargetLink subsystem, the Modeling Guidelines for dSPACE recommend the use of TargetLink port blocks instead of normal Simulink port blocks. MoRe complies with the guidelines and uses TargetLink port blocks if:
- The subsystem is a TargetLink subsystem,
- The subsystem is a TargetLink function subsystem with enabled incremental code generation, or
- The subsystem is a TargetLink function subsystem with enabled function reuse.
In addition to the guideline-compliant behavior described above, TargetLink port blocks are used if the subsystem already contains this type of blocks.
Consistency of TargetLink Simulation Frame
The TargetLink simulation frame consists of the two technical subsystems above the TargetLink subsystem that are required for the correct SIL/PIL simulation of the TargetLink subsystem.
These layers must not be edited manually in the editor, but TargetLink itself uses callbacks to ensure that the simulation frame remains consistent. For example, if you add a TargetLink port block to a TargetLink subsystem, the corresponding port blocks are automatically added to the simulation frame and connected correctly.
The actions of MoRe also ensure the consistency of the simulation frame. MoRe never edits the simulation frame directly, but calls the corresponding TargetLink function, which updates the simulation frame. This is only done when necessary, i.e. when TargetLink port blocks have been added to or removed from the TargetLink subsystem. If MoRe actions route signals into or out of the simulation frame, the signals within the frame are also created automatically by the corresponding TargetLink function.
Limitations When Working with TargetLink Models
Working within a TargetLink subsystem is 100% supported by MoRe. When working beyond the boundaries of a TargetLink subsystem, there are some limitations that are explained below:
- Remove Cross-Hierarchy Signal Forward: If a cross-hierarchy signal is removed that goes into an inport of a TargetLink simulation frame block, the removal is stopped at this inport. If a cross-hierarchy signal is removed that goes into an outport block of a TargetLink subsystem with simulation frame, the removal is stopped at this outport block.
- Remove Cross-Hierarchy Signal Backward: If you want to delete a cross-hierarchy signal coming from the outport of a TargetLink simulation frame block, the signal can only be deleted backward up to this outport at most. If you want to delete a cross-hierarchy signal coming from the inport block of a TargetLink subsystem with a simulation frame, the signal can only be deleted backward up to this inport block at most.
- Move Blocks Up: The action is disabled if the current subsystem is a TargetLink subsystem with a simulation frame.
- Move Blocks Down: TargetLink simulation frame subsystems are excluded from the list of possible target subsystems.
- Break Subsystem: The action is disabled if the selected block is a TargetLink simulation frame block.
- Split Subsystem: The action is disabled if the current subsystem is a TargetLink subsystem with a simulation frame.
- Merge Subsystems: The action is disabled if one of the selected blocks is a TargetLink simulation frame block.
- Insert Subsystem Inport/Outport Above/Below: The action is disabled if the destination/source block of the selected line is a TargetLink simulation frame block.
- Move Interface: The action is disabled if the selected block is a TargetLink simulation frame block.