If Action Subsystem

Subsystem whose execution is enabled by If block

• Library:

• Simulink / Ports & Subsystems

• 

Description

The If Action Subsystem block is a Subsystem block preconfigured as a starting point for creating a subsystem whose execution is controlled by an If block. The If block evaluates a logical expression and then, depending on the result of the evaluation, outputs an action signal. Execution of the subsystem is controlled by an Action Port block placed inside the subsystem.

Simulink^® ignores a priority set on an If Action Subsystem block. Instead, set the priority on the If block that initiates execution of the subsystem.

Merge signals from If Action Subsystem blocks

This example shows how to merge signals controlled by an If block. The If block selects the execution of an If Action Subsystem block from a set of subsystems. Regardless of which subsystem the If block selects, you can create a single signal with a Merge block. To open the model, see ex_if_block.

All blocks in an If Action Subsystem block must execute at the same rate as the driving If block. You can satisfy this requirement by setting the sample time parameter for each block to either inherited (-1) or the same value as the If block sample time.

Support for Fixed-Point Data Type

The If block does not directly support fixed-point data types. However, you can use the Compare To Constant block to work around this limitation.

Consider the following floating-point model without fixed-point data types. To open model, see ex_if_block_floating_point.

In this model, the If Action Subsystem blocks use their default configurations. The simulation parameters are set to their default values except for the parameters listed in the following table.

Configuration Parameter Pane	Parameter	Setting
Solver	Start time	0.0
	Stop time	1.0
	Type	Fixed-step
	Solver	discrete (no continuous states)
	Fixed-step size	0.1

The block parameters are set to their default values except for the parameters listed in the following table.

Block	Parameter	Setting
Repeating Sequence Stair	Vector of output values	[-2 -1 1 2].'
Repeating Sequence Stair1	Vector of output values	[0 0 0 0 1 1 1 1].'
If	Number of inputs	2
	If expression	(u1 > 0) | (u2 > 0.5)
	Show else condition	Selected
Constant	Constant value	-4
Constant1	Constant value	4
Scope	Number of axes	3
	Time range	1

For this model, when input u1 is greater than 0 or input u2 is greater than 0.5, the output is 4. Otherwise, the output is -4. The Scope block displays the output from the Merge block with inputs u1, and u2.

You can implement this block diagram as a model with fixed-point data types. To open model, see ex_if_block_fixed_point.

The Repeating Sequence Stair blocks output fixed-point data types.

The Compare To Constant blocks implement two parts of the If expression that is used in the If block in the floating-point version of the model, (u1 > 0) and (u2 > 0.5). The OR operation, (u1|u2), can still be implemented inside the If block. For a fixed-point model, the expression must be partially implemented outside of the If block as it is in this model.

The block and simulation parameters for the fixed-point model are the same as for the floating-point model with the following exceptions and additions:

Block	Parameter	Setting
Compare To Constant	Operator	>
	Constant value	0
	Output data type mode	Boolean
	Enable zero-crossing detection	off
Compare To Constant1	Operator	>
	Constant value	0.5
	Output data type mode	Boolean
	Enable zero-crossing detection	off
If	Number of inputs	2
	If expression	u1|u2

Ports

Input

In — Signal input to a subsystem block

scalar | vector | matrix

Placing an Inport block in a subsystem block adds an external input port to the block. The port label matches the name of the Inport block.

Use Inport blocks to get signals from the local environment.

Data Types: half | single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | fixed point | enumerated | bus

Action — Control signal input to a subsystem block

scalar | vector | matrix

Placing an Action Port block in a subsystem block adds an external input port to the block and changes the block to an If Action Subsystem.

Dot-dash lines from a Switch Case block to an Switch Case Action Subsystem block represent action signals. An action signal is a control signal connected to the action port of a Switch Case Action Subsystem block. A message on the action signal initiates execution of the subsystem.

Data Types: action

Output

Out — Signal output from a subsystem

scalar | vector | matrix

Placing an Outport block in a subsystem block adds an output port from the block. The port label on the subsystem block is the name of the Outport block.

Use Outport blocks to send signals to the local environment.

Data Types: half | single | double | int8 | int16 | int32 | int64 | uint8 | uint16 | uint32 | uint64 | Boolean | fixed point | enumerated | bus

Model Examples

Simulink Subsystem Semantics

This set of examples shows different types of Simulink® Subsystems and what semantics are used when simulating these Subsystems. Each example provides a description of the model and the subtleties governing how it will be executed.

Open Model

If-Then-Else Blocks

The effect of feeding a sine wave into If Action Subsystem blocks. It is designed to illustrate the similarity between the If Action Subsystem block and the Enabled Subsystem block.

Open Model

Modeling Clutch Lock-Up Using If Blocks

Use If/Else subsystems to build a clutch model. An 'If' subsystem models the clutch dynamics in the locked position while an 'Else' subsystem models the unlocked position. One or the other is enabled using the 'If' block. The dot-dashed lines from the 'If' block denote control signals, which are used to enable If/Else (or other conditional) subsystems. Checking any of the boxes on the GUI produces a plot of any of the selected variables (versus time).

Open Model

Block Characteristics

Data Types	Booleana | busa | doublea | enumerateda | fixed pointa | halfa | integera | singlea | stringa
Direct Feedthrough	no
Multidimensional Signals	yesa
Variable-Size Signals	yesa
Zero-Crossing Detection	no
a Actual data type or capability support depends on block implementation.

Extended Capabilities

C/C++ Code Generation

Generate C and C++ code using Simulink® Coder™.

Actual code generation support depends on block implementation.

HDL Code Generation

Generate Verilog and VHDL code for FPGA and ASIC designs using HDL Coder™.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

Architecture	Description
Module (default)	Generate code for the subsystem and the blocks within the subsystem.
BlackBox	Generate a black box interface. The generated HDL code includes only the input/output port definitions for the subsystem. Therefore, you can use a subsystem in your model to generate an interface to existing, manually written HDL code. The black-box interface generation for subsystems is similar to the Model block interface generation without the clock signals.
No HDL	Remove the subsystem from the generated code. You can use the subsystem in simulation, however, treat it as a “no-op” in the HDL code.

HDL Block Properties

General
AdaptivePipelining	Automatic pipeline insertion based on the synthesis tool, target frequency, and multiplier word-lengths. The default is inherit. See also AdaptivePipelining (HDL Coder).
BalanceDelays	Detects introduction of new delays along one path and inserts matching delays on the other paths. The default is inherit. See also BalanceDelays (HDL Coder).
ClockRatePipelining	Insert pipeline registers at a faster clock rate instead of the slower data rate. The default is inherit. See also ClockRatePipelining (HDL Coder).
ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays within your design. Distributed pipelining does not redistribute these registers. The default is 0. For more details, see ConstrainedOutputPipeline (HDL Coder).
DistributedPipelining	Pipeline register distribution, or register retiming. The default is inherit. See also DistributedPipelining (HDL Coder).
DSPStyle	Synthesis attributes for multiplier mapping. The default is none. See also DSPStyle (HDL Coder).
FlattenHierarchy	Remove subsystem hierarchy from generated HDL code. The default is inherit. See also FlattenHierarchy (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see OutputPipeline (HDL Coder).
SharingFactor	Number of functionally equivalent resources to map to a single shared resource. The default is 0. See also Resource Sharing (HDL Coder).
StreamingFactor	Number of parallel data paths, or vectors, that are time multiplexed to transform into serial, scalar data paths. The default is 0, which implements fully parallel data paths. See also Streaming (HDL Coder).

Target Specification

This block cannot be the DUT, so the block property settings in the Target Specification tab are ignored.

Restrictions

If the output of the subsystem is a bus then Initial condition of the outport must be 0.

Fixed-Point Conversion

Design and simulate fixed-point systems using Fixed-Point Designer™.

Actual data type support depends on block implementation.

Version History

Introduced before R2006a