3 Simulink Gui
3 Simulink Gui
R2024b
How to Contact MathWorks
Phone: 508-647-7000
Solver Parameters
3
Solver Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2
Diagnostics Parameters
6
Model Configuration Parameters: Diagnostics . . . . . . . . . . . . . . . . . . . . . . 6-2
v
Diagnostics Parameters: Sample Time
7
Model Configuration Parameters: Sample Time Diagnostics . . . . . . . . . . 7-2
vi Contents
Unspecified inheritability of sample time . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-16
vii
Wrap on overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
viii Contents
Detect precision loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-32
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-33
ix
Diagnostics Parameters: Connectivity
10
Model Configuration Parameters: Connectivity Diagnostics . . . . . . . . . . 10-2
x Contents
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
xi
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32
xii Contents
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-44
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-44
xiii
Model Referencing Parameters
15
Model Configuration Parameters: Model Referencing . . . . . . . . . . . . . . . 15-2
Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7
xiv Contents
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18
Defines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19
xv
Default function array layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
xvi Contents
Simulink Preferences Window
18
Font Styles for Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
Font Styles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
Specify Data Types for an Edit Parameter Using Data Type Parameter
........................................................ 19-35
xvii
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5
Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
xviii Contents
Install Variant Manager for Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
Open Variant Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-4
Explore Variant Manager Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-5
Manage Variant Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-6
Manage Variant Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-13
Reduce a Variant Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-16
Analyze Variant Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-17
Icons in Variant Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-17
Access the Variant Manager Functionality Programmatically . . . . . . . . 21-23
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-23
xix
1
In the Model Explorer you can edit the name and description of your configuration sets.
In the Model Explorer or Simulink Preferences window you can edit the description of your template
configuration set, Model Configuration Preferences. Go to the Model Configuration Preferences to
edit the template Configuration Parameters to be used as defaults for new models.
When editing the Model Configuration preferences, you can click Restore to Default Preferences
to restore the default configuration settings for creating new models. These underlying defaults
cannot be changed.
For more information about configuration sets, see “Manage Configuration Sets for a Model”.
Name
Settings
In the Model Configuration Preferences, the name of the default configuration is always
Configuration Preferences, and cannot be changed.
Description
Settings
No Default
1-2
Model Configuration Pane
Configuration Parameters
1-3
2
Description
The Test hardware is the same as production hardware parameter specifies whether the
hardware you use to test the code generated from the model is the same or has the same
characteristics as the production hardware on which the code will run. When the test and production
hardware differ, clear this parameter to generate additional code that emulates the production
hardware on the test hardware.
Settings
on (default) | off
on
Selecting this parameter indicates that the hardware you use to test the code you generate from
the model is the same as or has the same characteristics as the production hardware on which
the generated code will run.
off
Clearing this parameter indicates that the hardware you use to test the code you generate from
the model is not the same or has different characteristics from the production hardware.
When you clear this parameter, the software generates additional code to emulate the production
hardware on the test hardware.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution On
Programmatic Use
Parameter: ProdEqTarget
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2006b
2-2
Test hardware is the same as production hardware
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-3
2 Simulink Configuration Parameters: Advanced
Description
The Device vendor and Device type parameters specify the manufacturer and type of the hardware
used to test the code generated from the model.
Dependencies
The Device vendor and Device type parameter values reflect available device support for the
selected hardware board.
Menu options that are available depend on the Device vendor parameter setting.
With the exception of device vendor ASIC/FPGA, selecting a device type sets these parameters:
Whether you can modify the value of a device-specific parameter varies according to device type.
Settings
Intel, x86–64 (Windows64) | ...
2-4
Test device vendor and type
• AMD
• ARM Compatible
• Altera
• Analog Devices
• Apple
• Atmel
• Freescale
• Infineon
• Intel
• Microchip
• NXP
• Renesas
• STMicroelectronics
• Texas Instruments
• ASIC/FPGA
• Custom Processor
Then, select the device type. The available device types change depending on the device vendor
selected. If your hardware does not match one of the listed types, select Custom.
AMD® options:
• Athlon 64
• K5/K6/Athlon
• x86–32 (Windows 32)
• x86–64 (Linux 64)
• x86–64 (macOS)
• x86–64 (Windows64)
ARM® options:
• ARM 10
• ARM 11
• ARM 64-bit (LLP64)
• ARM 64-bit (LP64)
• ARM 7
• ARM 8
• ARM 9
• ARM Cortex-A (32-bit)
• ARM Cortex-A (64-bit)
• ARM Cortex-M
• ARM Cortex-R
Altera® options:
2-5
2 Simulink Configuration Parameters: Advanced
Apple options:
• ARM64
Atmel® options:
• AVR
• AVR (32-bit)
• AVR (8-bit)
Freescale® options:
• 32-bit PowerPC
• 68332
• 68HC08
• 68HC11
• ColdFire
• DSP563xx (16-bit mode)
• HC(S)12
• MPC52xx
• MPC5500
• MPC55xx
• MPC5xx
• MPC7xxx
• MPC82xx
• MPC83xx
• MPC85xx
• MPC86xx
• MPC8xx
• S08
• S12x
• StarCore
Infineon® options:
• C16x, XC16x
2-6
Test device vendor and type
• TriCore
Intel® options:
• x86–32 (Windows32)
• x86–64 (Linux 64)
• x86–64 (macOS)
• x86–64 (Windows64)
Microchip options:
• PIC18
• dsPIC
NXP options:
• Cortex—M0/M0+
• Cortex—M3
• Cortex—M4
Renesas® options:
• M16C
• M32C
• R8C/Tiny
• RH850
• RL78
• RX
• RZ
• SH-2/3/4
• V850
STMicroelectronics®:
• ST10/Super10
• C2000
• C5000
• C6000
• MSP430
• Stellaris Cortex—M3
• TMS470
• TMS570 Cortex—R4
ASIC/FPGA options:
2-7
2 Simulink Configuration Parameters: Advanced
• ASIC/FPGA
Selecting a device type specifies the hardware device to define system constraints:
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
AMD
Athlon 64 8 16 3 64 64 64 64 64 64 Cha None Littl Zero ✓ □
2 r e
Endia
n
K5/K6/ 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
Athlon 2 r e
Endia
n
x86–32 8 16 3 32 64 32 32 32 32 Cha Floa Littl Zero ✓ □
(Windows3 2 r t e
2) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Linux 2 r t e
64) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(macOS) 2 r t e
Endia
n
x86–64 8 16 3 32 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Windows6 2 r t e
4) Endia
n
ARM Compatible
2-8
Test device vendor and type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
ARM 8 16 3 32 64 32 32 32 32 Lon Floa Littl Zero ✓ □
7/8/9/10 2 g t e
Endia
n
ARM 11 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
ARM 64- 8 16 3 64 64 64 64 64 64 Lon Doub Littl Zero ✓ ✓
bit 2 g le e
(LP64) Endia
n
ARM 64- 8 16 3 32 64 64 64 64 64 Lon Doub Littl Zero ✓ ✓
bit 2 g le e
(LLP64) Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-A 2 g le e
(32-bit) Endia
n
ARM 8 16 3 64 64 32 64 64 64 Lon Doub Littl Zero ✓ ✓
Cortex-A 2 gLo le e
(64-bit) ng Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-M 2 g le e
Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-R 2 g le e
Endia
n
Altera
2-9
2 Simulink Configuration Parameters: Advanced
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
SoC (ARM 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
Cortex A) 2 r e
Endia
n
Analog Devices
ADSP- 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
CM40x(ARM 2 g le e
Cortex-M) Endia
n
Blackfin 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
SHARC 32 32 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
2 g le Endia
n
TigerSHAR 32 32 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
C 2 g le e
Endia
n
Apple
ARM64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
2 r t e
Endia
n
Atmel
AVR 8 16 1 32 64 8 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
AVR (32- 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
bit) 2 r e
Endia
n
2-10
Test device vendor and type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
AVR (8- 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
bit) 6 r e
Endia
n
Freescale
32-bit 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
PowerPC 2 g le Endia
n
68332 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
68HC08 8 16 1 32 64 8 8 16 8 Cha None Big Zero ✓ □
6 r Endia
n
68HC11 8 16 1 32 64 8 8 16 16 Cha None Big Zero ✓ □
6 r Endia
n
ColdFire 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
DSP563xx 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
(16-bit 6 r e
mode) Endia
n
DSP5685x 8 16 1 32 64 16 16 16 16 Cha Floa Littl Zero ✓ □
6 r t e
Endia
n
HC(S)12 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
2-11
2 Simulink Configuration Parameters: Advanced
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
MPC52xx, 8 16 3 32 64 32 32 32 32 Lon None Big Zero ✓ □
MPC5500, 2 g Endia
MPC55xx, n
MPC5xx,
PC5xx,
MPC7xxx,
MPC82xx,
MPC83xx,
MPC86xx,
MPC8xx
MPC85xx 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
2 g le Endia
n
S08 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
S12x 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
StarCore 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
Infineon
C16x, 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
XC16x 6 r e
Endia
n
TriCore 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
Intel
2-12
Test device vendor and type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
x86–32 8 16 3 32 64 32 32 32 32 Cha Floa Littl Zero ✓ □
(Windows3 2 r t e
2) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Linux 2 r t e
64) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(macOS) 2 r t e
Endia
n
x86–64 8 16 3 32 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Windows6 2 r t e
4) Endia
n
Microchip
PIC18 8 16 1 32 64 8 8 24 24 Cha None Littl Zero ✓ □
6 r e
Endia
n
dsPIC 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
NXP
Cortex— 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
M0/M0+ 2 g le e
Endia
n
Cortex—M3 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
2-13
2 Simulink Configuration Parameters: Advanced
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
Cortex—M4 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
Renesas
M16C 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
M32C 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
R8C/Tiny 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
RH850 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
RL78 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
RX 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
RZ 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
2-14
Test device vendor and type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
SH-2/3/4 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
V850 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
STMicroelectronics
ST10/ 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
Super10 6 r e
Endia
n
Texas Instruments
C2000 16 16 1 32 64 16 32 16 16 Int None Littl Zero ✓ □
6 e
Endia
n
C5000 16 16 1 32 64 16 16 16 16 Int None Big Zero ✓ □
6 Endia
n
C6000 8 16 3 40 64 32 32 32 32 Int None Littl Zero ✓ □
2 e
Endia
n
MSP430 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
Stellaris 8 16 3 32 6 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex—M3 2 g le e
Endia
n
2-15
2 Simulink Configuration Parameters: Advanced
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ point size ptrdif inte floati
ar rt t g g e er _t f_t ger ng-
lon point
g
TMS470 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
TMS570 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
Cortex—R4 2 g le Endia
n
ASIC/FPGA
ASIC/FPGA NA NA N NA NA NA NA NA NA NA NA NA NA NA NA
A
Tips
• Use the parameter TargetHWDeviceType to set both the Device vendor and Device type fields
programmatically. Specify the parameter value as a character vector that defines both the device
vendor and the device type, separated by the characters ->. For example, this command specifies
the device vendor as Intel and the device type as x86-64 (Linux 64).
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
2-16
Test device vendor and type
Programmatic Use
Parameter: TargetHWDeviceType
Type: string | character vector
Default:'Intel->x86–64 (Windows64)'
Version History
Introduced in R2006b
See Also
Topics
“Hardware board” on page 14-5
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-17
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: char parameter specifies the character bit length for the hardware that you
use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
8 (default) | 16 | 24 | 32
The bit length must be an integer multiple of 8 that is less than or equal to 32. Different devices have
different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerChar
Type: integer
Values: 8 | 16 | 24 | 32
Default: 8
Version History
Introduced in R2006b
2-18
Number of bits: char
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-19
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: short parameter specifies the bit length of the C short data type for the
hardware that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
16 (default) | 8 | 24 | 32
The bit length must be an integer multiple of 8 that is less than or equal to 32. Different devices have
different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerShort
Type: integer
Values: 8 | 16 | 24 32
Default: 16
Version History
Introduced in R2006b
2-20
Number of bits: short
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-21
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: int parameter specifies the bit length of the C int data type for the hardware
that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
32 (default) | 8 | 16 | 24
The bit length must be an integer multiple of 8 that is less than or equal to 32. Different devices have
different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerInt
Type: integer
Values: 8 | 16 | 24 | 32
Default: 32
Version History
Introduced in R2008a
2-22
Number of bits: int
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-23
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: long parameter specifies the bit length of the C long data type for the
hardware that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
32 (default) | 40 | 48 | 56 | 64
The bit length must be an integer multiple of 8 that is between 32 and 64, inclusive. Different devices
have different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerLong
Type: integer
Values: 32 | 40 | 48 | 56 | 64
Default: 32
Version History
Introduced in R2008a
2-24
Number of bits: long
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-25
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: long long parameter specifies the bit length of the C long long data type
that the test hardware supports.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
To enable this parameter, select Support long long.
This parameter is enabled only if you can change its value for the selected hardware. Changing the
value of this parameter is supported only for custom targets.
Settings
64 (default) | 72 | 80 | 88 | 96 | 104 | 112 | 120 | 128
Specify the number of bits that represent the C long long data type for the test hardware. The
value must be an integer multiple of 8 between 64 and 128, inclusive. Different devices have different
settings available for this parameter.
The value of this parameter must be greater than or equal to the value of Number of bits: long.
Tips
Use the long long data type only if your C compiler supports long long.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerLongLong
2-26
Number of bits: long long
Type: integer
Values: 64 | 72 | 80 | 88 | 96 | 104 | 112 | 120 | 128
Default: 64
Version History
Introduced in R2013a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-27
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: float parameter specifies the bit length of the C float data type for the
hardware that you use to test code.
This parameter is read only. The bit length for float data is always 32.
Settings
32
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerFloat
Type: integer
Values: 32 (read-only)
Default: 32
Version History
Introduced in R2010a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-28
Number of bits: double
Description
The Number of bits: double parameter specifies the bit length of the C double data type for the
hardware that you use to test code.
This parameter is read only. The bit length for double data is always 64.
Settings
64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerDouble
Type: integer
Values: 64 (read only)
Default: 64
Version History
Introduced in R2010a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-29
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: native parameter specifies the microprocessor native word size for the
hardware that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
64 (default) | 8 | 16 | 24 | 32 | 40 | 48 | 56
The native word length must be an integer multiple of 8 that is less than or equal to 64. Different
devices have different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetWordSize
Type: integer
Values: 8 | 16 | 24 | 32 | 40 | 48 | 56 | 64
Default: 64
Version History
Introduced in R2006a
2-30
Number of bits: native
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-31
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: pointer parameter specifies the bit length of pointer data for the hardware
that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
64 (default) | 8 | 16 | 24 | 32 | 40 | 48 | 56
The pointer bit length must be an integer multiple of 8 that is less than or equal to 64. Different
devices have different settings available for this parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerPointer
Type: integer
Values: 8 | 16 | 24 | 32 | 40 | 48 | 56 | 64
Default: 64
Version History
Introduced in R2010a
2-32
Number of bits: pointer
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-33
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: size_t parameter specifies the bit length of size_t data for the hardware that
you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Whether the software checks the size_t bit length for the test hardware or for the production
hardware for a processor-in-the-loop (PIL) simulation depends on whether you select Test hardware
is the same as production hardware.
• When Test hardware is the same as production hardware is selected, the software uses
size_t bit length for the test hardware, specified in the TargetBitPerSizeT parameter.
• When Test hardware is the same as production hardware is not selected, the software uses
the size_t bit length for the production hardware, specified in the ProdBitPerSizeT
parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
64 (default) | 8 | 16 | 24 | 32 | 40 | 128
The size_t bit length must be greater than or equal to the int bit length.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerSizeT
Type: integer
Values: 8 | 16 | 24 | 32 |40 | 64 | 128
2-34
Number of bits: size_t
Default: 64
Version History
Introduced in R2016b
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
“Verification of Code Generation Assumptions” (Embedded Coder)
2-35
2 Simulink Configuration Parameters: Advanced
Description
The Number of bits: ptrdiff_t parameter specifies the bit length of ptrdiff_t data for the
hardware that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Whether the software checks the ptrdiff_t bit length for the test hardware or for the production
hardware for a processor-in-the-loop (PIL) simulation depends on whether you select Test hardware
is the same as production hardware.
• When Test hardware is the same as production hardware is selected, the software uses
ptrdiff_t bit length for the test hardware, specified in the TargetBitPerPtrDiffT parameter.
• When Test hardware is the same as production hardware is not selected, the software uses
the ptrdiff_t bit length for the production hardware, specified in the ProdBitPerPtrDiffT
parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
64 (default) | 8 | 16 | 24 | 32 | 40 | 128
The ptrdiff_t bit length must be greater than or equal to the int bit length.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetBitPerPtrDiffT
Type: integer
Values: 8 | 16 | 24 | 32 |40 | 64 | 128
2-36
Number of bits: ptrdiff_t
Default: 64
Version History
Introduced in R2016b
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
“Verification of Code Generation Assumptions” (Embedded Coder)
2-37
2 Simulink Configuration Parameters: Advanced
Description
The Largest atomic size: integer parameter specifies the largest integer data type that can be
atomically loaded and stored on the hardware that you use to test code. Use this parameter, where
possible, to remove unnecessary double-buffering or unnecessary semaphore protection, based on
data size, in generated multirate code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
Char (default) | Short | Int | Long | LongLong
Char
Specifies that char is the largest integer data type that can be atomically loaded and stored on
the hardware that you use to test code.
Short
Specifies that short is the largest integer data type that can be atomically loaded and stored on
the hardware that you use to test code.
Int
Specifies that int is the largest integer data type that can be atomically loaded and stored on the
hardware that you use to test code.
Long
Specifies that long is the largest integer data type that can be atomically loaded and stored on
the hardware that you use to test code.
LongLong
Specifies that long long is the largest integer data type that can be atomically loaded and
stored on the hardware that you use to test code.
You can set this parameter value to LongLong only if the hardware used to test the code supports
the C long long data type and you have selected Enable long long.
2-38
Largest atomic size: integer
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetLargestAtomicInteger
Type: string | character vector
Values: 'Char' | 'Short' | 'Int' | 'Long' | 'LongLong'
Default: 'Char'
Version History
Introduced in R2010a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
Support long long
“Hardware Implementation Pane” on page 14-2
2-39
2 Simulink Configuration Parameters: Advanced
Description
The Largest atomic size: floating-point parameter specifies the largest floating-point data type
that can be atomically loaded and stored on the hardware that you use to test code. Use this
parameter, where possible, to remove unnecessary double-buffering or unnecessary semaphore
protection, based on data size, in generated multirate code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
Float (default) | Double | None
Float
Specifies that float is the largest floating-point data type that can be atomically loaded and
stored on the hardware that you use to test code.
Double
Specifies that double is the largest floating-point data type that can be atomically loaded and
stored on the hardware that you use to test code.
None
Specifies that there is no applicable setting or not to use this parameter in generating multirate
code.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetLargestAtomicFloat
2-40
Largest atomic size: floating-point
Version History
Introduced in R2010a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-41
2 Simulink Configuration Parameters: Advanced
Byte ordering
Byte ordering on test hardware
Description
The Byte ordering parameter specifies the endianess for the hardware that you use to test code.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
Little Endian (default) | Big Endian | Unspecified
Default:
Little Endian
The least significant byte comes first.
Big Endian
The most significant byte comes first.
Unspecified
The code determines the endianness of the hardware. This choice is the least efficient.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetEndianess
Type: string | character vector
Values: 'Unspecified' | 'LittleEndian' | 'BigEndian'
Default: 'LittleEndian'
2-42
Byte ordering
Version History
Introduced in R2006b
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-43
2 Simulink Configuration Parameters: Advanced
Description
The Signed integer division rounds to parameter specifies how the compiler for the test hardware
rounds the result of dividing two signed integers.
For information on how this option affects code generation, see Hardware Implementation Options
(Simulink Coder).
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
Zero (default) | Floor | Undefined
Zero
If the quotient is between two integers, the compiler chooses the integer that is closer to zero as
the result.
Floor
If the quotient is between two integers, the compiler chooses the integer that is closer to negative
infinity.
Undefined
Choose this option if neither Zero nor Floor describes the compiler behavior, or if that behavior
is unknown.
The table summarizes the compiler behavior that corresponds to each parameter option.
2-44
Signed integer division rounds to
Tips
• By setting the Integer rounding mode parameter for blocks in the model, you can simulate the
rounding behavior of the C compiler that you use to compile code generated from your model. The
parameter is on the Signal Attributes tab of the Block Parameters dialog box for blocks that
support signed integer arithmetic, for example, the Product block.
• For most blocks, the Integer rounding mode parameter value for the block completely specifies
the rounding behavior. For blocks that support fixed-point data types and the Simplest rounding
mode, both the Integer rounding mode parameter and the Signed integer division rounds to
parameter affect the rounding behavior. For more information, see “Rounding Modes” (Fixed-Point
Designer).
Recommended Settings
Application Setting
Debugging No impact for simulation or during development.
Undefined for production code generation.
Traceability No impact for simulation or during development.
Zero or Floor for production code generation.
Efficiency No impact for simulation or during development.
Zero for production code generation.
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetIntDivRoundTo
Type: string | character vector
Values: 'Floor' | 'Zero' | 'Undefined'
Default: 'Zero'
Version History
Introduced in R2006a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-45
2 Simulink Configuration Parameters: Advanced
Description
The Shift right on a signed integer as arithmetic shift parameter specifies whether the C
compiler for the test hardware implements a right shift of a signed integer as an arithmetic right
shift. An arithmetic right shift fills bits vacated by the right shift with the value of the most significant
bit. For signed integers that use two's-complement notation, the most significant bit indicates the
sign of the number. With this behavior, the arithmetic right shift is the equivalent of dividing the
number by two.
Most compilers implement right shifts for signed integers as arithmetic right shifts.
Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
Dependencies
This parameter is enabled only if you can modify it for the selected hardware.
Settings
on (default) | off
on
Generated code for arithmetic shifts on signed integers is simple and efficient.
off
Generated code for right arithmetic shifts is fully portable but less efficient.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetShiftRightIntArith
2-46
Shift right on a signed integer as arithmetic shift
Version History
Introduced in R2008a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
Hardware Implementation Options (Simulink Coder)
“Hardware Implementation Pane” on page 14-2
2-47
2 Simulink Configuration Parameters: Advanced
Description
The Support long long parameter specifies whether the C compiler for your test hardware supports
the C long long data type. Most C99 compilers support long long.
Settings
off (default) | on
on
The C compiler for the test hardware supports the C long long data type.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No impact when Test hardware is the same as
production hardware is selected. If it is not selected, no
recommendation.
Programmatic Use
Parameter: TargetLongLongMode
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2013a
See Also
Topics
Specifying Test Hardware Characteristics (Simulink Coder)
2-48
Support long long
2-49
2 Simulink Configuration Parameters: Advanced
Description
Use this parameter to limit the unit systems supported for the model. For example, when you specify
this parameter value as SI, only SI units are allowed in the model. By default, all unit systems are
allowed.
You can specify the allowed unit systems by typing into the text box or using the Set Allowed Unit
Systems dialog box. To open the Set Allowed Unit Systems dialog box, click Set Allowed Unit
Systems.
When you finish specifying the unit systems, click OK. The software populates the Allowed unit
systems box in the Configuration Parameters dialog box with the unit systems from the Allowed unit
systems list.
To limit unit systems at a subsystem level, see the Unit System Configuration block.
When registering custom unit databases, they appear in the list as new unit systems. For more
information on custom unit databases, see “Working with Custom Unit Databases”.
2-50
Allowed unit systems
Settings
all (default) | comma-separated list of unit systems
all
Allow use of units from all unit systems in model.
comma-separated list of unit systems
To limit the unit systems from which the model can use units, specify the parameter value as a
comma-separated list of one or more of these unit system names:
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: AllowedUnitSystems
Type: string | character vector
Values: all | comma-separated list that contains one or more of these unit system names: SI, SI
(extended), English, CGS
Default: 'all'
Version History
Introduced in R2016a
See Also
Unit System Configuration
Topics
“Unit Specification in Simulink Models”
Solver Diagnostics on page 6-2
2-51
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies whether the software issues a warning when the model contains inconsistent
units.
Settings
warning (default) | none
warning
The software issues a warning when the model contains unit inconsistencies.
none
The software does not issue a diagnostic when the model contains unit inconsistencies.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: UnitsInconsistencyMsg
Type: string | character vector
Values: 'warning' | 'none'
Default: 'warning'
Version History
Introduced in R2016a
See Also
Topics
“Unit Specification in Simulink Models”
Solver Diagnostics on page 6-2
2-52
Allow automatic unit conversions
Description
This parameter specifies whether the software automatically performs unit conversions in the model
for cases where the units to convert have a known mathematical relationship. When Simulink
successfully converts signal units at a block port, it displays .
Settings
on (default) | off
on
The software automatically converts units for cases where the units have a known mathematical
relationship. For more information, see “Converting Units”.
off
The software does not perform automatic unit conversion in the model. To convert units in the
model, use the Unit Conversion block.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: AllowAutomaticUnitConversions
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2016a
2-53
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Unit Specification in Simulink Models”
“Converting Units”
Solver Diagnostics on page 6-2
2-54
Dataset signal format
Description
Use this parameter to specify whether logged data is stored within elements of a
Simulink.SimulationData.Dataset object as timeseries objects or as timetables.
The value you specify for this parameter affects the way state, time, and output data is logged only
when the Format parameter value is Dataset.
This parameter does not effect data logged for variable-size signals or data logged using Scope
blocks. Logged data for variable-size signals is always stored in a timetable that contains a cell
array of signal values for each time step. Configure the format for logged Scope block data using the
block parameters.
The table summarizes a comparison between the timeseries and timetable objects.
2-55
2 Simulink Configuration Parameters: Advanced
output1 = out.yout{1}.Values.Data;
output1 = out.yout{1}.Values.Data;
Multidimensional data access Time aligns with the last Time always aligns with the first
dimension of data logged for dimension of data logged for
states, signals, data stores, and states, signals, and outputs. For
outputs that have two or more example, if you log data for a
dimensions, including row signal that has dimensions 3-
vectors with dimensions 1-by-n. by-2, each element in the Data
The length of the last dimension property of the timetable has
of the matrix in the Data dimensions 1-by-3-by-2.
property matches the number of
samples logged in simulation.
2-56
Dataset signal format
Settings
timeseries (default) | timetable
timeseries
Save Dataset element values in timeseries objects.
timetable
Save Dataset element values in timetable objects.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: DatasetSignalFormat
Type: string | character vector
Values: 'timeseries' | 'timetable'
Default: 'timeseries'
Version History
Introduced in R2017b
See Also
Topics
“Model Configuration Parameters: Data Import/Export” on page 4-2
“Log Data to Persistent Storage”
2-57
2 Simulink Configuration Parameters: Advanced
Description
Use this parameter to control whether data logged using To Workspace blocks streams to the
Simulation Data Inspector. By default, data logged using To Workspace blocks streams to the
Simulation Data Inspector along with logged signal data, data stores, and states and outputs logged
using the Dataset format.
When you run multiple simulations in a single MATLAB® session, the Simulation Data Inspector
retains results from each simulation so you can analyze the results together. To control the amount of
data retained in the Simulation Data Inspector, do not use this parameter. See “Limit the Size of
Logged Data”.
Settings
on (default) | off
on
Data logged using To Workspace blocks streams to the Simulation Data Inspector during
simulation.
off
Data logged using To Workspace blocks does not stream to the Simulation Data Inspector.
If you have a license for Fixed-Point Designer™, int64 and uint64 data is logged as a fi
object. If you do not have a license for Fixed-Point Designer, data is logged as double data.
• Logging data inside for-each subsystems.
• Using the Timeseries format in rapid accelerator simulations.
Recommended Settings
Application Setting
Debugging On
Traceability No recommendation
Efficiency On
Safety precaution No recommendation
2-58
Stream To Workspace blocks
Programmatic Use
Parameter: StreamToWks
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2022a
See Also
Topics
“Model Configuration Parameters: Data Import/Export” on page 4-2
“Limit the Size of Logged Data”
2-59
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies the diagnostic behavior in the software when an S-function writes to
memory locations not allocated for the block. Writing outputs, states, or work vectors outside of the
memory allocated for the block indicates a bug in the S-function. For more information, see “Handle
Errors in S-Functions”.
Setting this parameter to a value other than none degrades simulation performance. Set the
parameter value to warning or error only to debug an S-function in your model.
The software ignores this parameter for referenced models that simulate in accelerator mode. You
can use the Model Advisor to check for diagnostic parameters that are ignored for referenced models
that simulate in accelerator mode.
Settings
none (default) | warning | error
Default: none
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency none
Safety precaution No impact
Programmatic Use
Parameter: ArrayBoundsChecking
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'none'
2-60
Array bounds exceeded
Version History
Introduced in R2006a
See Also
Topics
Diagnosing Simulation Errors
Data Validity Diagnostics on page 8-2
2-61
2 Simulink Configuration Parameters: Advanced
Description
The Model Verification block enabling parameter globally enables or disables “Model Verification”
blocks, or enables them depending on the value of the Enable assertion parameter.
When you simulate models or generate code for model verification blocks in S-functions, this
parameter does not apply.
Settings
Use local settings (default) | Enable All | Disable All
Tips
• To programmatically modify this parameter, use the get_param function on the model.
• To programmatically retrieve the value of this parameter, use the set_param function on the
model.
• If you set this parameter to Enable All or Disable All, the model verification block icon
indicates whether the block is enabled or disabled. For example, the block icon of a Check
Dynamic Gap block is crossed out when this parameter is Disable All.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution EnableAll for simulation or during development
2-62
Model Verification block enabling
Programmatic Use
Parameter: AssertControl
Type: string | character vector
Values: 'UseLocalSettings' | 'EnableAll' | 'DisableAll'
Default: 'UseLocalSettings'
Version History
Introduced in R2006a
See Also
Topics
Diagnosing Simulation Errors
Data Validity Diagnostics on page 8-2
2-63
2 Simulink Configuration Parameters: Advanced
Description
Globally or locally enable parameter validation for Parameter Writer blocks in the current model.
When parameter validation is disabled for a Paramer Writer block, normal mode simulation of the
block is faster.
Dependencies
To disable parameter validation for Parameter Writer blocks, the blocks must not directly or indirectly
change the values of Model block instance parameters. For example, a Parameter Writer block must
not change the value of a model workspace variable or mask parameter that specifies the value of a
Model block instance parameter.
Settings
Use local settings (default) | Enable all | Disable all
Enable all
The software enables parameter validation for all Parameter Writer blocks in the model,
regardless of the settings of their Validate parameter parameters.
Disable all
The software disables parameter validation for all Parameter Writer blocks in the model,
regardless of the settings of their Validate parameter parameters.
Recommended Settings
Application Setting
Debugging No recommendation.
Traceability No recommendation.
Efficiency For normal mode simulation, Disable all.
Safety precaution No recommendation.
2-64
Parameter Writer block validation
Programmatic Use
Parameter: ParamWriterValidationControl
Values: 'uselocalsettings' | 'enableall' | 'disableall'
Default: 'uselocalsettings'
Version History
Introduced in R2023a
See Also
Parameter Writer
Topics
“Model Configuration Parameters: Data Validity” on page 8-2
2-65
2 Simulink Configuration Parameters: Advanced
Description
The Check undefined subsystem initial output parameter specifies whether the software issues a
warning when a model contains a conditionally executed subsystem that has an undefined initial
output value. An initial output value is undefined when a block that has a specified initial condition
drives an Outport block that has an undefined initial condition (Initial Output parameter is set to
[]). For more information, see “Initial output”.
Dependencies
To enable this parameter, set Underspecified initialization detection to Classic.
Settings
on (default) | off
on
The software issues a warning if the model contains a conditionally executed subsystem in which
a block that has a specified initial condition drives an Outport block with an undefined initial
condition.
off
The software does not issue a warning if the model contains a conditionally executed subsystem
in which a block that has a specified initial condition drives an Outport block with a defined initial
condition.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution On
Programmatic Use
Parameter: CheckSSInitialOutputMsg
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
2-66
Check undefined subsystem initial output
Version History
Introduced in R2008b
See Also
Topics
Diagnosing Simulation Errors
“Conditionally Executed Subsystems and Models”
Underspecified initialization detection
“Model Configuration Parameters: Diagnostics” on page 6-2
2-67
2 Simulink Configuration Parameters: Advanced
Description
The Detect multiple driving blocks executing at the same time step parameter specifies the
diagnostic action when a model does not explicitly define the execution order for blocks that drive the
same Merge block at the same time step. Connecting blocks that execute in the same time step to the
same Merge block can lead to inconsistent results in simulation and in generated code unless the
model explicitly defines the execution order of the driving blocks.
To explicitly define the execution order of the driving blocks, use a function-call initiator block, such
as a Stateflow® Chart or a MATLAB Function block.
This diagnostic does not detect this condition in referenced models. For example, suppose a test
harness model references the system under test using a Model block. This diagnostic does not detect
whether model for the system under test contains a Merge block driven by multiple blocks that
execute in the same time step.
Settings
error (default) | warning | none
error
The software issues an error and terminates the simulation only if the execution order of the
blocks that execute in the same time step is not explicitly defined.
Use this parameter value to avoid inconsistent results in simulation and generated code.
warning
The software issues a warning when multiple blocks that drive the same Merge block execute in
the same time step.
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging error
Traceability error
Efficiency No impact
Safety precaution error
2-68
Detect multiple driving blocks executing at the same time step
Programmatic Use
Parameter: MergeDetectMultiDrivingBlocksExec
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced in R2008b
See Also
Merge
Topics
Diagnosing Simulation Errors
“Check usage of Merge blocks”
Underspecified initialization detection
Data Validity Diagnostics on page 8-2
2-69
2 Simulink Configuration Parameters: Advanced
Description
The Unspecified initialization detection parameter specifies how the software determines the
initial conditions for blocks that have underspecified initial conditions. The software determines the
initial condition for conditionally executed subsystems, Merge blocks, subsystem elapsed time, and
Discrete-Time Integrator blocks when the model does not fully specify the initial conditions.
Settings
Simplified (default) | Classic
Simplified
The software determines initial conditions using an enhanced algorithm that can improve the
consistency of simulation results, especially in models that:
To update your model to use the simplified initialization mode, run these Model Advisor
checks:
For more information, see “Convert from Classic to Simplified Initialization Mode”.
Classic
The software determines initial conditions the same way it does for versions prior to R2008b.
Recommended Settings
Application Setting
Debugging Simplified
Traceability Simplified
Efficiency Simplified
2-70
Underspecified initialization detection
Application Setting
Safety precaution Simplified
Programmatic Use
Parameter: UnderspecifiedInitializationDetection
Type: string | character vector
Values: 'Classic' | 'Simplified'
Default: 'Simplified'
Version History
Introduced in R2008b
See Also
Merge | Discrete-Time Integrator
Topics
“Convert from Classic to Simplified Initialization Mode”
“Conditional Subsystem Initial Output Values”
“Conditionally Executed Subsystems and Models”
“Simplified Initialization Mode”
“Classic Initialization Mode”
“Conditional Subsystem Output Values When Disabled”
Diagnosing Simulation Errors
Data Validity Diagnostics on page 8-2
2-71
2 Simulink Configuration Parameters: Advanced
Description
The Solver data inconsistency configuration parameter specifies the diagnostic action the software
takes when an S-function that has continuous sample time produces inconsistent results. This
diagnostic validates assumptions of ODE solvers.
• Custom S-functions adhere to the same rules that built in blocks do.
• Blocks produce consistent output values for the same value of time.
Warning Setting this parameter to a value other than none can significantly degrade simulation
performance.
Solvers save output, zero-crossing, derivative, and state values calculated in each time step for use in
the calculations for the next time step. When you enable consistency checking by setting this
parameter value to warning or error, the solver recomputes the output, zero-crossing, derivative,
and state values to compare them to the values saved from the previous time step. If the recalculated
values do not match the values from the previous time step, the software issues a diagnostic.
Settings
none (default) | warning | error
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging warning
Traceability No impact
Efficiency none
2-72
Solver data inconsistency
Application Setting
Safety precaution No impact
Programmatic Use
Parameter:ConsistencyChecking
Type: string | character vector
Values: "none" | "warning" | "error"
Default: "none"
Version History
Introduced in R2006a
See Also
Topics
Diagnosing Simulation Errors
Choosing a Solver
Solver Diagnostics on page 6-2
2-73
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies the diagnostic behavior when the software determines that zero crossings in
the model are ignored during simulation.
Settings
none (default) | warning | error
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency none
Safety precaution No impact
Programmatic Use
Parameter:IgnoredZcDiagnostic
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2010a
See Also
Topics
Solver Diagnostics on page 6-2
2-74
Masked zero crossings
Description
The Masked zero crossings configuration parameter specifies the diagnostic action for the software
to take when zero crossings are being masked.
Dependencies
To enable this parameter, set the solver Type to Variable-step.
Settings
none (default) | warning | error
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging warning
Traceability No impact
Efficiency none
Safety precaution No impact
Programmatic Use
Parameter: MaskedZcDiagnostic
Type: string | character vector
Values: "none" | "warning" | "error"
Default: "none"
Version History
Introduced in R2010a
2-75
2 Simulink Configuration Parameters: Advanced
See Also
Topics
Solver Diagnostics on page 6-2
2-76
Block diagram contains disabled library links
Description
The Block diagram contains disabled library links parameter specifies the diagnostic behavior
when you save a model that contains disabled library links. When you save a model that contains
disabled library links, the saved model might not reflect the changes made to the referenced library
blocks.
To find disabled library links, you can use the Model Advisor check Identify disabled library
links.
Settings
warning (default) | none | error
none
The software does not issue a diagnostic and saves the model.
warning
The software issues a warning and saves the model.
error
The software issues an error and does not save the model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: SaveWithDisabledLinksMsg
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2008a
2-77
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Disable or Break Links to Library Blocks”
“Identify disabled library links”
Saving a Model
Solver Diagnostics on page 6-2
2-78
Block diagram contains parameterized library links
Description
The Block diagram contains parameterized library links parameter specifies the diagnostic
behavior when you save a model that contains parameterized library links. When you save a model
that contains parameterized library links, the saved model might not reflect the changes made to the
referenced library blocks.
To find parameterized library links, you can use the Model Advisor check Identify
parameterized library links.
Settings
warning (default) | error | none
none
The software does not issue a diagnostic and saves the model.
warning
The software issues a warning and saves the model.
error
The software issues an error and does not save the model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: SaveWithParameterizedLinksMsg
Default: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2008a
2-79
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Identify parameterized library links”
Solver Diagnostics on page 6-2
2-80
Initial state is array
Description
The Initial state is array configuration parameter specifies the diagnostic action the software takes
when you specify the value of the Initial state parameter for the model as an array.
Array format is not recommended for specifying the initial state. Because the Array format does not
include block path information, the software pairs the state values in array with block states in the
model based on:
The execution order can change from one simulation to the next if you modify the model and from one
release to the next even if you do not modify the model. If the order of the states in the array does not
match the execution order as intended, the simulation can produce unexpected results.
The array format also does not support several options available when you use the Dataset,
Structure, or Structure with time format, including:
• Associating initial state values with the path to the block to which the state applies. This
association removes dependencies on the block execution order.
• Using different data types for each initial state value.
• Initializing a subset of states.
• Initializing states for a model hierarchy.
For best results, specify the initial state for the model as a Simulink.op.ModelOperatingPoint
object or as a Simulink.SimulationData.Dataset object.
Settings
warning (default) | error | none
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
none
The software does not issue a diagnostic.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
2-81
2 Simulink Configuration Parameters: Advanced
Application Setting
Debugging warning
Traceability warning
Efficiency warning
Safety precaution warning
Programmatic Use
Parameter: InitInArrayFormatMsg
Type: string | character vector
Values: "none" | "warning" | "error"
Default: "warning"
Version History
Introduced in R2010a
See Also
Initial state | States | Final states | Save final operating point | Format
Topics
Initial state
“Save Block States and Simulation Operating Points”
“Convert Data to Dataset Format”
2-82
Insufficient maximum identifier length
Description
The Insufficient maximum identifier length configuration parameter specifies the diagnostic
action to take when the Maximum identifier length configuration parameter provides too few
characters to ensure unique global identifiers across models in a model reference hierarchy.
Settings
warning (default) | error | none
warning
The software issues a warning and truncates the identifiers in the generated code. The truncated
identifiers fit within the maximum length specified by Maximum identifier length.
error
The software issues an error.
none
The software does not issue a diagnostic and truncates the identifiers in the generated code. The
truncated identifiers fit within the maximum length specified by Maximum identifier length.
Recommended Settings
Application Setting
Debugging warning
Traceability warning
Efficiency warning
Safety precaution warning
Programmatic Use
Parameter: ModelReferenceSymbolNameMessage
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2006b
See Also
Maximum identifier length
2-83
2 Simulink Configuration Parameters: Advanced
Topics
“Model Configuration Parameters: Diagnostics” on page 6-2
“Specify Identifier Length to Avoid Naming Collisions” (Simulink Coder)
“Set Configuration Parameters for Code Generation of Model Hierarchies” (Simulink Coder)
2-84
Compiler optimization level
Description
This parameter specifies the degree of optimization used by the compiler that generates code for
simulation. The software generates a simulation target for the model in:
The software generates a simulation target for normal mode simulation for:
Whether the compiler optimizes the generated code affects the amount of time required to build the
simulation target and the execution of the simulation target in simulation.
• Optimizing the generated code increases the build time but can result in faster execution during
simulation.
• Skipping optimization decreases the build time but can result in slower execution during
simulation.
Settings
Optimizations off (faster builds) | Optimizations on (faster runs)
This setting can be helpful when you run many simulations without rebuilding the simulation
target.
2-85
2 Simulink Configuration Parameters: Advanced
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: SimCompilerOptimization
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2008a
See Also
Topics
“Acceleration”
“Interact with the Acceleration Modes Programmatically”
“Customize the Acceleration Build Process”
“Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
2-86
Verbose accelerator builds
Description
This parameter specifies the amount of information to display during simulation target builds for
accelerator mode simulations, rapid accelerator simulations, and referenced models that simulate in
accelerator mode.
Settings
off (default) | on
off
The software displays limited information while building simulation target.
on
The software displays compiler options in use and progress information while building simulation
target.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: AccelVerboseBuild
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2008a
See Also
Topics
“Controlling Verbosity During Code Generation”
“Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
2-87
2 Simulink Configuration Parameters: Advanced
Description
The Implement logic signals as Boolean data (vs. double) parameter specifies whether the data
type for logical signals is Boolean or double. Using Boolean values instead of double values reduces
memory requirements for generated code. A Boolean value typically requires one byte of storage,
while a double value requires eight bytes of storage.
• Logical Operator blocks that have the Output data type parameter set to Inherit: Logical
(see Configuration Parameters: Optimization)
• Relational Operator blocks that have the Output data type parameter set to Inherit: Logical
(see Configuration Parameters: Optimization)
• Combinatorial Logic blocks
• Hit Crossing blocks
Dependencies
To enable this parameter, you must create your model with a version of Simulink that supports both
double and Boolean signals.
Settings
on (default) | off
On
Blocks that generate logic signals produce Boolean output values.
Off
Blocks that generate logic signals produce double output values.
This setting ensures compatibility with models created using a version of Simulink that does not
support Boolean signals.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency on
2-88
Implement logic signals as Boolean data (vs. double)
Application Setting
Safety precaution on
Programmatic Use
Parameter: BooleanDataType
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2008a
See Also
Topics
“Optimize Generated Code Using Boolean Data for Logical Signals” (Simulink Coder)
“Math and Data Types Pane” on page 5-2
2-89
2 Simulink Configuration Parameters: Advanced
Block reduction
Option to reduce execution time by reducing number of blocks that execute in simulation
Description
This parameter specifies whether to reduce execution time by optimizing the block diagram to reduce
the number of blocks in the model that execute during simulation. Block reduction collapses groups
of blocks into a single, more efficient block or eliminates unnecessary blocks from the execution list.
Block reduction does not affect the appearance of the block diagram.
The software searches for these block patterns to optimize out of the block diagram for simulation:
When you generate code using Simulink Coder, block reduction is intended to remove only generated
code for block execution. Other block data, such as sample time and data type definitions, might
remain in the generated code.
The software considers a code path unused when the signal path meets both of these conditions:
• All signal paths for a block end with a block that does not execute, such as a Terminator block, a
disabled Assertion block, or an S-Function block configured for block reduction.
• No signal paths for the block include global signal storage downstream from the block.
Consider the three signal paths in this block diagram. Each signal path starts with an Inport block
that connects to the input port of a Gain block. The output of the Gain block connects to a different
block in each signal path.
• In the first signal path, the Gain block connects to an Outport block. The software does not reduce
blocks in this signal path.
• In the second signal path, the Gain block connects to a Terminator block. This signal path is
unused because the Terminator block does not execute. These blocks are reduced for simulation
and code generation when you enable Block reduction.
• In the last signal path, the output of the Gain block connects to a Scope block. The Scope block
does execute in simulation, so this code path is not reduced in simulation. The software generates
code for this signal path only when you select MAT-file logging.
2-90
Block reduction
Having tunable parameters does not prevent the software from eliminating a block when block
reduction is enabled.
You can identify nonvirtual blocks that block reduction removes from the execution list by
highlighting the blocks in the block diagram or by using the get_param function.
To highlight nonvirtual blocks in the block diagram that block reduction removed from the execution
list, in the Simulink Toolstrip, on the Debug tab, select Information Overlays. Then, under Blocks,
select Reduced Blocks.
The Reduced Blocks option in the Information Overlays menu is enabled only when Block
reduction is enabled and has reduced blocks in the model.
Blocks reduced in simulation are highlighted in the model after you update the block diagram or
simulate the model. Blocks reduced in generated code are highlighted after you build your model for
code generation.
2-91
2 Simulink Configuration Parameters: Advanced
reducedBlocks = get_param("ModelName","ReducedNonVirtualBlockList");
Settings
on (default) | off
on
The software optimizes the block diagram to reduce the number of blocks that execute during
simulation and for which code is generated.
off
The software does not optimize the block diagram to reduce the number of blocks that execute
during simulation and for which code is generated.
Recommended Settings
Application Setting
Debugging off for simulation or during development
Programmatic Use
Parameter: BlockReduction
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2008a
See Also
Topics
“Eliminate Dead Code Paths in Generated Code” (Simulink Coder)
“Time-Based Scheduling” (Simulink Coder)
“Code Efficiency” (Simulink Coder)
“Model Configuration Parameters: Simulation Target” on page 16-2
2-92
Conditional input branch execution
Description
This parameter specifies whether the software optimizes input paths for Switch and Multiport Switch
blocks. The software optimizes by executing only the blocks required to compute the control input
and the data input selected by the control input. This optimization improves execution speed of
simulation and generated code. It has these limitations:
Settings
on (default) | off
on
The software optimizes the execution of blocks that determine the control and data inputs for
Switch and Multiport Switch blocks.
off
The software executes blocks driving the Switch and Multiport Switch block input ports at each
time step.
Recommended Settings
Application Setting
Debugging No impact
Traceability on
Efficiency on (execution), No impact (ROM, RAM)
Safety precaution No impact
Programmatic Use
Parameter: ConditionallyExecuteInputs
Type: string | character vector
Values: 'on' | 'off'
2-93
2 Simulink Configuration Parameters: Advanced
Default: 'on'
Version History
Introduced in R2008a
See Also
Topics
“Use Conditional Input Branch Execution” (Simulink Coder)
“Conditionally Executed Subsystems Overview”
“Code Efficiency” (Simulink Coder)
“Model Configuration Parameters: Simulation Target” on page 16-2
“Simulink Optimizations and Model Coverage” (Simulink Coverage)
2-94
Break on Ctrl+C
Break on Ctrl+C
Option to enable terminating simulation by pressing Ctrl+C
Description
The Break on Ctrl+C parameter specifies whether models that contain MATLAB Function blocks,
Stateflow charts, and dataflow domains terminate when you press Ctrl+C when you run a simulation
or generate code. When you enable this parameter, graphics refresh during simulation.
Caution When you disable this parameter, you may have to close MATLAB to end a long-running
simulation.
Settings
on | off
on
MATLAB Function blocks, Stateflow charts, and dataflow domains periodically check if Ctrl+C is
pressed. The graphics refresh.
off
MATLAB Function blocks, Stateflow charts, and dataflow domains do not respond to Ctrl+C. The
graphics do not refresh.
Recommended Settings
Application Setting
Debugging on
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SimCtrlC
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2009b
2-95
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Control Run-Time Checks”
“Model Configuration Parameters: Simulation Target” on page 16-2
2-96
Compile-time recursion limit for MATLAB functions
Description
The Compile-time recursion limit for MATLAB functions parameter specifies the number of
specialized instances of a MATLAB function allowed in code generated for MATLAB Function blocks,
Stateflow charts, and MATLAB System blocks that use compile-time recursion. The limit that you
specify applies in simulation and code generation.
Settings
50 (default) | integer greater than or equal to 0
For most functions that require specialization, the default compile-time recursion limit of 50 is large
enough. If code generation fails because of the limit, you can:
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: CompileTimeRecursionLimit
Type: integer greater than or equal to 0
Default: 50
Version History
Introduced in R2016b
See Also
Topics
“Code Generation for Recursive Functions”
2-97
2 Simulink Configuration Parameters: Advanced
2-98
Enable implicit expansion in MATLAB functions
Description
The Enable implicit expansion in MATLAB functions parameter specifies whether to enable
implicit expansion in simulation and code generation for MATLAB code that contains binary
operations and functions in MATLAB Function blocks, Stateflow charts, and MATLAB System blocks.
Implicit expansion can change the output size of binary operations and functions. When you enable
this parameter, the code generator may generate additional code to perform the implicit expansion.
Settings
on (default) | off
on
Enables implicit expansion in simulation and code generation for MATLAB code that contains
binary operations and functions.
off
Disables implicit expansion in simulation and code generation for MATLAB code that contains
binary operations and functions.
The software issues errors in simulation and code generation when MATLAB code requires
implicit expansion.
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: EnableImplicitExpansion
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2021a
2-99
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Compatible Array Sizes for Basic Operations”
“Generate Code With Implicit Expansion Enabled” (MATLAB Coder)
“Optimize Implicit Expansion in Generated Code” (MATLAB Coder)
“Model Configuration Parameters: Simulation Target” on page 16-2
2-100
Enable run-time recursion for MATLAB functions
Description
The Enable run-time recursion for MATLAB functions parameter specifies whether to allow
MATLAB code for MATLAB Function blocks, Stateflow charts, and MATLAB System blocks to contain
recursive functions. Some coding standards, such as MISRA™, do not allow recursion. To increase the
likelihood that generated code is compliant with MISRA C™, clear this parameter.
Settings
on (default) | off
on
Allows recursive functions and enables run-time recursion when generating code from MATLAB
code that contains recursive functions.
off
Does not allow recursive functions. The software issues an error if you generate code from a
model that uses MATLAB code that requires run-time recursion.
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: EnableRuntimeRecursion
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2016b
See Also
Topics
“Code Generation for Recursive Functions”
2-101
2 Simulink Configuration Parameters: Advanced
2-102
Dynamic memory allocation in MATLAB functions
Description
The Dynamic memory allocation in MATLAB functions parameter specifies whether to use
dynamic memory allocation for MATLAB code in MATLAB Function blocks, Stateflow charts, and
MATLAB System blocks in simulation and for code generation.
Use dynamic memory allocation for variable-size arrays whose size, in bytes, is greater than or equal
to the dynamic memory allocation threshold. This parameter applies to MATLAB code in a MATLAB
Function block, a Stateflow chart, or a System object™ associated with a MATLAB System block. This
parameter applies to the model during simulation and code generation. This parameter does not
apply to:
• Input signals
• Output signals
• Parameters
• Global variables
• Discrete state properties of the System object associated with a MATLAB System block
Code that uses dynamic memory allocation can be less efficient than code that uses static memory
allocation. Unless your model requires dynamic memory allocation, clear this parameter.
If sufficient memory is not available for a dynamic memory allocation request, dynamic memory
allocation can fail. The code generator does not check memory allocation requirements. For safety-
critical applications, the recommended setting for this parameter is off.
Settings
on | off
on
The software dynamically allocates memory for variable-size arrays in MATLAB code that have a
size in bytes greater than the dynamic memory allocation threshold specified by the Dynamic
memory allocation threshold in MATLAB functions parameter.
2-103
2 Simulink Configuration Parameters: Advanced
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency off
Safety precaution off
Programmatic Use
Parameter: MATLABDynamicMemAlloc
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Limitations
• If you generate code using GPU Coder™, the generated code allocates memory on the GPU using
the cudaMalloc API. As a result, the generated code might dynamically allocate GPU memory for
MATLAB functions even if this parameter is set to off.
Version History
Introduced in R2017a
See Also
Topics
“Control Memory Allocation for Variable-Size Arrays in a MATLAB Function Block”
“Model Configuration Parameters: Simulation Target” on page 16-2
2-104
Dynamic memory allocation threshold in MATLAB functions
Description
The Dynamic memory allocation threshold in MATLAB functions parameter specifies the
threshold, in bytes, above which memory is allocated dynamically for variable-size arrays in MATLAB
code in MATLAB Function blocks, Stateflow charts, and MATLAB System blocks in simulation and
code generation. This parameter does not apply to:
• Input signals
• Output signals
• Parameters
• Global variables
• Discrete state properties of the System object associated with a MATLAB System block
Dependencies
To enable this parameter, select Dynamic memory allocation in MATLAB functions.
Settings
65536 (default) | 0 | positive integer
Specify the threshold for dynamic memory allocation in bytes as 0 or as a positive integer value. To
use dynamic memory allocation for all variable-size arrays, specify the threshold as 0.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: MATLABDynamicMemAllocThreshold
Type: integer
Values: 0 | positive integer
Default: 65536
2-105
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2017a
See Also
Topics
“Control Memory Allocation for Variable-Size Arrays in a MATLAB Function Block”
“Model Configuration Parameters: Simulation Target” on page 16-2
2-106
Echo expressions without semicolons
Description
The Echo expressions without semicolons parameter specifies whether to display run-time output
values during simulation to the MATLAB Command Window from expressions that do not end in a
semicolon in MATLAB Function, State Transition Table, Truth Table, Requirements Table, and Test
Sequence blocks, and Stateflow charts.
Settings
on | off
on
Displays run-time output values from expressions that do not end in a semicolon in the MATLAB
Command Window during simulation.
off
Does not display run-time output values from expressions that do not end in a semicolon in the
MATLAB Command Window during simulation.
Recommended Settings
Application Setting
Debugging on
Traceability No impact
Efficiency off
Safety precaution No impact
Programmatic Use
Parameter: SFSimEcho
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2008b
2-107
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Speed Up Simulation” (Stateflow)
“Model Configuration Parameters: Simulation Target” on page 16-2
2-108
Enable continuous-time MATLAB functions to write to initialized persistent variables
Description
The Enable continuous-time MATLAB functions to write to initialized persistent variables
parameter controls whether continuous-time MATLAB functions can write to initialized persistent
variables.
Settings
off (default) | on
off
Continuous-time MATLAB functions can only initialize and read persistent variables.
on
Continuous-time MATLAB functions can initialize, read, and write to persistent variables.
Enable this parameter to ensure consistent functionality in later releases for models designed
using R2017b and earlier.
Tips
When you initialize a persistent variable, check that the variable is empty before assigning a value.
For more information, see “Initialize Persistent Variables in MATLAB Functions”.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: LegacyBehaviorForPersistentVarInContinuousTime
Default: string | character vector
Values: 'on' | 'off' |
Default: 'off'
2-109
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2021a
See Also
Topics
“Initialize Persistent Variables in MATLAB Functions”
“Model Configuration Parameters: Simulation Target” on page 16-2
2-110
Allow setting breakpoints during simulation
Description
The Allow setting breakpoints during simulation parameter controls whether you can set
breakpoints during simulation in MATLAB Function blocks, Stateflow charts, State Transition blocks,
and Truth Table blocks. When the Pause within time step option is selected in the Breakpoints List,
this parameter also enables stepping into Stateflow charts and MATLAB Function blocks while
stepping block by block through simulation.
This parameter applies only to breakpoints that you add in MATLAB Function blocks, Stateflow
charts, State Transition blocks, and Truth Table blocks when your simulation is actively running.
Simulink does not recognize breakpoints that you add in these locations when the simulation is
paused.
This parameter does not affect signal breakpoints for debugging in Simulink. Adding signal
breakpoints is supported while paused in simulation and while the simulation is running. For more
information, see “Debug Simulation Using Signal Breakpoints”.
Enabling this parameter has significant performance impact for models that contain multiple
MATLAB Function blocks, Stateflow charts, State Transition blocks, or Truth Table blocks. Enable this
parameter only when you want to debug a simulation of the model.
Settings
off (default) | on
off
Disables the ability to add breakpoints in MATLAB Function blocks, Stateflow charts, State
Transition blocks, and Truth Table blocks during simulation.
Use this setting when you do not intend to debug the simulation. When you clear this parameter,
if the model does not contain breakpoints when you start simulation, the software does not enable
debugging capabilities for these blocks and modeling constructs, which can improve simulation
performance.
on
Enables adding breakpoints in MATLAB Function blocks, Stateflow charts, State Transition
blocks, and Truth Table blocks during simulation.
Use this setting when you need to debug a simulation of a model that contains these blocks.
Enabling this parameter can degrade simulation performance, but also provides flexibility for
debugging simulations. You can pause the simulation, add breakpoints, and then continue the
simulation.
2-111
2 Simulink Configuration Parameters: Advanced
Recommended Settings
Application Setting
Debugging on
Traceability No impact
Efficiency off
Safety precaution No impact
Programmatic Use
Parameter: SFSimEnableDebug
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2008b
See Also
Breakpoints List
Topics
“Debug MATLAB Function Blocks”
“Set Breakpoints to Debug Charts” (Stateflow)
“Model Configuration Parameters: Simulation Target” on page 16-2
2-112
Enable memory integrity checks
Description
The Enable memory integrity checks parameter specifies whether to check for memory integrity
violations when building the simulation target for MATLAB Function and MATLAB System blocks. You
can check for memory integrity violations in all simulation modes or only during simulations in
normal and accelerator mode.
Settings
On for simulation (default) | Always on | Off
On for simulation
Checks MATLAB code in MATLAB Function and MATLAB System blocks for memory integrity
violations in normal and accelerator mode simulations.
Always on
Checks MATLAB code in MATLAB Function and MATLAB System blocks for all simulation modes,
including rapid accelerator simulations.
Off
Does not check MATLAB code in MATLAB Function and MATLAB System blocks in normal,
accelerator, or rapid accelerator simulations.
Caution Memory integrity violations can result in unpredictable behavior. Set this parameter to
Off only if you are sure that dimension and array bounds checking are not necessary for the
MATLAB code for all MATLAB Function and MATLAB System blocks in your model.
Tips
The most likely cause of memory integrity issues is accessing an array out of bounds.
Recommended Settings
Application Setting
Debugging On for simulation
Traceability No impact
Efficiency No recommendation
Safety precaution Always on
Programmatic Use
Parameter: SimIntegrity
2-113
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2009b
See Also
Topics
“Control Run-Time Checks”
“Model Configuration Parameters: Simulation Target” on page 16-2
2-114
Generate typedefs for imported bus and enumeration types
Description
This parameter specifies whether Simulink generates type definitions for bus and enumeration data
types imported in Stateflow charts and MATLAB Function blocks.
Settings
off (default) | on
off
Simulink does not generate its own type definitions for bus and enumeration data types imported
in Stateflow charts and MATLAB Function blocks. Simulink uses type definitions from the
included header file.
on
Simulink generates type definitions for bus and enumeration types imported in Stateflow charts
and MATLAB Function blocks.
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SimGenImportedTypeDefs
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2013b
2-115
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Model Configuration Parameters: Simulation Target” on page 16-2
2-116
Use local custom code settings (do not inherit from main model)
Description
The Use local custom code settings (do not inherit from main model) parameter specifies
whether library models can use custom code settings that are different from the main model.
If your model contains libraries that contain C Caller or C Function blocks that call custom code
functions, you must:
• Specify the custom code in the configuration parameter for the library model. Specify custom code
in the Custom Code section of the Simulation Target pane in the Configuration Parameters
dialog box.
• Enable this parameter.
When a library does not contain C Caller or C Function blocks, this parameter applies only to
MATLAB Function, State Transition Table, Truth Table, Requirements Table, and Test Sequence
blocks, and Stateflow charts in the library.
Settings
on (default) | off
on
Custom code settings for library models can differ from the custom code settings of the main
model.
off
Custom code settings for library models cannot differ from the custom code settings of the main
model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: SimUseLocalCustomCode
Type: string | character vector
2-117
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2008b
See Also
Topics
Including Custom C Code (Stateflow)
“Model Configuration Parameters: Simulation Target” on page 16-2
2-118
Allow symbolic dimension specification
Description
The Allow symbolic dimension specification parameter specifies whether Simulink software:
Settings
on (default) | off
on
Simulink propagates symbolic dimensions throughout the model and preserves these symbols in
the generated code when using Embedded Coder®.
off
The software propagates the numeric values associated with the symbolic specification
throughout the model but the symbols do not appear in the generated code.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: AllowSymbolicDim
Type: string | character vector
Values: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2015a
See Also
Topics
“Use Symbolic Dimensions for Signal Dimensions” (Embedded Coder)
2-119
2 Simulink Configuration Parameters: Advanced
“Implement Symbolic Dimensions for Array Sizes in Generated Code” (Embedded Coder)
“Model Configuration Parameters: Diagnostics” on page 6-2
2-120
Enable decoupled continuous integration
Description
The Enable decoupled continuous integration configuration parameter controls whether the
fastest discrete sample time in the model controls continuous state integration.
In hybrid models, such as cyber-physical systems, that contain both continuous and discrete sample
times, enabling this parameter can improve simulation performance when:
maxstep = get_param(mdl,"CompiledStepSize");
Settings
off (default) | on
on
Allow the solver to decouple integration of continuous states from discrete sample times in the
model.
off
Preserve coupling between integration of continuous states and discrete sample times in the
model.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: DecoupledContinuousIntegration
2-121
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2017b
See Also
Topics
“Solver Pane” on page 3-2
2-122
Enable minimal zero-crossing impact integration
Description
The Enable minimal zero-crossing impact integration configuration parameter specifies whether
the solver tries to reduce the effect of zero crossings that occur during simulation on the integration
of continuous states in variable-step simulations.
Dependencies
To enable this parameter, set the solver Type to Variable-step.
Settings
off (default) | on
off
The solver does not try to reduce the impact of zero crossings on the integration of continuous
states.
on
The solver tries to reduce the impact of zero crossings on the integration of continuous states.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging off
Traceability off
Efficiency on
Safety precaution No impact
Programmatic Use
Parameter: MinimalZcImpactIntegration
Type: string | character vector
Values: "on" | "off"
Default: "off"
Version History
Introduced in R2018a
2-123
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies the diagnostic behavior when a model contains a Reusable storage class
that has more than one endpoint. An endpoint is a usage of a Reusable storage class with no other
downstream usages.
If your model contains aReusable storage class that does not have a unique endpoint, the run-time
environment must not use the variable value because the value is ambiguous. If the run-time
environment must use the final value of a signal that uses the Reusable storage class specification,
set this parameter value to error.
To resolve the error, remove the Reusable storage class specification from the endpoints until the
storage class has only one endpoint. For example, in this model, the final value of the Reusable
storage class RCSC_1 is ambiguous because RCSC_1 has two endpoints. If you remove the
specification from the Sum block output signal or from the output signal of the Bias block connected
to the Outport block with a port index of 1, then the storage class RCSC_1 has only one endpoint.
Dependencies
To enable this parameter, set System target file to ert.tlc.
Settings
warning (default) | error | none
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
2-124
Detect ambiguous custom storage class final values
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: RCSCObservableMsg
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2017b
See Also
Topics
Data Validity Diagnostics on page 8-2
“Specify Buffer Reuse for Signals in a Path” (Embedded Coder)
“Model Configuration Parameters: Code Generation Optimization” (Embedded Coder)
2-125
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies the diagnostic behavior when a model contains a Reusable storage class
that the code generator cannot reuse with other instances of the same Reusable storage class.
The code generator might not implement the reuse specification for a Reusable storage class if:
• The code generator cannot change the block execution order to enable reuse.
• The conditional execution of some blocks in the model is incompatible with reuse.
When the code generator does not implement the reuse specification, the generated code likely
contains additional global variables. For example, in this model, the code generator cannot reuse the
variable Y to hold the outputs of In2, Gain, and Gain2 because Gain executes before Gain2. The
generated code contains an extra variable to hold the Gain output. The red numbers to the top right
of the blocks indicate the execution order.
Dependencies
To enable this parameter, set System target file to ert.tlc.
Settings
warning (default) | error | none
The diagnostic behavior for each setting varies based on whether the model contains Reusable
storage classes and model references.
2-126
Detect non-reused custom storage classes
none
If the model does not contain Reusable storage classes and referenced models, the software
does not issue a message when the code generator cannot reuse a Reusable storage class.
If the model contains Reusable storage classes and referenced models, the software issues a
message that suggests changing this parameter value to error.
warning
If the model does not contain Reusable storage classes and referenced models, the software
issues a warning when the code generator cannot reuse a Reusable storage class.
If the model contains reusable storage classes and referenced models, the software issues a
message that advises changing this parameter value to error.
error
The software issues an error if the code generator cannot reuse a Reusable storage class.
Use this setting if you want to prevent additional global variables in the generated code because
of a Reusable storage class specification that the code generator cannot honor. Remove the
Reusable storage class specification from the signal line in the error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: RCSCRenamedMsg
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2017b
See Also
Topics
Data Validity Diagnostics on page 8-2
“Specify Buffer Reuse for Signals in a Path” (Embedded Coder)
“Model Configuration Parameters: Code Generation Optimization” (Embedded Coder)
2-127
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies whether Simulink requires that simulation and generated code have the
same execution order when output and update code are combined in the same function. For certain
modeling patterns, enabling this parameter prevents a potential mismatch between simulation results
and results obtained using generated code. If your model requires enabling this parameter, Simulink
issues a warning that indicates a potential mismatch between simulation and code generation results.
You might see this warning for models that meet these conditions:
• A referenced model has a single function for output and update code, uses function prototype
control, or generates C++ code.
• A referenced model input port connects only to blocks that do not have direct feedthrough, such
as Delay and Integrator blocks and is not associated with a function-call subsystem port in the
referenced model. Blocks that do not have direct feedthrough do not use the block input values for
the current time step to calculate the block output values for the current time step.
• The referenced model uses a shared global resource such as a global data store.
Settings
off (default) | on
Enabling this parameter can create artificial algebraic loops. Enable this parameter only if you plan
to generate code from your model and you see a warning about a potential mismatch between
simulation and code generation.
off
Simulink does not force simulation and code generation to use the same execution order. For
certain modeling patterns, the simulation execution order can differ from the execution order in
generated code. If the execution order is different, the results you obtain in simulation might not
match results you obtain from the generated code.
on
Simulink forces simulation and code generation to use the same execution order when output and
update code are combined in a single function.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
2-128
Combine output and update methods for code generation and simulation
Application Setting
Safety precaution No impact
Programmatic Use
Parameter: ForceCombineOutputUpdateInSim
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2017b
See Also
Topics
“Artificial Algebraic Loops”
“Model Configuration Parameters: Diagnostics” on page 6-2
2-129
2 Simulink Configuration Parameters: Advanced
Description
The Include custom code for referenced models configuration parameter lets you use custom
code for model reference simulation target builds for accelerator mode simulation.
Use the “Model Configuration Parameters: Simulation Target” on page 16-2 pane to specify the
custom code file.
Caution Using custom code for referenced models in accelerator mode can produce different results
than if you simulate the model without using the custom code. If the custom code includes
declarations of structures for buses or enumerations, the model reference simulation target
generation fails if the build results in duplicate declarations of those structures. Also, if the custom
code uses a structure that represents a bus or enumeration, you might get unexpected simulation
results.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
off (default) | on
off
Ignore custom code during model reference accelerator mode simulation.
on
Use custom code with blocks such as Stateflow, MATLAB Function, or C Caller blocks during
model reference accelerator mode simulation.
2-130
Include custom code for referenced models
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution off
Programmatic Use
Parameter: SupportModelReferenceSimTargetCustomCode
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2018a
See Also
Model
Topics
“Manage Simulation Targets for Referenced Models”
“Model Configuration Parameters: Model Referencing” on page 15-2
2-131
2 Simulink Configuration Parameters: Advanced
Hardware acceleration
Option to improve simulation performance by leveraging SIMD instructions
Description
This parameter specifies the type of hardware acceleration to use in simulation. Hardware
acceleration improves simulation performance by leveraging SIMD instructions.
Settings
Leverage generic hardware (Faster, no rebuild) | Leverage native hardware
(Fastest, rebuild allowed) | Off
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: SimHardwareAcceleration
Type: string | character vector
Values: 'off' | 'generic' | 'native'
Default: 'generic'
Version History
Introduced in R2021a
2-132
Hardware acceleration
See Also
Topics
“Model Configuration Parameters: Simulation Target” on page 16-2
2-133
2 Simulink Configuration Parameters: Advanced
Description
This parameter specifies the diagnostic behavior when a model cannot use pregenerated library code
or pregenerated library code is missing. This parameter applies when you generate code for a model
that contains an instance of a reusable library subsystem that has a function interface.
To use pregenerated library code, generate code for the library before generating code for the model.
Dependencies
To enable this parameter, on the Code Generation pane, set System target file to ert.tlc or
another TLC file that is derived from ert.tlc.
Settings
warning (default) | error | none
warning
The software issues a warning.
The code generator generates code for a reusable library subsystem that does not contain
function interfaces. The generated code for the reusable library subsystem is in the slprj/
target/_sharedutils folder.
error
The software issues an error, and the code generator does not generate code.
none
The software does not issue a diagnostic.
The code generator generates code for a reusable library subsystem that does not contain
function interfaces. The generated code for the reusable library subsystem is in the slprj/
target/_sharedutils folder.
Recommended Settings
Application Setting
Debugging error or warning
Traceability No impact
Efficiency No impact
2-134
Behavior when pregenerated library subsystem code is missing
Application Setting
Safety precaution error
Programmatic Use
Parameter: PregeneratedLibrarySubsystemCodeDiagnostic
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2019a
See Also
System target file
Topics
“Library-Based Code Generation for Reusable Library Subsystems” (Embedded Coder)
2-135
2 Simulink Configuration Parameters: Advanced
Description
The Behavior when a matching unit test for subsystem reference is missing parameter
specifies the diagnostic behavior when you simulate or build a model that contains a Subsystem
Reference block whose signatures does not match any of the unit test signatures of the Subsystem
Reference block in the subsystem file.
Settings
error (default) | warning | none
none
The software simulates or builds the model and does not issue a diagnostic.
warning
The software simulates or builds the model, but issues a warning that includes the names of
subsystem reference instances that do not have matching unit tests.
error
The software does not simulate or build the model and issues an error that includes the names of
subsystem reference instances that do not have matching unit tests.
Recommended Settings
Application Setting
Debugging error or warning
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SubsystemReferenceDiagnosticForUnitTest
Type: string | character vector
Value: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced in R2023a
2-136
Behavior when a matching unit test for subsystem reference is missing
See Also
“Create and Use Referenced Subsystems in Models”
Topics
“Define Subsystem Reference Interfaces Using Test Harnesses and Generate Reusable Code”
2-137
2 Simulink Configuration Parameters: Advanced
Description
The Arithmetic operations in variant conditions parameter specifies the diagnostic behavior
when the variant condition value for a variant block with code compile activation time contains
arithmetic operations, such as +, -, and *. Variant blocks have code compile activation time when you
set the Variant activation time parameter for the block to code compile.
Variant conditions specified using arithmetic operators can cause differences in behavior between
simulation and generated code due to variation in data types used in generated code based on
implementation. If your model uses arithmetic operations to specify variant conditions, consider
removing the arithmetic operations instead of relaxing the diagnostic behavior.
For example, suppose the variant condition for a Variant Source block is V * W == 10 and you
generate code that produces preprocessor conditions for the block. The generated C code contains
#if V*W == 10. In simulation, V and W use the int32 data type, but the integer data type used by
the compiler for the generated code depends on the implementation. The data type difference can
cause a difference in behavior between simulation and generated code for large values of V and D.
Settings
error | warning | none
none
The software does not issue a diagnostic.
warning
The software issues a warning.
This is the default setting for models created using a version prior to R2019a.
error
The software issues an error and terminates the simulation.
This is the default setting for models created using version R2019a and later. If your model uses
arithmetic operations to specify variant conditions, consider removing the arithmetic operations
instead of relaxing the diagnostic behavior.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
2-138
Arithmetic operations in variant conditions
Application Setting
Safety precaution No impact
Programmatic Use
Parameter: ArithmeticOperatorsInVariantConditions
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced in R2019a
See Also
Topics
Solver Diagnostics on page 6-2
2-139
2 Simulink Configuration Parameters: Advanced
Description
The Variant activation time inherited from Simulink.VariantControl parameter specifies the
diagnostic behavior when the Variant activation time parameter for a variant block is set to
inherit from Simulink.VariantControl but the block has no Simulink.VariantControl
variant control variables from which to inherit activation time.
Settings
warning | error | none
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: InheritVATfromSVC
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2022b
2-140
Variant activation time inherited from Simulink.VariantControl
See Also
Topics
Solver Diagnostics on page 6-2
2-141
2 Simulink Configuration Parameters: Advanced
Description
The FMU Import blocks parameter enables debug execution mode for FMU Import blocks. When
debug execution mode is enabled, FMU binaries execute in a separate process, which protects
MATLAB processes. For example, enabling debug execution mode can prevent MATLAB from
crashing if a third-party FMU binary contains a segmentation violation.
Settings
off (default) | on
on
This setting enables debug execution mode for FMU Import blocks. FMU binaries execute in a
separate process.
on
This setting disables debug execution mode for FMU Import blocks. FMU binaries execute in the
same process as the MATLAB process.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: DebugExecutionForFMUViaOutOfProcess
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2019a
2-142
Variant condition mismatch at signal source and destination
Description
The Variant condition mismatch at signal source and destination parameter specifies the
diagnostic behavior when variant modeling issues might cause generated code to contain unused
variables. Generated code may contain unused variables due to incorrect modelling. For more
information, see “Prevent Creation of Unused Variables for Lenient Variant Choices” or “Prevent
Creation of Unused Variables for Unconditional and Conditional Variant Choices”.
Settings
none (default) | warning | error
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: VariantConditionMismatch
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2020b
2-143
2 Simulink Configuration Parameters: Advanced
See Also
Topics
“Prevent Creation of Unused Variables for Lenient Variant Choices”
“Prevent Creation of Unused Variables for Unconditional and Conditional Variant Choices”
2-144
Variant configuration not used by top model
Description
This parameter applies to models that have variant configurations defined using Variant Manager for
Simulink. The parameter selects the diagnostic action to take when a top-level model references this
model but does not use one of the predefined configurations of this model to set up its own variant
configurations. Use this parameter to help verify that this model is used only for its tested variant
configurations when referenced by another model. When you set this parameter to warning or
error, the software issues the diagnostic when you compile the top model or activate the top model
configurations using Variant Manager.
Settings
warning (default) | error | none
none
The software does not issue a diagnostic if the top model does not use this model in one of its
published variant configurations.
warning
The software issues a warning if the top model does not use this model for one of its published
variant configurations. To suppress the warning and continue with simulation, click Suppress.
error
The software issues an error and terminates the simulation if the top model does not use this
model for one of its published variant configurations.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: VariantConfigNotUsedByTopModel
Type: string | character vector
Values: 'none' | 'warning' | 'error'
Default: 'warning'
2-145
2 Simulink Configuration Parameters: Advanced
Version History
Introduced in R2022b
See Also
Topics
“Variant Configurations”
“Compose Variant Configurations for Top Model Using Referenced Model Configurations”
“Variant Manager for Simulink” on page 21-2
2-146
Use precompiled libraries for MATLAB functions
Description
This parameter specifies the extent to which the code generated for the MATLAB functions in your
model includes calls to precompiled libraries.
For certain precompiled libraries (for example, BLAS, LAPACK, and FFTW), there exist individual
configuration parameters that allow you to customize their usage in the generated code. The Use
precompiled libraries for MATLAB functions parameter does not affect the use of these libraries.
Settings
Prefer precompiled libraries when available | Avoid precompiled libraries when
possible
For simulation or C/C++ code generation, this value is the default value.
This setting is an appropriate choice when you want to optimize the performance of your model
or the generated code for specific platforms.
Avoid precompiled libraries when possible
The code generator uses precompiled libraries only if no alternative implementations of their
algorithms are available.
For GPU acceleration or code generation, this value is the default value.
This setting is useful when you want to create portable applications that can run on many
platforms.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Prefer precompiled libraries when
available
Safety precaution Avoid precompiled libraries when
possible
2-147
2 Simulink Configuration Parameters: Advanced
Programmatic Use
Parameter: UsePrecompiledLibraries
Type: string | character vector
Values: "Prefer | "Avoid"
Default: "Prefer" (C/C++) | "Avoid" (CUDA®)
Version History
Introduced in R2024b
See Also
Topics
“Model Configuration Parameters: Simulation Target” on page 16-2
2-148
3
Solver Parameters
3 Solver Parameters
Solver Pane
The Solver pane includes parameters for configuring the solver for a model. A solver computes the
states for a dynamic system for each simulation time step over the specified time span for the
simulation. The Solver pane also includes the parameters you use to configure the simulation start
and stop times that define the time span.
Once the model compiles, the status bar displays the solver used for compiling and a carat (^) when:
• Simulation time is not the same as clock time. For example, running a simulation for 10 seconds
usually does not take 10 seconds. Total simulation time depends on factors such as model
complexity, solver step sizes, and computer speed.
• Code generation requires selecting a fixed-step solver.
• Selecting a variable-step solver can significantly shorten the time required to simulate models in
which states change rapidly or contain discontinuities.
Parameter Description
Start time Specify the start time for the simulation or
generated code as a double-precision value,
scaled to seconds.
Stop time Specify the stop time for the simulation or
generated code as a double-precision value,
scaled to seconds.
Type Select the type of solver you want to use to
simulate your model.
Solver Select the solver you want to use to compute the
states of the model during simulation or code
generation.
Max step size Specify the largest time step that the solver can
take.
Integration method Specify the integration order of the odeN solver
Initial step size Specify the size of the first time step that the
solver takes.
Min step size Specify the smallest time step that the solver can
take.
3-2
Solver Pane
Parameter Description
Relative tolerance Specify the largest acceptable solver error,
relative to the size of each state during each time
step. If the relative error exceeds this tolerance,
the solver reduces the time step size.
Absolute tolerance Specify the largest acceptable solver error, as the
value of the measured state approaches zero. If
the absolute error exceeds this tolerance, the
solver reduces the time step size.
Shape preservation At each time step use derivative information to
improve integration accuracy.
Maximum order Select the order of the numerical differentiation
formulas (NDFs) used in the ode15s solver.
Solver reset method Select how the solver behaves during a reset,
such as when it detects a zero crossing.
Number of consecutive min steps Specify the maximum number of consecutive
minimum step size violations allowed during
simulation.
Solver Jacobian Method Specify the method to compute the Jacobian
matrix for an implicit solver.
Daessc mode Fine-tune the daessc solver performance.
Treat each discrete rate as a separate task Specify whether Simulink executes blocks with
periodic sample times individually or in groups.
Automatically handle rate transition for data Specify whether Simulink software automatically
transfer inserts hidden Rate Transition blocks between
blocks that have different sample rates to ensure:
the integrity of data transfers between tasks; and
optional determinism of data transfers for
periodic tasks.
Deterministic data transfer Control whether the Rate Transition block
parameter Ensure deterministic data transfer
(maximum delay) is set for auto-inserted Rate
Transition blocks.
Higher priority value indicates higher task Specify whether the real-time system targeted by
priority the model assigns higher or lower priority values
to higher priority tasks when implementing
asynchronous data transfers.
Zero-crossing control Enables zero-crossing detection during model
simulation. For most models, this speeds up
simulation by enabling the solver to take larger
time steps.
Time tolerance Specify a tolerance factor that controls how
closely zero-crossing events must occur to be
considered consecutive.
3-3
3 Solver Parameters
Parameter Description
Number of consecutive zero crossings Specify the number of consecutive zero crossings
that can occur before Simulink software displays
a warning or an error.
Algorithm Specifies the algorithm to detect zero crossings
when a variable-step solver is used.
Signal threshold Specifies the deadband region used during the
detection of zero crossings. Signals falling within
this region are defined as having crossed through
zero.
Periodic sample time constraint Select constraints on the sample times defined by
this model. If the model does not satisfy the
specified constraints during simulation, Simulink
software displays an error message.
Fixed-step size (fundamental sample time) Specify the step size used by the selected fixed-
step solver.
Sample time properties Specify and assign priorities to the sample times
that this model implements.
Extrapolation order Select the extrapolation order used by the
ode14x solver to compute a model's states at the
next time step from the states at the current time
step.
Number of Newton's iterations Specify the number of Newton's method
iterations used by the ode14x solver to compute
a model's states at the next time step from the
states at the current time step.
Allow tasks to execute concurrently on target Enable concurrent tasking behavior for model.
Auto scale absolute tolerance Enable automatic absolute tolerance adaptation
Allow multiple tasks to access inputs and outputs Enable Branched Input Multiple Outputs in rate-
based models
Enable zero-crossing detection for fixed-step Enable zero-crossing detection with fixed step
simulation
Maximum number of bracketing iterations Specify maximum number of bracketing
iterations performed when locating a zero
crossing
Maximum number of zero-crossings per step Specify the maximum number of zero-crossings to
locate in one fixed step
Parameter Description
Enable decoupled continuous integration Removes the coupling between continuous and
discrete rates.
Enable minimal zero-crossing impact integration Minimizes the impact of zero-crossings on the
integration of continuous states.
3-4
Solver Pane
See Also
Related Examples
• “Solver Selection Criteria”
3-5
3 Solver Parameters
Absolute tolerance
Absolute tolerance for solver tolerance calculation
Description
Specify the largest acceptable solver error as the value of the measured state approaches zero.
The acceptable error considered for each state on each time step is determined by either the relative
tolerance or the absolute tolerance, whichever results in a larger tolerance. The solver calculates the
acceptable error based on the relative tolerance by multiplying the relative tolerance and the state
value.
ei = reltol * |x|,
where:
When ei is larger than the value specified for the Absolute tolerance parameter, the relative
tolerance determines the tolerance for that state on that time step. When the absolute tolerance is
greater than ei, the absolute tolerance determines the tolerance for that state on that time step. In
general, the absolute tolerance applies when the state values approach zero.
Dependencies
To enable this parameter:
Settings
auto | positive scalar number
By default, the value is auto, and the software scales the value of the absolute tolerance based on the
state values during simulation. The software determines the initial absolute tolerance based on the
value of the relative tolerance.
3-6
Absolute tolerance
where abstol is the absolute tolerance and reltol is the relative tolerance.
As the simulation progresses, the absolute tolerance for each state is scaled to the maximum value
that state has reached up to the current time step times the relative tolerance.
For example, if a state reaches a value of 1 during the simulation and the relative tolerance is 1e-4,
the absolute tolerance is initialized to 1e-7 and reaches a value of 1e-4 by the end of the simulation.
When you specify the absolute tolerance as a positive scalar number, you can choose whether to scale
the absolute tolerance based on state values during simulation using the Auto scale absolute
tolerance parameter.
Tips
• Some blocks have a block parameter that allows you to specify an absolute tolerance value for the
software to use when computing the acceptable error for those block states. When you specify a
value for the block parameter, the software uses the block parameter value instead of the model
configuration parameter value when calculating acceptable state errors for states of that block.
Such blocks include:
• Integrator
• Second-Order Integrator
• Variable Transport Delay
• Transfer Fcn
• State-Space
• Zero-Pole
Consider specifying the block parameter value when the states in your model vary widely in
magnitude.
• If your simulation results do not seem accurate, and if your model has states with values that
approach zero, then the absolute tolerance might be too large.
• Specifying a small absolute tolerance might slow the simulation because the solver might take
more steps than necessary near time points where the state values are near zero.
• To check the accuracy of a simulation, you can reduce the absolute tolerance and simulate the
model again. If the results of the two simulations are not significantly different, then the solution
has converged.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
3-7
3 Solver Parameters
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: AbsTol
Type: string | character vector
Value: 'auto' | positive scalar number
Default: 'auto'
Version History
Introduced before R2006a
See Also
Topics
“Error Tolerances for Variable-Step Solvers”
“Improve Simulation Performance Using Performance Advisor”
“Solver Pane” on page 3-2
3-8
Allow multiple tasks to access inputs and outputs
Description
When root-level input or output ports in the top model or a model reference connect to multiple tasks
with different sample times, use this parameter to determine how the software combines the task
sample times to provide data to each task.
Settings
off (default) | on
off
When multiple tasks access data for root-level input and output ports, the software uses the
greatest common denominator sample time that has an implicit task.
on
The software assigns root-level input and output ports connected to multiple tasks a union sample
time that includes each task sample time.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency On
Safety precaution No recommendation
Programmatic Use
Parameter: AllowMultiTaskInputOutput
Type: string | character vector
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2021b
3-9
3 Solver Parameters
See Also
Rate Transition
Topics
“Solver Pane” on page 3-2
3-10
Automatically handle rate transition for data transfer
Description
When you select this option, the software inserts Rate Transition blocks between blocks that have
different sample times. The inserted Rate Transition blocks ensure that data in deployed code
transfers between different sample times without overwritten values.
For more information, see “Rate Transition Block Options” (Simulink Coder).
Settings
off (default) | on
off
The software does not insert Rate Transition blocks between blocks with different sample times.
When the software detects a sample time transition, you must modify the model to eliminate the
transition or manually insert a Rate Transition block.
on
The software inserts a Rate Transition block between blocks with different sample times and
handles rate transitions for asynchronous and periodic tasks.
For asynchronous tasks, the software configures the inserted blocks to ensure data integrity but
not determinism during data transfers.
Selecting this option enables the Deterministic data transfer parameter, which allows you to
control the level of data transfer determinism for periodic tasks.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact for simulation or during development
3-11
3 Solver Parameters
Programmatic Use
Parameter: AutoInsertRateTranBlk
Type: string | character vector
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2007a
See Also
Topics
“Rate Transition Block Options” (Simulink Coder)
“Solver Pane” on page 3-2
3-12
Auto scale absolute tolerance
Description
Choose whether to use a fixed tolerance value for all states throughout the simulation or to scale the
absolute tolerance value for each state based on the state value.
Dependencies
To enable this parameter:
Settings
on (default) | off
When you enable absolute tolerance scaling, as the simulation progresses, the absolute tolerance for
each state is scaled to the maximum value that state has reached up to the current time step times
the relative tolerance.
For example, if a state reaches a value of 1 during the simulation, the relative tolerance is 1e-4, and
the absolute tolerance value is auto, then the absolute tolerance is initialized to 1e-7 and reaches a
value of 1e-4 by the end of the simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: AutoScaleAbsTol
Type: string | character vector
3-13
3 Solver Parameters
Value:'on' | 'off'
Default: 'on'
Version History
Introduced in R2018a
See Also
Absolute tolerance
Topics
“Solver Pane” on page 3-2
“Absolute Tolerances”
3-14
Allow tasks to execute concurrently on target
Description
Enable or disable concurrent tasking behavior for model. If a referenced model has a single rate, you
do not need to select this option to enable concurrent tasking behavior.
Dependencies
To enable this parameter, set the solver Type to Fixed-step.
Settings
off (default) | on
off
Disable the model from being configured for concurrent tasking.
on
Enable the model to be configured for concurrent tasking.
When you select this option, the Configure Tasks button appears. Click this button to open the
Concurrent Execution dialog box.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: ConcurrentTasks
Type: string | character vector
Values: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2012a
3-15
3 Solver Parameters
See Also
Topics
“Concurrent Execution Tool” on page 20-2
“Solver Pane” on page 3-2
3-16
Time tolerance
Time tolerance
Definition of consecutive zero crossings
Description
The software defines zero crossings as consecutive if the time between events is smaller than an
interval defined by the time tolerance. Consider a simulation in which the software detects zero
crossings ZC1 and ZC2, bracketed at successive time steps t1 and t2.
The software considers the zero crossings consecutive when the interval dt between t1 and t2 is less
than the product of the specified time tolerance timetol and the larger time t2.
dt < timetol * t2
The software counts the number of consecutive zero crossings detected and issues a diagnostic when
the count exceeds the amount specified by the Number of consecutive zero crossings parameter.
You can specify whether the diagnostic is a warning or an error using the Consecutive zero-
crossings violation parameter. The counter resets when the simulation progresses without
detecting another zero crossing long enough for the next zero crossing to be considered
nonconsecutive.
Dependencies
To enable this parameter, set the solver Type to Variable-step and set Zero-crossing control to
either Use local settings or Enable all.
Settings
10*128*eps | positive scalar number
Decreasing the time tolerance specifies a stricter definition for consecutive. A lower time tolerance
can provide more flexibility for a model to recover from behaviors and conditions that result in many
discontinuities.
Tips
For models that experience excessive zero crossings, consider increasing the value for the Number
of consecutive zero crossings parameter to relax the condition for when the software issues a
diagnostic about the number of detected zero crossings.
3-17
3 Solver Parameters
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ConsecutiveZCsStepRelTol
Type: string | character vector
Value: positive scalar number
Default: '10*128*eps'
Version History
Introduced before R2006a
See Also
Number of consecutive zero crossings | Consecutive zero-crossings violation | Zero-crossing
control
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-18
Daessc mode
Daessc mode
Mode of operation for daessc solver
Description
Select the mode of operation for the daessc solver.
Dependencies
To enable this parameter:
Settings
auto (default) | Fast | Balanced | Robust | Quick debug | Full debug
auto
With this option selected, the software automatically selects the optimal daessc solver mode.
This option typically provides a good balance between robustness and simulation speed for most
models.
Fast
This option is the least computationally intensive but less robust than other options.
Balanced
This option provides a balance between computational complexity and robustness.
Robust
This option is more robust but more computationally intensive compared to the Fast and
Balanced options.
Quick debug
With this option selected, the software updates the solver Jacobian at every time step, which
makes this option more computationally intensive than the Robust option.
This option is recommended only for interactive model development, for quickly identifying issues
with equations.
Full debug
With this option selected, the software updates the solver Jacobian at every time step and every
Newton iteration. This mode is the most computationally intensive and is recommended only for
interactive model development and thoroughly checking equations to identify possible issues.
3-19
3 Solver Parameters
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: DaesscMode
Type: string | character vector
Value: 'auto' | 'Fast' | 'Balanced' | 'Robust' | 'QuickDebug' | 'FullDebug'
Default: 'auto'
Version History
Introduced in R2018b
See Also
Topics
“Choose a Solver”
“Solver Pane” on page 3-2
3-20
Enable zero-crossing detection for fixed-step simulation
Description
When you enable zero-crossing detection, you can sometimes use a larger step size without
sacrificing accuracy. When a discontinuity occurs in the simulation, the zero-crossing algorithm
calculates the time at which the discontinuity occurred and adjusts the continuous state values
accordingly. By adjusting the state values only around discontinuities, the solver can retain the
accuracy of a smaller step size with overall fewer calculations.
Consider enabling this parameter when your model contains continuous states.
The zero-crossing algorithm for fixed-step solvers has a bounded computational cost. You can adjust
the maximum number of calculations that occur due to using zero-crossing detection by modifying
the Maximum number of bracketing iterations and Maximum number of zero-crossings per
step parameters.
• Zero-crossing control
• Maximum number of bracketing iterations
• Maximum number of zero-crossings per step
Dependencies
To enable this parameter, set the solver Type to Fixed-step.
Settings
off (default) | on
off
Fixed-step solver does not detect or locate zero crossings during simulation.
on
Fixed-step solver detects and locates zero crossings during simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
3-21
3 Solver Parameters
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: EnableFixedStepZeroCrossing
Type: string | character vector
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2022a
R2023b: Parameter values must match for all models to generate code for model reference
hierarchy
Behavior changed in R2023b
When you generate code for a model reference hierarchy using Simulink Coder or Embedded Coder,
the value of the Enable zero-crossing detection for fixed-step simulation parameter must be the
same for the top model and all referenced models in the hierarchy.
R2023b: Software issues warning instead of error when parameter enabled for model that
has no continuous states
Behavior changed in R2023b
Since fixed-step zero-crossing detection became available in R2022a, the software has issued an error
when a model enables fixed-step zero-crossing detection but does not contain any continuous states.
Starting in R2023b, the software issues a warning instead to support code generation for model
reference hierarchies that use fixed-step zero-crossing detection and have one or more models that
do not contain continuous states. This change also provides improved support for configuration
references for both simulation and code generation workflows.
See Also
Topics
“Zero-Crossing Detection”
“Zero-Crossing Detection with Fixed-Step Simulation”
“Zero-Crossing Algorithms”
“Use Fixed-Step Zero-Crossing Detection for Faster Simulations”
3-22
Treat each discrete rate as a separate task
Description
Specify whether the software executes blocks with periodic sample times individually or in groups.
To use this parameter, clear the Use local solver when referencing model parameter.
A model with multiple tasks cannot reference a multirate model that uses single tasking mode.
Dependencies
To enable this parameter, set the solver Type to Fixed-step.
Settings
off (default) | on
off
All blocks are processed through each stage of simulation together (for example, calculating
output and updating discrete states). Use single-tasking execution if:
on
Groups of blocks with the same execution priority are processed through each stage of simulation
based on task priority. The multitasking mode helps to create valid models of real-world
multitasking systems, where sections of your model represent independent tasks.
Tips
Use the Single task data transfer and Multitask data transfer parameters to control the
diagnostic behavior for sample rate transitions between blocks that have different sample times.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
3-23
3 Solver Parameters
Application Setting
Traceability No impact for simulation or during development
Programmatic Use
Parameter: EnableMultiTasking
Type: string | character vector
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2016b
See Also
Rate Transition
Topics
“Time-Based Scheduling” (Simulink Coder)
“Time-Based Scheduling and Code Generation” (Simulink Coder)
“Rate Transitions and Data Transfers” (Simulink Coder)
“Solver Pane” on page 3-2
3-24
Extrapolation order
Extrapolation order
Extrapolation order for ode14x fixed-step solver
Description
The ode14x solver uses extrapolation to compute the model states for the next time step using the
states in the current time step. Use this parameter to specify the order of extrapolation.
Dependencies
To enable this parameter when the solver Type is Fixed-step, from the Solver list, select ode14x
(extrapolation).
Settings
4 (default) | 3 | 2 | 1
Higher-order extrapolation is more accurate but also more computationally intensive. The number
you select corresponds to the order of extrapolation used. For example, selecting 3 specifies third-
order extrapolation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ExtrapolationOrder
Type: scalar number
Value: 1 | 2 | 3 | 4
Default: 4
3-25
3 Solver Parameters
Version History
Introduced before R2006a
See Also
Topics
“Fixed Step Solvers in Simulink”
“Solver Pane” on page 3-2
3-26
Fixed-step size (fundamental sample time)
Description
When you use a fixed-step solver, the Fixed-step size (fundamental sample time) parameter
specifies the size of the fixed step the solver takes during simulation.
When you configure a referenced model to use a local solver, the Fixed-step size (fundamental
sample time) parameter of the referenced model specifies the step size for the local solver.
Dependencies
To enable this parameter:
Settings
auto | positive scalar double
auto
By default, the fixed step size is auto. The software determines the appropriate step size for the
simulation according to these rules:
• If the model includes periodic discrete sample times, the software chooses a step size equal to
the greatest common divisor of the periodic sample times in the model. This step size ensures
that the simulation takes a step for every sample time in the model.
• If the model does not include periodic discrete sample times and specifies a finite sample time,
the solver chooses a step size that divides the simulation into 50 equal steps.
tstop − tstart
hmax =
50
• If the model does not include periodic sample times and specifies the stop time as Inf, the
simulation uses a step size of 0.2.
• If the model has no periodic sample times and uses Sine Wave or Signal Generator blocks, the
software also considers the maximum frequency for the periodic signals generated by the
source blocks. The step size is calculated to ensure that the step size is no smaller than one
third of the minimum period of a periodic signal in the model, determined as the inverse of the
maximum frequency Freqmax.
For a simulation with a finite stop time, if one third of the minimum period is smaller than the
step size calculated to divide the simulation into fifty even steps, the simulation uses the step
size determined using the maximum frequency.
tstop − tstart 1 1
hmax = min ,
50 3 Freqmax
3-27
3 Solver Parameters
For a simulation with infinite stop time, if one third of the minimum period is smaller than
0.2, the simulation uses the step size determined using the maximum frequency.
tstop − tstart 1 1
hmax = min ,
50 3 Freqmax
• When the model is configured to start the simulation from an initial state specified as a
Simulink.op.ModelOperatingPoint object, the software uses the fixed step size stored in
the ModelOperatingPoint object.
When you allow the solver to determine the fixed step size, you can see the value that the solver
determines several ways:
• Once the model is compiled, the Solver information window and tooltip provide information
about the solver and fixed step size. To see the solver information, click or pause on the solver
information string in the lower-right corner of the Simulink Editor.
Several actions result in compiling the model, including updating the block diagram and
simulating the model.
• When you use the get_param function to get the value of the FixedStep parameter, the
function returns 'auto' if the parameter value is specified as auto. Once the model is
compiled, you can programmatically access the fixed step size chosen by the software by using
the get_param function to get the value of the CompiledStepSize parameter.
fixedStepSize = get_param("mdlName","CompiledStepSize");
• When you return simulation results as a single simulation output object, the metadata in the
Simulink.SimulationOutput object includes the fixed step size used in the simulation. The
fixed step size is stored as part of the model information in the
Simulink.SimulationMetadata object, in the solver information.
simMetadata = getSimulationMetadata(out);
simModelInfo = simMetadata.ModelInfo;
simSolverInfo = simModelInfo.SolverInfo;
simFixedStep = simSolverInfo.FixedStepSize;
The specified step size must be less than or equal to the smallest discrete sample time in the
model, and all discrete sample times in the model must be evenly divisible by the specified step
size.
3-28
Fixed-step size (fundamental sample time)
• The local step size must be less than or equal to the communication step size, which
determines the rate at which the parent and local solvers exchange data.
When the parent solver is a fixed-step solver, the local solver step size must be an integer
multiple of the parent solver step size.
• When the local step size is smaller than the communication step size, the communication step
size must be evenly divisible by the local step size.
For example, when the communication step size is 0.1 seconds, the local solver can be 0.1
seconds, 0.05 seconds, 0.025 seconds, and so on.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: FixedStep
Type: string | character vector
Value: "auto" | positive scalar number
Default: "auto"
Parameter: CompiledStepSize
Type: string | character vector
Value: positive scalar number
Version History
Introduced before R2006a
See Also
Topics
“Solver Pane” on page 3-2
“Use Local Solvers in Referenced Models”
3-29
3 Solver Parameters
Description
Specify the size of the first time step, in seconds, for the variable-step solver.
Dependencies
To enable this parameter, set the solver Type to Variable-step.
Settings
auto (default) | scalar number
By default, the Initial step size value is auto, which indicates that the solver determines the initial
step size by examining the derivatives of the states at the start of the simulation.
Be careful when specifying an initial step size other than auto. If the first step size is too large, the
solver might step over important behavior.
When you specify an initial step size, the solver takes a smaller step than specified when error
criteria are not met.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: InitialStep
Type: string | character vector
Value: scalar number
Default: 'auto'
Version History
Introduced before R2006a
3-30
Initial step size
See Also
Topics
“Sample Times in Systems and Subsystems”
“Improve Simulation Performance Using Performance Advisor”
“Solver Pane” on page 3-2
3-31
3 Solver Parameters
Description
When you allow the software to automatically handle rate transitions by inserting Rate Transition
blocks, use this parameter to specify how the software sets the Ensure deterministic data transfer
parameter for the automatically inserted blocks.
Dependencies
To enable this parameter when the solver Type is Variable-step, select Automatically handle
data transition for data transfer.
Settings
Whenever possible (default) | Always | Never (minimum delay)
Whenever possible
The software selects the Ensure deterministic data transfer (maximum delay) parameter for
automatically inserted Rate Transition blocks when the block handles data transfer between two
periodic sample rates that are related by an integer factor. For Rate Transition blocks that handle
data transfer between sample rates that are not periodic or are not related by an integer factor,
the software does not select the Ensure deterministic data transfer (maximum delay)
parameter.
Always
The software always selects the Ensure deterministic data transfer (maximum delay)
parameter for automatically inserted Rate Transition blocks.
The software issues an error if you select this option and the model automatically inserts a Rate
Transition block to handle data transfer between two sample times that are not periodic sample
times related by an integer factor.
Never (minimum delay)
The software never selects the Ensure deterministic data transfer (maximum delay)
parameter for automatically inserted Rate Transition blocks.
Clearing the Ensure deterministic data transfer (maximum delay) parameter can provide
reduced latency for models that do not require determinism. For more information, see Rate
Transition.
3-32
Deterministic data transfer
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: InsertRTBMode
Type: string | character vector
Values: 'Always' | 'Whenever possible' | 'Never (minimum delay)'
Default: 'Whenever possible'
Version History
Introduced in R2008a
See Also
Model Settings
Automatically handle rate transition for data transfer
Blocks
Rate Transition
Topics
“Rate Transition Block Options” (Simulink Coder)
“Solver Pane” on page 3-2
3-33
3 Solver Parameters
Description
This parameter specifies how many steps the solver can take that are less than or equal to the
minimum step size before a minimum step size violation occurs. When a minimum step size violation
occurs, the software issues a diagnostic based on the value of the Min step size violation
parameter.
To specify the minimum step size, use the Min step size parameter.
Dependencies
To enable this parameter:
Settings
1 (default) | positive scalar integer
By default, the software issues a diagnostic when the solver takes any consecutive steps that are less
than or equal to the minimum step size. To allow more consecutive steps that are less than or equal to
the minimum step size to occur, specify a larger number as a positive scalar integer value.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MaxConsecutiveMinStep
Type: string | character vector
Value: positive scalar integer
Default: '1'
3-34
Number of consecutive min steps
Version History
Introduced before R2006a
See Also
Topics
“Choose a Solver”
Min step size violation
Min step size
“Solver Pane” on page 3-2
3-35
3 Solver Parameters
Description
The software counts the number of consecutive zero crossings detected and issues a diagnostic when
the count exceeds the amount specified by this parameter. You can specify whether the diagnostic is a
warning or an error using the Consecutive zero-crossings violation parameter. The counter resets
when the simulation progresses without detecting another zero crossing long enough for the next
zero crossing to be considered nonconsecutive. To specify how close zero crossings must occur to be
considered consecutive, use the Time tolerance parameter.
Dependencies
To enable this parameter, set the solver Type to Variable-step and set Zero-crossing control to
either Use local settings or Enable all.
Settings
1000 (default) | positive scalar integer
If your model experiences excessive zero crossings, you can increase this parameter value to increase
the threshold at which the software issues the Consecutive zero-crossings violation diagnostic.
Allowing more consecutive zero crossings can give the model behavior more time to recover.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MaxConsecutiveZCs
Type: string | character vector
Value: positive scalar integer
Default: '1000'
Version History
Introduced before R2006a
3-36
Number of consecutive zero crossings
See Also
Time tolerance | Consecutive zero-crossings violation | Zero-crossing control
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-37
3 Solver Parameters
Maximum order
Order of numerical differentiation formulas used for ode15s solver
Description
Specify the order of the numerical differentiation formulas (NDFs) used for the ode15s solver.
Dependencies
To enable this parameter:
Settings
5 (default) | 4 | 3 | 2 | 1
The number you select specifies the order of the NDFs used by the ode15s solver. For example, when
you select 3, the ode15s solver uses third order NDFs.
Using higher order NDFs produces a more accurate result, but the solver is less stable.
For stiff systems that require more stability, reduce the maximum order to 2, which is the highest
order for which the NDFs are A-stable. Alternatively, try the ode23s solver, which is a lower order
and A-stable solver.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MaxOrder
Type: scalar
Value: 1 | 2 | 3 | 4 | 5
Default: 5
3-38
Maximum order
Version History
Introduced before R2006a
See Also
Topics
“Error Tolerances for Variable-Step Solvers”
“Improve Simulation Performance Using Performance Advisor”
“Solver Pane” on page 3-2
3-39
3 Solver Parameters
Description
Specify the largest time step, in seconds, for the variable-step solver to take in simulation.
Dependencies
To enable this parameter, set the solver Type to Variable-step.
Settings
auto (default) | scalar
By default, the Max step size value is auto, which indicates that the solver determines the
maximum step size to use in the simulation. The way the solver determines the maximum step size
depends on the type of variable-step solver selected.
• When the Solver parameter value is discrete (no continuous states), the solver uses the
smallest sample time in the model as the maximum step size.
• When the Solver parameter value is something other than discrete (no continuous
states), the maximum step size is determined based on the specified Start time and Stop time.
• When the stop time is inf or is equal to the start time, the maximum step size is 0.2.
• For all other stop time values, the maximum step size is chosen such that the simulation has at
least 50 time hits.
tstop − tstart
hmax =
50
• When your model includes a Sine Wave block or a Signal Generator block, the maximum step size
is determined based on the highest specified frequency in the model Freqmax. The software
ensures that the maximum step size results in a sample rate larger than the Nyquist rate for all
periodic signals in the model.
tstop − tstart 1 1
hmax = min ,
50 3 Freqmax
When the model is configured to start the simulation from an initial state specified as a
Simulink.op.ModelOperatingPoint object, if the Max step size parameter value is auto, the
software uses the maximum step size stored in the ModelOperatingPoint object.
Generally, the solver determines an appropriate maximum step size. Consider specifying the
maximum step size when:
• You simulate the model over a large time span. For long time spans, the step size the solver
chooses might be too large to find the solution.
3-40
Max step size
• Your model contains periodic or nearly periodic behavior, and you know the period. Specify the
maximum step size to a fraction of the period, such as 1/4.
• You are concerned about the solver missing significant behavior when using the solver-determined
maximum step size.
Examples
To allow the software to select the solver to use for the model, specify the Type parameter as Fixed-
step or Variable-step, and set the Solver parameter to auto. For this example, configure the
software to select a variable-step solver for the model.
1 To open the Configuration Parameters dialog box, on the Modeling tab, click Model Settings.
2 On the Solver pane, set the solver Type to Variable-step and the Solver parameter to auto
(Automatic solver selection).
3 Click OK.
Alternatively, use the set_param function to set the parameter values programmatically.
set_param(mdl,"SolverType","Variable-step", ...
"SolverName","VariableStepAuto")
Simulate the model. On the Simulation tab, click Run. Alternatively, use the sim function.
out = sim(mdl);
As part of initializing the simulation, the software analyzes the model to select the solver. The status
bar on the bottom of the Simulink Editor indicates the selected solver on the right. For this model, the
software selects the ode45 solver.
To view more information about the selected solver parameters, click the text in the status bar that
indicates the selected solver. The Solver Information menu shows the selected solver and the selected
3-41
3 Solver Parameters
value for the Max step size parameter. For this simulation, the solver uses a maximum step size of
0.4.
If you want to lock down the solver selection and maximum step size, explicitly specify the solver
parameter values. In the Solver information menu, click Accept suggested settings .
Alternatively, you can use the set_param function to specify the parameter values programmatically.
set_param(mdl,"SolverName","ode45","MaxStep","0.4")
After you explicitly specify the parameter values, the solver information in the status bar and Solver
information menu no longer indicate that the parameter values are automatically selected.
Tips
Selecting Enable decoupled continuous integration can allow the solver to determine a larger
maximum step size when the Max step size parameter is set to auto.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
3-42
Max step size
Application Setting
Safety precaution No impact
Programmatic Use
Parameter: MaxStep
Type: string | character vector
Value: numeric scalar
Default: 'auto'
Version History
Introduced before R2006a
See Also
Topics
“Sample Times in Systems and Subsystems”
“Solver Pane” on page 3-2
3-43
3 Solver Parameters
Description
When a discontinuity, or zero crossing, is detected in a simulation where you have zero-crossing
detection enabled, the solver tries to determine the time at which the zero crossing occurred through
an iterative process. This parameter specifies the maximum number of iterations the solver performs
to locate the time of the zero-crossing.
You can adjust the bounded computational cost of the fixed-step zero-crossing algorithm using this
parameter and the Maximum number of zero-crossings per step parameter.
Dependencies
To enable this parameter:
Settings
10 (default) | positive scalar integer
Allowing the solver to perform more iterations to locate each zero crossing can produce a more
accurate result but is more computationally intensive.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MaxZcBracketingIterations
Type: numeric
Value: positive scalar integer
Default: 10
3-44
Maximum number of bracketing iterations
Version History
Introduced in R2022a
See Also
Topics
“Zero-Crossing Detection”
“Zero-Crossing Detection with Fixed-Step Simulation”
“Zero-Crossing Algorithms”
“Use Fixed-Step Zero-Crossing Detection for Faster Simulations”
3-45
3 Solver Parameters
Description
When a discontinuity, or zero crossing, is detected in a simulation where you have zero-crossing
detection enabled, the solver tries to determine the time at which the zero crossing occurred through
an iterative process. This parameter specifies the maximum number of zero crossings the solver tries
to locate within a single simulation time step.
You can adjust the bounded computational cost of the fixed-step zero-crossing algorithm using this
parameter and the Maximum number of zero-crossings per step parameter.
Category: Solver
Dependencies
To enable this parameter:
Settings
2 | positive scalar integer
Allowing the solver to detect more zero crossings per step can produce a more accurate solution but
is more computationally intensive.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MaxZcPerStep
Type: numeric
Value: positive scalar integer
Default: 2
3-46
Maximum number of zero-crossings per step
Version History
Introduced in R2022a
See Also
Topics
“Zero-Crossing Detection”
“Zero-Crossing Detection with Fixed-Step Simulation”
“Zero-Crossing Algorithms”
“Use Fixed-Step Zero-Crossing Detection for Faster Simulations”
3-47
3 Solver Parameters
Description
Specify the smallest time step, in seconds, for the variable-step solver to take in simulation.
Dependencies
To enable this parameter, set the solver Type to Variable-step.
Settings
auto (default) | positive scalar number
By default, the Min step size parameter value is auto, and the software determines a minimum step
size on the order of machine precision.
When you specify the minimum step size as auto or as a positive scalar number, the software allows
the solver to take an unlimited number of steps of the specified size.
Tips
• To specify how many times the software allows the solver to take a step of the specified size before
issuing a diagnostic, use the Number of consecutive min steps parameter.
• To specify the diagnostic behavior when the solver exceeds the number of specified minimum-
sized steps, use the Min step size violation parameter.
• When the solver needs to take a smaller step to meet error tolerances, the software issues a
warning that indicates the current effective relative tolerance.
• The Min step size parameter determines the step size of the variable-step ODE solver. The size is
limited by the smallest discrete sample time in the model.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
3-48
Min step size
Programmatic Use
Parameter: MinStep
Type: string | character vector
Value: 'auto' | positive scalar number
Default: 'auto'
Version History
Introduced before R2006a
See Also
Max step size | Number of consecutive min steps | Min step size violation
Topics
“Sample Times in Systems and Subsystems”
“Solver Pane” on page 3-2
3-49
3 Solver Parameters
Description
The ode14x and ode1be solvers use Newton's method to compute the model states for the next time
step using the state values in the current time step. Use this parameter to specify the number of
Newton's method iterations for the solver to use in each time step.
Dependencies
To enable this parameter when the solver Type is Fixed-step, from the Solver list, select ode14x
(extrapolation).
Settings
1 | scalar integer between 1 and 2147483647
More Newton's method iterations produce a more accurate solution but increases the computational
intensity for each simulation step.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: NumberNewtonIterations
Type: scalar integer
Value: scalar integer between 1 and 2147483647
Default: 1
3-50
Number of Newton's iterations
Version History
Introduced before R2006a
See Also
Topics
“Fixed Step Solvers in Simulink”
“Purely Discrete Systems”
“Solver Pane” on page 3-2
3-51
3 Solver Parameters
Integration method
Integration for nonadaptive odeN variable-step solver
Description
Choose which solver to use to integrate states on each time step of a simulation that uses the
nonadaptive odeN variable-step solver.
Dependencies
To enable this parameter:
Settings
ode3 (Bogacki-Shampine) (default) | ode8 (Dormand-Price) | ode5 (Dormand-Price) |
ode4 (Runge-Kutta) | ode2 (Heun) | ode1 (Euler) | ode14x (extrapolation) | ode1be
(Backward Euler)
Select the solver to use to integrate states during simulation. The number in the solver name
indicates the order of the solver. For more information about each solver option, see Solver.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ODENIntegrationMethod
Type: string | character vector
Value: 'ode1' | 'ode2' | 'ode3' | 'ode4' | 'ode5' | 'ode8' | 'ode14x' | 'ode1be'
Default: 'ode3'
Version History
Introduced in R2020a
3-52
Integration method
See Also
Solver | Max step size
Topics
“Solver Pane” on page 3-2
“Fixed-Step Continuous Solvers”
“Fixed-Step Versus Variable-Step Solvers”
3-53
3 Solver Parameters
Description
Use this option to indicate whether a higher task priority is indicated by a lower value or a higher
value in the real-time target. Code generation uses this information to implement asynchronous data
transfers.
Settings
off (default) | on
Default: Off
on
The real-time system assigns higher priority values to higher priority tasks. For example, a task
with a priority value of 8 has a higher task priority than a task with a priority value of 4.
Rate Transition blocks treat asynchronous transitions from a rate with a lower priority value to a
rate with a higher priority value as a low-to-high rate transitions.
off
The real-time system assigns lower priority values to higher priority tasks. For example, a task
with a priority value of 4 has a higher task priority than a task with a priority value of 8.
Rate Transition blocks treat asynchronous transitions from a rate with a lower priority value to a
rate with a higher priority value as high-to-low rate transitions.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: PositivePriorityOrder
Type: string | character vector
Value: 'on' | 'off'
Default: 'off'
3-54
Higher priority value indicates higher task priority
Version History
Introduced in R2006b
See Also
Topics
“Rate Transitions and Asynchronous Blocks” (Simulink Coder)
“Solver Pane” on page 3-2
3-55
3 Solver Parameters
Relative tolerance
Relative tolerance for solver tolerance calculation
Description
Specify the largest acceptable solver error, relative to the size of each state during each time step. If
the relative error exceeds this tolerance, the solver reduces the time step size.
The acceptable error considered for each state on each time step is determined by either the relative
tolerance or the absolute tolerance, whichever results in a larger tolerance. The solver calculates the
acceptable error based on the relative tolerance by multiplying the relative tolerance and the state
value.
ei = reltol * |x|,
where:
When ei is larger than the value specified for the Absolute tolerance parameter, the relative
tolerance determines the tolerance for that state on that time step. When the absolute tolerance is
greater than ei, the absolute tolerance determines the tolerance for that state on that time step. In
general, the absolute tolerance applies when the state values approach zero.
Dependencies
To enable this parameter:
Settings
1e-3 (default) | auto | positive scalar number
3-56
Relative tolerance
The relative tolerance indicates the tolerance allowed for the computational accuracy of the variable-
step solver as a percentage of each state value. The default value 1e-3 indicates that the computed
state value at each time step must be accurate within 0.1%.
The default relative tolerance is appropriate for most applications. Decreasing the relative tolerance
can slow simulation.
When you specify the Relative tolerance as auto, the software uses the default value of 1e-3.
Tips
To assess the accuracy of a simulation, reduce the relative tolerance to 1e-4 and simulate the model
again. If the results of the two simulations are not significantly different, the solution has converged.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: RelTol
Type: string | character vector
Value: positive scalar number
Default: '1e-3'
Version History
Introduced before R2006a
See Also
Topics
“Error Tolerances for Variable-Step Solvers”
“Improve Simulation Performance Using Performance Advisor”
“Solver Pane” on page 3-2
3-57
3 Solver Parameters
Description
You can specify constraints on sample times for simulations that use a fixed-step solver. When the
model does not satisfy the specified constraint, the software issues a diagnostic.
Dependencies
To enable this parameter, set the solver Type to Fixed-step.
Settings
Unconstrained (default) | Ensure sample time independent | Specified
Unconstrained
The software imposes no constraints on sample times in the model.
When you select this option, the software assigns priority 40 to the sample time that corresponds
to the fixed step size for the simulation. The software increments or decrements from 40 to assign
priorities to other rates in the model according to the value of the Higher priority value
indicates higher task priority parameter. Continuous sample times always have the highest
priority.
The software checks to ensure that this model can inherit its sample times from a model that
references it without altering its behavior. Models that specify a fixed step size cannot satisfy this
constraint.
Specified
The software checks to ensure that the model operates at a specified set of prioritized periodic
sample times. When you select this option, you must specify properties for each sample time you
3-58
Periodic sample time constraint
use in the model. The software issues a diagnostic when the model uses a sample time that is not
specified. During simulation, higher priority tasks run first and can interrupt lower priority tasks
as needed. Use the Sample time properties parameter to specify the rates and priorities for
sample times in the model.
For information about how to use this option for multitasking models, see “Tasking Modes and
Execution Order” (Simulink Coder).
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Specified or Ensure sample time independent
Programmatic Use
Parameter: SampleTimeConstraint
Value: 'unconstrained' | 'STIndependent' | 'Specified'
Default: 'unconstrained'
Version History
Introduced before R2006a
See Also
Fixed-step size (fundamental sample time)
Topics
“Referenced Model Sample Times”
“Tasking Modes and Execution Order” (Simulink Coder)
“S-Functions That Specify Sample Time Inheritance Rules” (Simulink Coder)
“Conditionally Execute Referenced Models”
“Function-Call Models”
“Solver Pane” on page 3-2
3-59
3 Solver Parameters
Description
Specify priority for each sample time in the model.
Dependencies
To enable this parameter, set the Periodic sample time constraint parameter to Specified.
Settings
n-by-3 matrix
Specify the sample time properties as an n-by-3 matrix where n is equal to the number of discrete
sample times in the model. Each row of the matrix has this form:
Specify the sample time properties in order from highest priority to lowest priority. During
simulation, higher priority tasks run first and can interrupt lower priority tasks as needed. Faster
rates must have higher priorities. Continuous sample time always has the highest priority.
For example, specifying the value as [[0.1, 0, 10]; [0.2, 0, 11]; [0.3, 0, 12]]:
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
3-60
Sample time properties
Application Setting
Safety precaution Period, offset, and priority of each sample time in
the model
Programmatic Use
Parameter: SampleTimeProperty
Type: structure
Value: n-by-3 matrix
Default: []
Version History
Introduced in R2007a
See Also
Topics
“Purely Discrete Systems”
“Specify Sample Time”
“Solver Pane” on page 3-2
3-61
3 Solver Parameters
Shape preservation
Option to preserve shape of states using derivative information at each time step
Description
Shape preservation uses the information about state derivatives at each time step to preserve the
shape of each state and improve simulation accuracy.
Dependencies
To enable this parameter:
Settings
Disable all (default) | Enable all
Disable all
No shape preservation performed for any states. This option typically provides sufficient accuracy
for most models.
Enable all
Shape preservation performed for all states. This option can increase accuracy in models with
state derivatives that have high rates of change. Shape preservation increases computational
complexity and might decrease simulation speed.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ShapePreserveControl
Type: string | character vector
Value: 'EnableAll' | 'DisableAll'
Default: 'DisableAll'
3-62
Shape preservation
Version History
Introduced in R2008a
See Also
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-63
3 Solver Parameters
Solver
Solver that computes states and outputs for simulation
Description
The Solver parameter specifies the solver that computes the states of the model during simulation
and in generated code. In the process of solving the set of ordinary differential equations that
represent the system the model implements, the solver also determines the next time step for the
simulation.
When you enable the Use local solver when referencing model parameter for a referenced model,
the Solver parameter for the referenced model specifies the solver to use as a local solver. The local
solver solves the referenced model as a separate set of differential equations. While the top solver
can be a fixed-step or variable-step solver, the local solver must be a fixed-step solver. For more
information, see “Use Local Solvers in Referenced Models”.
Variable-Step Solvers
A variable-step solver adjusts the interval between simulation time hits where the solver computes
states and outputs based on the system dynamics and specified error tolerance. For most variable-
step solvers, you can configure additional parameters, including:
Fixed-Step Solvers
In general, fixed-step solvers except for ode14x and ode1be calculate the next step using this
formula:
where X is the state, h is the step size, and dX is the state derivative. dX(n) is calculated by a
particular algorithm using one or more derivative evaluations depending on the order of the method.
For most fixed-step solvers, you can configure additional parameters, including:
Settings
auto (Automatic solver selection) (default) | discrete (no continuous states) | ...
3-64
Solver
In general, the automatic solver selection chooses an appropriate solver for each model. The choice
of solver depends on several factors, including the system dynamics and the stability of the solution.
For more information, see “Choose a Solver”.
The options available for this parameter depend on the value you select for the solver Type.
Variable-Step Solvers
For crude tolerance and in the presence of mild stiffness, the ode23 solver is more efficient than
the ode45 solver.
ode113 (Adams)
The ode113 solver computes the model states using a variable-order Adams-Bashforth-Moulton
PECE numerical integration technique.
The ode113 solver uses the solutions from several preceding time points to compute the current
solution.
The ode113 solver can be more efficient than ode45 for stringent tolerances.
ode15s (stiff/NDF)
The ode15s solver computes the model states using variable-order numerical differentiation
formulas (NDFs). NDFs are related to but more efficient than the backward differentiation
formulas (BDFs), also known as Gear's method.
The ode15s solver uses the solutions from several preceding time points to compute the current
solution.
The ode15s solver is efficient for stiff problems. Try this solver if the ode45 solver fails or is
inefficient.
ode23s (stiff/Mod. Rosenbrock)
The ode23s solver computes the model states using a modified second-order Rosenbrock
formula.
The ode23s solver uses only the solution from the preceding time step to compute the solution
for the current time step.
3-65
3 Solver Parameters
The ode23s solver is more efficient than the ode15s solver for crude tolerances and can solve
stiff problems for which ode15s is ineffective.
ode23t (mod. stiff/Trapezoidal)
The ode23t solver computes the model states using an implementation of the trapezoidal rule.
The ode23t solver uses only the solution from the preceding time step to compute the solution
for the current time step.
Use the ode23t solver for problems that are moderately stiff and require a solution with no
numerical damping.
ode23tb (stiff/TR-BDF2)
The ode23tbsolver computes the model states using a multistep implementation of TR-BDF2, an
implicit Runge-Kutta formula with a trapezoidal rule first stage and a second stage that consists
of a second-order backward differentiation formula. By construction, the same iteration matrix is
used in both stages.
The ode23tb solver is more efficient than ode15s for crude tolerances and can solve stiff
problems for which the ode15s solver is ineffective.
odeN (Nonadaptive)
The odeN solver uses a nonadaptive fixed-step integration formula to compute the model states as
an explicit function of the current value of the state and the state derivatives approximated at
intermediate points.
The nonadaptive odeN solver does not adjust the simulation step size to satisfy error constraints
but does reduce step size in some cases for zero-crossing detection and discrete sample times.
daessc (DAE solver for Simscape)
The daessc solver computes the model states by solving systems of differential algebraic
equations modeled using Simscape. The daessc solver provides robust algorithms specifically
designed to simulate differential algebraic equations that arise from modeling physical systems.
Fixed-Step Solvers
3-66
Solver
ode5 (Dormand-Prince)
The ode5 solver uses the fifth-order Dormand-Prince formula to compute the model state as an
explicit function of the current value of the state and the state derivatives approximated at
intermediate points.
ode4 (Runge-Kutta)
The ode4 solver uses the fourth-order Runge-Kutta (RK4) formula to compute the model state as
an explicit function of the current value of the state and the state derivatives.
ode3 (Bogacki-Shampine)
The ode3 solver computes the state of the model as an explicit function of the current value of
the state and the state derivatives. The solver uses the Bogacki-Shampine Formula integration
technique to compute the state derivatives.
ode2 (Heun)
The ode2 solver uses the Heun integration method to compute the model state as an explicit
function of the current value of the state and the state derivatives.
ode1 (Euler)
The ode1 solver uses the Euler integration method to compute the model state as an explicit
function of the current value of the state and the state derivatives. This solver requires fewer
computations than a higher order solver but provides comparatively less accuracy.
ode14x (extrapolation)
The ode14x solver uses a combination of Newton's method and extrapolation from the current
value to compute the model state as an implicit function of the state and the state derivative at
the next time step. In this example, X is the state, dX is the state derivative, and h is the step size:
This solver requires more computation per step than an explicit solver but is more accurate for a
given step size.
ode1be (Backward Euler)
The ode1be solver is a Backward Euler type solver that uses a fixed number of Newton iterations
and incurs a fixed computational cost. You can use the ode1be solver as a computationally
efficient fixed-step alternative to the ode14x solver.
Examples
mdl = "vdp";
open_system(mdl)
3-67
3 Solver Parameters
To allow the software to select the solver to use for the model, specify the Type parameter as Fixed-
step or Variable-step, and set the Solver parameter to auto. For this example, configure the
software to select a variable-step solver for the model.
1 To open the Configuration Parameters dialog box, on the Modeling tab, click Model Settings.
2 On the Solver pane, set the solver Type to Variable-step and the Solver parameter to auto
(Automatic solver selection).
3 Click OK.
Alternatively, use the set_param function to set the parameter values programmatically.
set_param(mdl,"SolverType","Variable-step", ...
"SolverName","VariableStepAuto")
Simulate the model. On the Simulation tab, click Run. Alternatively, use the sim function.
out = sim(mdl);
As part of initializing the simulation, the software analyzes the model to select the solver. The status
bar on the bottom of the Simulink Editor indicates the selected solver on the right. For this model, the
software selects the ode45 solver.
To view more information about the selected solver parameters, click the text in the status bar that
indicates the selected solver. The Solver Information menu shows the selected solver and the selected
value for the Max step size parameter. For this simulation, the solver uses a maximum step size of
0.4.
3-68
Solver
If you want to lock down the solver selection and maximum step size, explicitly specify the solver
parameter values. In the Solver information menu, click Accept suggested settings .
Alternatively, you can use the set_param function to specify the parameter values programmatically.
set_param(mdl,"SolverName","ode45","MaxStep","0.4")
After you explicitly specify the parameter values, the solver information in the status bar and Solver
information menu no longer indicate that the parameter values are automatically selected.
Tips
• The optimal solver balances acceptable accuracy with the shortest simulation time. Identifying the
optimal solver for a model requires experimentation. For more information, see “Choose a Solver”.
• When you use fast restart, you can change the solver for the simulation without having to
recompile the model.
• The software uses a discrete solver for models that have no states or have only discrete states,
even if you specify a continuous solver.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Discrete (no continuous states)
Programmatic Use
Parameter: SolverName or Solver
Type: string | character vector
Variable-Step Solver Values: "VariableStepAuto" | "VariableStepDiscrete" | "ode45" |
"ode23" | "ode113" | "ode15s" | "ode23s" | "ode23t" | "ode23tb" | "odeN" | "daessc"
Fixed-Step Solver Values: "FixedStepAuto" | "FixedStepDiscrete" | "ode8" | "ode5" |
"ode4" | "ode3" | "ode2" | "ode1" | "ode14x" | "ode1be"
3-69
3 Solver Parameters
Default: "VariableStepAuto"
Version History
Introduced before R2006a
See Also
Topics
“Compare Solvers”
“Choose a Solver”
“Sample Times in Systems and Subsystems”
“Solver Pane” on page 3-2
3-70
Solver Jacobian Method
Description
Selecting a sparse Jacobian method might improve simulation speed for models with many continuous
states.
Dependencies
To enable this parameter, configure your model with one of these parameter combinations:
• Set the solver Type to Variable-step and use the Solver parameter to select one of these
implicit solvers:
• ode15s (stiff/NDF)
• ode23s (stiff/Mod. Rosenbrock)
• ode23t (mod. stiff/Trapezoidal)
• ode23tb (stiff/TR-BDF2)
• daessc (DAE solver for Simscape)
• Set the solver Type to Variable-step. For the Solver parameter, select odeN (Nonadaptive).
Then, for the Integration method parameter, select ode14x (extrapolation).
• Set the solver Type to Fixed-step and set the Solver parameter to ode14x (extrapolation)
or ode1be (Backward Euler).
Settings
auto (default) | Sparse perturbation | Full perturbation | Sparse analytical | Full
analytical
By default, the software chooses the Jacobian method. For most models, the solver chooses a Jacobian
method with sufficient accuracy.
When a referenced model configured to use a local solver has an implicit top solver or parent solver,
this parameter value must be auto or Full perturbation.
For more information, see “Choose a Jacobian Method for an Implicit Solver”.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
3-71
3 Solver Parameters
Application Setting
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: SolverJacobianMethodControl
Type: string | character vector
Value: 'auto' | 'SparsePerturbation' |'FullPerturbation' | 'SparseAnalytical' |
'FullAnalytical'
Default: 'auto'
Version History
Introduced in R2010b
See Also
Topics
“Choose a Solver”
“Solver Pane” on page 3-2
3-72
Solver reset method
Description
Solver resets happen in response to certain simulation conditions, such as zero crossings. Use this
parameter to prioritize solver reset speed against computational accuracy as needed for your model.
Dependencies
To enable this parameter:
Settings
Fast (default) | Robust
Fast
The solver does not recompute the Jacobian matrix for each solver reset.
Selecting this option can improve simulation performance but simulations might produce
inaccurate results.
Robust
The solver does recompute the Jacobian matrix for each solver reset.
If you suspect simulation results are incorrect, simulate with the robust solver reset method. If
the simulation results do not change, revert back to the fast solver reset method.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: SolverResetMethod
3-73
3 Solver Parameters
Version History
Introduced before R2006a
See Also
Topics
“Choose a Solver”
“Solver Pane” on page 3-2
3-74
Type
Type
Choice of variable- or fixed-step solver
Description
The Type parameter specifies whether to use a variable-step or a fixed-step solver to simulate the
model. Both variable-step and fixed-step solvers have additional solver settings, including a choice of
the solver to use.
When you configure a referenced model to use a local solver, the Type parameter for the referenced
model specifies the local solver type, which must be Fixed-step. For more information, see “Use
Local Solvers in Referenced Models”.
Settings
Variable-step (default) | Fixed-step
Variable-step
Step size varies from step to step, depending on model dynamics. A variable-step solver:
• Reduces step size when model states change rapidly, to maintain accuracy
• Increases step size when model states change slowly, to avoid unnecessary steps
A variable-step solver is recommended for models in which states change rapidly and models that
contain discontinuities. In these cases, a variable-step solver requires fewer time steps than a
fixed-step solver to achieve a comparable level of accuracy, which can significantly shorten
simulation time.
Fixed-step
Step size remains constant throughout the simulation. The solver computes the next simulation
time hit as the sum of the current simulation time and the step size.
Code generation requires a fixed-step solver. Typically, lower-order solvers are computationally
more efficient than higher-order solvers. However, lower-order solvers are also less accurate than
higher-order solvers.
When you configure a referenced model to use a local solver, the top solver can be a variable-step
or fixed-step solver, and the local solver must be a fixed-step solver. For more information, see
“Use Local Solvers in Referenced Models”.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
3-75
3 Solver Parameters
Application Setting
Debugging Fixed-step
Traceability Fixed-step
Efficiency Fixed-step
Safety precaution Fixed-step
Programmatic Use
Parameter: SolverType
Type: string | character vector
Values: "Variable-step" | "Fixed-step"
Default: "Variable-step"
Version History
Introduced before R2006a
See Also
Topics
“Choose a Solver”
“Purely Discrete Systems”
“Solver Pane” on page 3-2
3-76
Start time
Start time
Simulation start time
Description
Specify the start time for the simulation in seconds, as a double-precision value. The start time
specifies the first time value for which the simulation computes a result and the time from which the
simulation engine propagates time.
Settings
0.0 (default) | scalar number
• The start time must be less than or equal to the stop time.
• The values of block parameters with initial conditions must match the initial condition settings at
the specified start time.
• Simulation time is not the same as clock time. For example, running a simulation for 10 seconds
usually does not take 10 seconds. Total simulation time depends on many factors, such as model
complexity, solver step size, and system speed.
• When you use a fixed-step solver, the start time for the simulation must be zero or an integer
multiple of the fixed time step for the simulation. When you specify a start time that does not
satisfy this requirement, the software issues a diagnostic and changes the start time to the nearest
integer multiple of the fixed step size. To change the diagnostic behavior for this condition, use the
Automatic solver parameter selection parameter.
Examples
mdl = "vdp";
open_system(mdl)
The model is saved with a start time of 0 seconds and a stop time of 20 seconds.
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Simulate the model. To view the simulation results, double-click the Scope block. The Scope window
displays the results from the start time to the stop time.
3-77
3 Solver Parameters
out1 = sim(mdl);
Change the start time to 10 seconds and the stop time to 40 seconds.
Alternatively, use the set_param function to configure the start and stop time programmatically.
set_param(mdl,"StartTime","10","StopTime","40")
Simulate the model again. The Scope window updates to reflect the longer simulation time. The time
axis ranges from 0 to 30, with a 10-second offset indicated in the lower-right of the Scope window.
out2 = sim(mdl);
3-78
Start time
To change the start and stop time for a simulation without modifying configuration parameter values
saved in a model, use a Simulink.SimulationInput object.
As saved, the model has a start time of 0 seconds and a stop time of 20 seconds.
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Use the setModelParameter function to specify a start time of 10 seconds and a stop time of 40
seconds for the simulation.
simIn = setModelParameter(simIn,"StartTime","10",...
"StopTime","40");
3-79
3 Solver Parameters
out = sim(simIn);
The simulation uses the start time and stop time values defined on the SimulationInput object.
tFirst = out.yout{1}.Values.Time(1)
tFirst =
10
tLast = out.yout{1}.Values.Time(end)
tLast =
40
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution 0.0
Programmatic Use
Parameter: StartTime
Type: string | character vector
Values: scalar double
Default: '0.0'
Version History
Introduced before R2006a
See Also
Model Settings
Stop time | Fixed-step size (fundamental sample time)
3-80
Start time
Objects
Simulink.SimulationInput
Topics
“Solver Pane” on page 3-2
3-81
3 Solver Parameters
Stop time
Simulation stop time
Description
Specify the stop time for the simulation or generated code in seconds, as a double-precision value.
Settings
scalar
Default: 10
• The stop time must be greater than or equal to the start time.
• Specify inf to run a simulation or generated program until you explicitly pause or stop it.
• If the stop time is the same as the start time, the simulation or generated program runs for one
step.
• Simulation time is not the same as clock time. For example, running a simulation for 10 seconds
usually does not take 10 seconds. Total simulation time depends on many factors, such as model
complexity, solver step size, and system speed.
• If your model includes blocks that depend on absolute time and your design runs indefinitely, see
“Blocks That Depend on Absolute Time”.
Examples
mdl = "vdp";
open_system(mdl)
The model is saved with a start time of 0 seconds and a stop time of 20 seconds.
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Simulate the model. To view the simulation results, double-click the Scope block. The Scope window
displays the results from the start time to the stop time.
out1 = sim(mdl);
3-82
Stop time
Change the start time to 10 seconds and the stop time to 40 seconds.
Alternatively, use the set_param function to configure the start and stop time programmatically.
set_param(mdl,"StartTime","10","StopTime","40")
Simulate the model again. The Scope window updates to reflect the longer simulation time. The time
axis ranges from 0 to 30, with a 10-second offset indicated in the lower-right of the Scope window.
out2 = sim(mdl);
3-83
3 Solver Parameters
To change the start and stop time for a simulation without modifying configuration parameter values
saved in a model, use a Simulink.SimulationInput object.
As saved, the model has a start time of 0 seconds and a stop time of 20 seconds.
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Use the setModelParameter function to specify a start time of 10 seconds and a stop time of 40
seconds for the simulation.
simIn = setModelParameter(simIn,"StartTime","10",...
"StopTime","40");
3-84
Stop time
out = sim(simIn);
The simulation uses the start time and stop time values defined on the SimulationInput object.
tFirst = out.yout{1}.Values.Time(1)
tFirst =
10
tLast = out.yout{1}.Values.Time(end)
tLast =
40
get_param(mdl,"StartTime")
ans =
'0.0'
get_param(mdl,"StopTime")
ans =
'20'
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution A positive value
Programmatic Use
Parameter: StopTime
Type: string | character vector
Values: double
Default: '10.0'
Version History
Introduced before R2006a
See Also
Model Settings
Start time | Fixed-step size (fundamental sample time)
3-85
3 Solver Parameters
Objects
Simulink.SimulationInput
Topics
“Blocks That Depend on Absolute Time”
“Use Blocks to Stop or Pause a Simulation”
“Solver Pane” on page 3-2
3-86
Signal threshold
Signal threshold
State value at which adaptive zero-crossing algorithm can stop bracketing
Description
The algorithm for zero-crossing detection with a variable-step solver detects the occurrence of a zero
crossing and then locates the time at which the zero crossing occurred through a process called
bracketing. In the bracketing process, the algorithm searches for the time at which the signal value
crosses through zero. When you use the adaptive zero-crossing algorithm, the Signal threshold
specifies a tolerance on the signal value. The signal threshold allows the adaptive algorithm to stop
bracketing when the algorithm finds the time at which the signal value is close enough to zero.
Dependencies
To enable this parameter:
Settings
auto (default) | scalar number
By default, the adaptive algorithm automatically determines the signal threshold. The signal
threshold must be a scalar number greater than or equal to zero.
Using a signal threshold that is too small can decrease simulation speed.
Using a larger signal threshold can increase simulation speed, especially in systems with strong
chattering. Using a signal threshold that is too large can reduce the accuracy of simulation results.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
3-87
3 Solver Parameters
Programmatic Use
Parameter: ZCThreshold
Value: 'auto' | scalar number greater than or equal to zero
Default: 'auto'
Version History
Introduced in R2008a
See Also
Algorithm | Time tolerance | Number of consecutive zero crossings | Consecutive zero-
crossings violation | Zero-crossing control
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-88
Algorithm
Algorithm
Algorithm for zero-crossing detection with variable-step solver
Description
The algorithm for zero-crossing detection detects the occurrence of a zero crossing and then locates
the time at which the zero crossing occurred through a process called bracketing. Use this parameter
to specify whether the software uses a nonadaptive algorithm that always locates when the state
value crosses zero or an adaptive algorithm that allows for tolerance in the bracketing process.
Dependencies
To enable this parameter, set the solver Type to Variable-step and set Zero-crossing control to
either Use local settings or Enable all.
Settings
Nonadaptive (default) | Adaptive
Nonadaptive
This option uses the zero-crossing algorithm present in the Simulink software prior to Version 7.0
(R2008a). The nonadaptive algorithm detects and locates zero crossings accurately but might
decrease simulation speed for systems with strong chattering, or high-frequency oscillation
around the zero-crossing point, also known as Zeno behavior.
Adaptive
This option uses an improved zero-crossing algorithm that dynamically determines whether to use
bracketing locate the precise time at which the zero crossing occurred. The adaptive algorithm
can improve simulation speed for systems with strong chattering.
Selecting the Adaptive algorithm enables the Signal threshold parameter. The value of the
Signal threshold parameter determines when the state value is close enough to zero for the
adaptive algorithm to stop bracketing.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
3-89
3 Solver Parameters
Programmatic Use
Parameter: ZeroCrossAlgorithm
Type: string | character vector
Value: 'Nonadaptive' | 'Adaptive'
Default: 'Nonadaptive'
Version History
Introduced in R2008a
See Also
Signal threshold | Time tolerance | Number of consecutive zero crossings | Consecutive zero-
crossings violation | Zero-crossing control
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-90
Zero-crossing control
Zero-crossing control
Option to control how zero-crossing detection is enabled in the model
Description
With zero-crossing detection enabled, each time a discontinuity, or zero-crossing, is detected in
simulation, the solver determines the time at which the zero crossing occurred and uses this
information to adjust the values of continuous states in the model.
For most models, enabling zero-crossing detection speeds up simulation by allowing the solver to take
larger time steps while maintaining computational accuracy.
• When you enable zero-crossing detection for a variable-step solver, the ability to compensate state
values based on the location of the discontinuity prevents the solver from taking many small time
steps near that time.
• When you enable zero-crossing detection for a fixed-step solver, you can use a larger fixed time
step without sacrificing accuracy in models that have continuous states.
Dependencies
This parameter is always enabled when you set the solver Type to Variable-step.
To enable this parameter when you set the solver Type to Fixed-step, select Enable zero-crossing
detection for fixed-step simulation.
When you use a variable-step solver, setting Zero-crossing control to either Use local settings
or Enable all enables these parameters:
• Time tolerance
• Number of consecutive zero crossings
• Algorithm
Settings
Use local settings (default) | Enable all | Disable all
Each block reference page indicates whether that block supports zero-crossing detection. To
enable or disable the parameter that specifies whether zero-crossing detection is enabled for a
block, double-click the block to open the Block Parameters dialog box or select the block and
press Ctrl+Shift+I to open the Property Inspector. On macOS, press command+option+O
instead.
3-91
3 Solver Parameters
Enable all
This option enables zero-crossing detection for all blocks in the model that register zero crossings
regardless of the parameter setting on each block.
Disable all
This option disables zero-crossing detection for all blocks in the model that register zero
crossings regardless of the parameter setting on each block.
Tips
For models that have large dynamic changes, disabling zero-crossing detection can speed up the
simulation but can also decrease the accuracy of simulation results. For more information, see “Zero-
Crossing Detection”.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ZeroCrossControl
Type: string | character vector
Value: 'UseLocalSettings' | 'EnableAll' | 'DisableAll'
Default: 'UseLocalSettings'
Version History
Introduced before R2006a
See Also
Number of consecutive zero crossings | Consecutive zero-crossings violation | Time
tolerance
Topics
“Zero-Crossing Detection”
“Solver Pane” on page 3-2
3-92
4
The Data Import/Export pane of the Configuration Parameters dialog box includes parameters that
configure options for loading data into your model and logging simulation results. The parameters
allow you to load input signal data and initial state data into your model and to export output, signal,
and state data from simulations.
You can use built-in or custom MATLAB functions to generate input signals for a system and to graph,
analyze, and postprocess simulation results.
Parameter Description
Input Option to load external input data for simulation
using top-level input ports
Initial state Option to specify initial model state or operating
point for simulation
Time Option to log time values for simulation
States Option to log block state values during simulation
Output Option to log data for top-level output ports
Final states Option to log final state values
Format Format for logged states, output, and final states
data
Limit data points to last Option to log only last n data points for outputs,
states, and time
Decimation Option to apply decimation factor for logged
output, state, and time data
Save final operating point Option to save complete model operating point
when simulation is paused or stopped
Signal logging Option to log data for signals marked for logging
in model
Data stores Option to log data for Data Store Memory blocks
Log Dataset data to file Option to log data that uses Dataset format to
MAT file
Output options Options to produce output values at specified
times in variable-step simulation
Refine factor Option to produce additional output values
between simulation time steps
Output times Option to specify times for which variable-step
simulation produces output values
Single simulation output Option to return simulation results as single
Simulink.SimulationOutput object
Logging intervals Option to specify time intervals in which to log
simulation data
4-2
Model Configuration Parameters: Data Import/Export
Parameter Description
Record logged workspace data in Simulation Data Option to send data logged in format other than
Inspector Dataset to Data Inspector at end of simulation
Parameter Description
Dataset signal format Option to specify whether values for Dataset
elements use timeseries or timetable format
Stream To Workspace blocks Option to specify whether data logged using To
Workspace blocks streams to the Simulation Data
Inspector
See Also
Related Examples
• Importing Data from a Workspace
• “Save Simulation Data”
• “Save Signal Data Using Signal Logging”
• “Load Signal Data for Simulation”
• “Save Run-Time Data from Simulation”
4-3
4 Data Import/Export Parameters
Input
Option to load external input data for simulation using top-level input ports
Description
The Input parameter specifies whether to load external input data for top-level input ports. When
you select the Input parameter, you must also specify the external input data to load for each top-
level input port.
When you simulate a model hierarchy, only input ports in the top model load data from the
workspace. The Input parameter value for referenced models is ignored except when you simulate a
referenced model as a top model. To load data into a referenced model that is not simulated as a top
model, use a loading block other than the Inport block or In Bus Element block, for example the From
Workspace block.
Settings
off (default) | on
off
By default, the Input parameter is disabled. Leave this parameter disabled when your model does
not contain top-level input ports.
on
When your model contains top-level input ports, select the Input parameter to specify input data
to load for each port during simulation. In the text box, specify the external input data to load as
a MATLAB variable that contains the data for all top-level input ports or as a comma-separated
list where each item in the list contains data for one top-level input port. You can use several
formats to represent the data for all top-level input ports and to represent the data for each top-
level input port. For all data formats:
• Time values must have double data type and increase monotonically.
• Time and signal data must not contain Inf or NaN values.
The table summarizes supported data formats for specifying the value of the Input parameter as
a variable that contains data for all top-level input ports.
4-4
Input
time = sampleTime*(0:numSteps);
4-5
4 Data Import/Export Parameters
In addition to choosing whether to specify the data to load as a single variable or a comma-
separated list, you must also choose how to represent the input data for each port. The supported
formats depend on the way that you specify the value of the Input parameter and the type of
output produced by the port. The table summarizes the formats you can use to specify the data
for a top-level input port based on the type of output the port produces in the model.
4-6
Input
4-7
4 Data Import/Export Parameters
Simulation time
always uses units
of seconds. When
you create a
duration vector
that uses units
other than
seconds, the
software converts
the value to
seconds for use in
the simulation.
4-8
Input
4-9
4 Data Import/Export Parameters
Tips
• You can use the Root Inport Mapper to facilitate mapping input data to top-level input ports in
models with several top-level Inport or In Bus Element blocks. To open the Root Inport Mapper,
click Connect Inputs.
• You cannot use a data dictionary to store external input data for top-level input ports. The Input
parameter does not include data dictionaries when resolving the value you specify for the input
data. When a model uses a data dictionary and you disable access to the base workspace, the
Input parameter still accesses simulation input data in the base workspace. For more information
about how the software resolves symbols, see “Symbol Resolution”.
• Inport blocks in the top model interpolate and extrapolate input data values according to block
parameter values.
• In Bus Element blocks in the top model always linearly interpolate and extrapolate input data
values.
4-10
Input
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: LoadExternalInput
Value: 'on' | 'off'
Default: 'off'
Parameter: ExternalInput
Type: string | character vector
Value: Simulink.SimulationData.Dataset object | Simulink.SimulationData.DatasetRef
object | structure | array | time expression | comma-separated list where each item contains data for a
top-level input port
Default: '[t,u]'
Version History
Introduced before R2006a
See Also
Tools
Root Inport Mapper
Blocks
Inport | In Bus Element
Functions
createInputDataset
Topics
“Load Data to Root-Level Input Ports”
“Load Input Data for Bus Using In Bus Element Blocks”
“Load Big Data for Simulations”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-11
4 Data Import/Export Parameters
Initial state
Option to specify initial model state or operating point for simulation
Description
The Initial state parameter specifies whether the model loads initial states or an operating point at
the start of simulation and the initial state or operating point from which to simulate.
Settings
off (default) | on
off
By default, the model does not load initial states or an initial operating point at the start of
simulation. The simulation uses default initial states and initial conditions specified in the model.
on
The simulation starts from the specified initial state or operating point. In the text box, specify
the name of the variable that contains the initial state or operating point. For example, the initial
state could be a Simulink.op.ModelOperatingPoint object saved from a prior simulation of
the same model.
To specify the most complete initial state information, use a ModelOperatingPoint object. The
model operating point contains complete information about the state of the simulation, including
block states, hidden block states, the state of the solver and execution engine, and output values
for some blocks. When you use a model operating point as the initial state, the simulation results
are the same as a simulation that runs from the beginning. When you specify initial states using
logged states data alone, the simulation results might not match. For more information, see
“Specify Initial State for Simulation”.
When you specify logged states data as the initial state for simulation, use the Dataset,
Structure, or Structure with time format. These formats support several options that the
Array format does not support:
• Associating initial state values with the path to the block to which the state applies. This
association removes dependencies on the block execution order.
• Using different data types for each initial state value.
• Initializing a subset of states.
• Initializing states for a model hierarchy.
Array format is not recommended for specifying the initial state. By default, the software issues a
warning if you specify the initial state as an array.
Because the Array format does not include block path information, the software pairs the state
values in array with block states in the model based on:
4-12
Initial state
The execution order can change from one simulation to the next if you modify the model and from
one release to the next even if you do not modify the model. If the order of the states in the array
does not match the execution order as intended, the simulation can produce unexpected results.
Examples
mdl = "vdp";
open_system(mdl);
Configure the model to save the final operating point at the end of simulation.
Alternatively, create a Simulink.SimulationInput object to store the parameter values for the
simulation. Then, use the setModelParameter function to specify the parameter values to use in the
simulation.
simIn = Simulink.SimulationInput(mdl);
simIn = setModelParameter(simIn,"SaveFinalState","on");
simIn = setModelParameter(simIn,"SaveOperatingPoint","on");
Set the stop time for the simulation to 10 seconds. On the Simulation tab, under Simulate, in the
Stop Time box, enter 10, or use the setModelParameter function to specify the value of the
StopTime parameter for the simulation.
simIn = setModelParameter(simIn,"StopTime","10");
out = sim(simIn);
To view the simulation results, double-click the Scope block in the model. The plot in the Scope
displays the values of the signals x1 and x2 over the 10-second simulation.
4-13
4 Data Import/Export Parameters
Resume the simulation by using the operating point you saved at the end of the first simulation as the
initial operating point for the second simulation.
Get the final operating point from the first simulation from the Simulink.SimulationOutput
object out.
vdpOP = out.xFinal;
Specify the operating point as the initial state for the simulation.
simIn2 = Simulink.SimulationInput(mdl);
simIn2 = setInitialState(simIn2,vdpOP);
Set the stop time for this simulation to 20. On the Simulation tab, under Simulate, in the Stop
Time box, enter 20, or use the setModelParameter function to specify the value of the StopTime
parameter for the simulation.
simIn2 = setModelParameter(simIn2,"StopTime","20");
Simulate the model again, resuming the prior simulation by starting this simulation from the final
operating point saved in the first simulation.
out2 = sim(simIn2);
4-14
Initial state
The plot in the Scope window updates to show the data from this simulation. The time axis starts at 0
and goes to the simulation stop time of 20. Because this simulation started from the initial operating
point from the first simulation, which ended after 10 simulation seconds, the plot shows the values of
the signals x1 and x2 only between simulation time 10 seconds and 20 seconds.
Tips
• Initial states loaded using the Initial state parameter override initial conditions and initial values
specified in the model.
• To load initial state data for a model that contains bus-valued states, use the Dataset format.
• By default, the software issues a warning when you specify initial states using the Array format.
You can control this diagnostic behavior using the Initial state is array parameter.
• The Initial state parameter does not load initial state data from a data dictionary. When a model
uses a data dictionary and you disable model access to the base workspace, the Initial State
parameter still has access to resolve variables in the base workspace.
• Loading an initial state or operating point that uses the Dataset format is not supported for rapid
accelerator or deployed simulations if one or more states in the model has any of these data types:
• half
• string
• Character vector
• Fixed-point
• Loading an initial state or operating point that uses the Dataset format is not supported if a
referenced model that simulates in a mode other than normal contains one or more states that
have any of these data types:
• half
• string
4-15
4 Data Import/Export Parameters
• Character vector
• Fixed-point
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: LoadInitialState
Value: "on" | "off"
Default: "off"
Parameter: InitialState
Type: string | character vector
Value: Simulink.op.ModelOperatingPoint object | Simulink.SimulationData.Dataset
object | structure | matrix
Default: "xInitial"
Version History
Introduced before R2006a
State data that you specify using the Initial state model configuration parameter can have Inf
values, including when you specify the initial state for a model using a
Simulink.op.ModelOperatingPoint object. In previous releases, the software issued an error
when initial state data included Inf values.
See Also
States | Final states | Save final operating point | Initial state is array | Format
Topics
“Specify Initial State for Simulation”
“Save Block States and Simulation Operating Points”
“Use Model Operating Point for Faster Simulation Workflow”
4-16
Time
Time
Option to log time values for simulation
Description
Specify whether to log simulation time data to the specified MATLAB variable during simulation.
tout = out.tout;
Settings
on (default) | off
on
The software logs time data during simulation. By default, the name of the logging variable that
contains the time data is tout. To use a different variable name, specify a valid MATLAB variable
name in the text box.
The variable must not have a name that matches the name of any object functions or properties of
the Simulink.SimulationOutput object.
off
The software does not log time data during simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SaveTime
Value: 'on' | 'off'
Default: 'on'
Parameter: TimeSaveName
Type: string | character vector
4-17
4 Data Import/Export Parameters
Version History
Introduced before R2006a
See Also
Topics
“Save Simulation Data”
“Data Format for Logged Simulation Data”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-18
States
States
Option to log block state values during simulation
Description
Specify whether the software logs block state values to the specified MATLAB variable. Some blocks
have hidden states data that is not captured by state logging.
Settings
off (default) | on
off
The software does not log block states during simulation.
on
The software logs block state values during simulation. By default, the state data is saved using
the variable name xout. To use a different variable name, specify a valid MATLAB variable name
in the text box.
The variable must not have a name that matches the name of any object functions or properties of
the Simulink.SimulationOutput object.
For more information about states data, see “Save Block States and Simulation Operating Points”.
Tips
• Specify the format for the logged states data using the Format parameter.
• To log fixed-point states data, log states data using the Dataset format.
• When you log states data using the Dataset format, states data streams to the Simulation Data
Inspector during simulation.
• Dataset format does not support:
4-19
4 Data Import/Export Parameters
• If you log states data in Structure with time format or in Array format while also logging
time, select the Record logged workspace data in Simulation Data Inspector parameter to
view the data in the Simulation Data Inspector after simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SaveState
Value: 'on' | 'off'
Default: 'off'
Parameter: StateSaveName
Type: string | character vector
Value: valid MATLAB variable name
Default: 'xout'
Version History
Introduced before R2006a
See Also
Model Settings
Format | Final states | Save final operating point
Objects
Simulink.SimulationOutput | Simulink.SimulationData.Dataset |
Simulink.SimulationData.State
Topics
“Save Block States and Simulation Operating Points”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-20
Output
Output
Option to log data for top-level output ports
Description
Specify whether the software logs data for output ports in the top model.
yout = out.yout;
Settings
on (default) | off
on
The software logs data for output ports in the top model during simulation. By default, the data is
stored using the variable name yout. To use a different variable name, specify a valid MATLAB
variable name in the text box.
The variable must not have a name that matches the name of any object functions or properties of
the Simulink.SimulationOutput object.
off
The software does not log data for output ports in the top model.
Tips
• The software logs data for top-level output ports at the base rate for the model when you set the
Format parameter to a value other than Dataset. When you use the Dataset format, the
software logs the data using the sample time specified for each output port.
• You can specify which values are logged in simulation using options such as decimation and
limiting saved data to the last n values. For more information, see “Specify Signal Values to Log”.
• When you set the Format parameter to Dataset, logged output data also logs to the Simulation
Data Inspector.
• To log fixed-point data, set the Format parameter to Dataset. If you set the Format parameter to
a value other than Dataset, fixed-point data is logged as double.
• To log bus data, set the Format parameter to a value other than Array.
• For the active variant condition, the software creates a Dataset object with the logged data. For
inactive variant conditions, the software creates a timeseries object that contains zero samples.
• To log data for a variable-size signal, use the Dataset format. Data for a variable-size signal is
always saved as a timetable that contains a cell array of data for each time step.
4-21
4 Data Import/Export Parameters
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SaveOutput
Value: 'on' | 'off'
Default: 'on'
Parameter: OutputSaveName
Type: string | character vector
Value: valid MATLAB variable name
Default: 'yout'
Version History
Introduced before R2006a
See Also
Topics
“Data Format for Logged Simulation Data”
“Save Simulation Data”
“Model Configuration Parameters: Data Import/Export” on page 4-2
“Convert Data to Dataset Format”
4-22
Final states
Final states
Option to log final state values
Description
Specify whether to log the final values of block states in the model at the end of simulation using the
specified variable name. You can use the final states data as the initial state for another simulation.
When you want to use final states data as the initial state for another simulation, consider selecting
Save final operating point. The model operating point contains complete information about the
simulation state, including block states, hidden block states, the state of the solver and execution
engine, and output values for some blocks. When you use a model operating point as the initial state,
the simulation results are the same as a simulation that runs from the beginning. When you specify
initial states using logged states data alone, the simulation results might not match. For more
information, see “Specify Initial State for Simulation”.
Settings
off (default) | on
off
The software does not save final state values at the end of simulation.
on
At the end of the simulation, the software saves the final state values. By default, the final state
values are stored in the variable xFinal. To use a different variable name for final states data,
specify a valid MATLAB variable name in the text box.
Tips
• The final states data has the format you specify using the Format parameter.
• The final states data is empty when the model does not contain any states or contains only hidden
states.
• To use final state data as the initial state for another simulation, set the Format parameter to
Dataset if your model contains bus-valued states.
• Logging final states using the Dataset format is not supported in rapid accelerator or deployed
simulations if one or more states in the model have any of these data types:
• half
• string
• Character vector
• Fixed-point
• Logging final states using the Dataset format is not supported if a referenced model that
simulates in a mode other than normal contains one or more states that have any of these data
types:
4-23
4 Data Import/Export Parameters
• half
• string
• Character vector
• Fixed-point
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SaveFinalState
Value: 'on' | 'off'
Default: 'off'
Parameter: FinalStateName
Type: string | character vector
Value: valid MATLAB variable name
Default: 'xFinal'
Version History
Introduced before R2006a
See Also
Format | Save final operating point
Topics
“Save Block States and Simulation Operating Points”
“Specify Initial State for Simulation”
Importing and Exporting States
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-24
Format
Format
Format for logged states, output, and final states data
Description
Specify format for logged states, output, and final states data. Signal logging and data store logging
always use the Dataset format.
The choice of format does not affect the simulation results in terms of the system behavior but can
affect the content of the logged data. The Dataset format logs time data for each signal, so logged
values reflect the sample rate for each output and state. The Structure, Structure with time,
and Array formats share a single time vector for all outputs and states, so the output and state data
is logged using the fundamental sample time for the model.
Settings
Dataset (default) | Array | Structure | Structure with time
Dataset
Logged outputs, states, and final states are each stored in a
Simulink.SimulationData.Dataset object. Each Dataset object contains an element for
each individual state or output. By default, the data for each state or output is stored in a
timeseries object except variable-size signal data. Logged data for variable-size signals is
always stored in a timetable that contains a cell array of signal values for each time step. To
specify whether to store data as a timeseries object or as a timetable, use the Dataset
signal format parameter.
You can process data logged using the Dataset format in MATLAB without a Simulink license.
When you log states and output data using the Dataset format:
• Logging supports saving multiple data values for a given time step, which can be required for
logging data in a For Iterator Subsystem, a While Iterator Subsystem, and Stateflow.
• Logged data automatically streams to the Simulation Data Inspector during simulation.
• You can log variable-size signals using top-level Outport blocks.
• You can use state and operating point data as the initial state for simulation of a model that
contains bus-valued states.
• Code generation.
• Logging states inside a function-call subsystem.
• Logging states during rapid accelerator simulations.
• Logging states in simulations deployed using Simulink Compiler
• Logging final states in rapid accelerator and deployed simulations if one or more states in the
model has any of these data types:
4-25
4 Data Import/Export Parameters
• half
• string
• Character vector
• Fixed-point
• Logging final states if a referenced model that simulates in a mode other than normal contains
one or more states that have any of these data types:
• half
• string
• Character vector
• Fixed-point
Array
Logged outputs, states, and final states are each stored as a matrix. Each row in the matrix
corresponds to a simulation time step, and each column corresponds to a state or output.
The order of the states and outputs in the matrix depends on the block sorted order, which can
change from one simulation to the next. Do not use Array format to log bus data.
To use Array format, all logged states and outputs must be:
Use another format if the outputs and states in your model do not meet these conditions.
Structure
Outputs, states, and final states are each stored as a structure. The states structure contains a
structure for each block in the model that has a state. The outputs structure contains a structure
for each top-level output port.
Structure with time
Outputs, states, and final states are each logged to a structure that contains a field for time data
as well as a field for the output or states data. The time field contains a vector of simulation
times. The signals field contains the same data that is logged when you select the Structure
format.
Examples
Open the model vdp. The model produces two outputs x1 and x2.
mdl = "vdp";
open_system(mdl);
4-26
Format
Simulate the model, logging block states along with the output data.
out = sim(mdl,"SaveState","on");
All logged data is returned in the single variable out as a Simulink.SimulationOutput object.
The SimulationOutput object contains a Simulink.SimulationData.Dataset object that
groups each kind of logged data.
out
out =
Simulink.SimulationOutput:
tout: [64x1 double]
xout: [1x1 Simulink.SimulationData.Dataset]
yout: [1x1 Simulink.SimulationData.Dataset]
Access the Dataset object yout that contains the logged output data using dot notation. The
Dataset object contains a Simulink.SimulationData.Signal object for each output.
outputs = out.yout
outputs =
Simulink.SimulationData.Dataset 'yout' with 2 elements
Name BlockPath
____ _________
1 [1x1 Signal] x1 vdp/Out1
2 [1x1 Signal] x2 vdp/Out2
The Signal object has metadata about the signal, including the path to the block and index of the
port that produces the signal. Use the getElement function to access the Signal object that
contains the data for signal x1 by name. You can also use curly braces({}) to access elements in a
Dataset object by index.
outputX1 = getElement(outputs,'x1')
4-27
4 Data Import/Export Parameters
outputX1 =
Simulink.SimulationData.Signal
Package: Simulink.SimulationData
Properties:
Name: 'x1'
PropagatedName: ''
BlockPath: [1x1 Simulink.SimulationData.BlockPath]
PortType: 'inport'
PortIndex: 1
Values: [1x1 timeseries]
The signal data is stored in the Values property of the Signal object as a timeseries object.
outputValsX1 = outputX1.Values
timeseries
Common Properties:
Name: 'x1'
Time: [64x1 double]
TimeInfo: tsdata.timemetadata
Data: [64x1 double]
DataInfo: tsdata.datametadata
The time values are in the Time property of the timeseries object. The signal values are in the
Data property.
outputTimesX1 = outputValsX1.Time
outputTimesX1 = 64×1
0
0.0001
0.0006
0.0031
0.0157
0.0785
0.2844
0.5407
0.8788
1.2788
⋮
outputDataX1 = outputValsX1.Data
outputDataX1 = 64×1
2.0000
2.0000
2.0000
2.0000
1.9998
1.9943
1.9379
1.8155
1.5990
4-28
Format
1.2687
⋮
You can also access the time values or data values by combining the steps into a single line of code.
outputDataX1 = getElement(out.yout,'x1').Values.Data
outputDataX1 = 64×1
2.0000
2.0000
2.0000
2.0000
1.9998
1.9943
1.9379
1.8155
1.5990
1.2687
⋮
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SaveFormat
Value: "Array" | "Structure" | "StructureWithTime" | "Dataset"
Default: "Dataset"
Version History
Introduced before R2006a
See Also
Model Settings
Dataset signal format | Output | States | Final states | Save final operating point
Objects
Simulink.SimulationOutput | Simulink.SimulationData.Dataset |
Simulink.op.ModelOperatingPoint
4-29
4 Data Import/Export Parameters
Topics
“Save Simulation Data”
“Data Format for Logged Simulation Data”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-30
Limit data points to last
Description
Specify whether to log all values or log only the last n data points for outputs, states, and time.
Settings
off (default) | on
off
States and outputs are logged for the entire simulation.
on
Only the last n output, state, and time values are logged. Specify the number of data points to
save in the text box. By default, the number of data points to save when you select Limit data
points to last is 1000.
Tips
• For some models and simulation conditions, logging can produce large amounts of data. Use this
parameter to limit the number of values logged when you only need to analyze data from the end
of the simulation.
• You can also apply a decimation factor to reduce the number of values logged for outputs, states,
and time. For more information, see Decimation.
• For more information about configuring which data points are logged for different logging
techniques, see “Specify Signal Values to Log”.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: LimitDataPoints
Value: 'on' | 'off'
Default: 'off'
4-31
4 Data Import/Export Parameters
Parameter: MaxDataPoints
Type: string | character vector
Value: positive integer greater than zero
Default: '1000'
Version History
Introduced before R2006a
See Also
Topics
“Specify Signal Values to Log”
“Save Simulation Data”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-32
Decimation
Decimation
Option to apply decimation factor for logged output, state, and time data
Description
Specify the decimation factor, n, such that every nth data point is logged for outputs, states, and time.
Settings
1 (default) | positive integer greater than zero
• With the default value 1, all data points are logged for outputs, states, and time.
• The specified value must be a positive integer greater than zero.
• The value of this parameter is not tunable during simulation.
Tips
• For some models and simulation conditions, logging can produce large amounts of data. Use this
parameter to reduce the number of samples logged when a reduced effective sample rate is
sufficient.
• You can also use the Limit data points to last parameter to reduce the number of sample values
saved for output, state, and time logging.
• For more information about configuring which data points are logged for different logging
techniques, see “Specify Signal Values to Log”.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: Decimation
Type: string | character vector
Value: positive integer greater than zero
Default: '1'
4-33
4 Data Import/Export Parameters
Version History
Introduced before R2006a
See Also
Topics
“Save Simulation Data”
“Specify Signal Values to Log”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-34
Save final operating point
Description
When the simulation is paused or stops, the software saves the complete model operating point,
including block states, hidden block states, the state of the solver and execution engine, and some
block output values, to the specified MATLAB variable.
Dependencies
To enable this parameter, select Final states.
Settings
off (default) | on
off
If you select Final states, the software exports only the final values for block states at the end of
simulation. This information might not be sufficient to accurately resume a simulation from the
same point.
on
The software saves complete information about the simulation state as a
Simulink.op.ModelOperatingPoint object. The operating point information is stored in the
Final states logging variable.
Examples
mdl = "vdp";
open_system(mdl);
Configure the model to save the final operating point at the end of simulation.
Alternatively, create a Simulink.SimulationInput object to store the parameter values for the
simulation. Then, use the setModelParameter function to specify the parameter values to use in the
simulation.
4-35
4 Data Import/Export Parameters
simIn = Simulink.SimulationInput(mdl);
simIn = setModelParameter(simIn,"SaveFinalState","on");
simIn = setModelParameter(simIn,"SaveOperatingPoint","on");
Set the stop time for the simulation to 10 seconds. On the Simulation tab, under Simulate, in the
Stop Time box, enter 10, or use the setModelParameter function to specify the value of the
StopTime parameter for the simulation.
simIn = setModelParameter(simIn,"StopTime","10");
out = sim(simIn);
To view the simulation results, double-click the Scope block in the model. The plot in the Scope
displays the values of the signals x1 and x2 over the 10-second simulation.
Resume the simulation by using the operating point you saved at the end of the first simulation as the
initial operating point for the second simulation.
Get the final operating point from the first simulation from the Simulink.SimulationOutput
object out.
vdpOP = out.xFinal;
Specify the operating point as the initial state for the simulation.
4-36
Save final operating point
simIn2 = Simulink.SimulationInput(mdl);
simIn2 = setInitialState(simIn2,vdpOP);
Set the stop time for this simulation to 20. On the Simulation tab, under Simulate, in the Stop
Time box, enter 20, or use the setModelParameter function to specify the value of the StopTime
parameter for the simulation.
simIn2 = setModelParameter(simIn2,"StopTime","20");
Simulate the model again, resuming the prior simulation by starting this simulation from the final
operating point saved in the first simulation.
out2 = sim(simIn2);
The plot in the Scope window updates to show the data from this simulation. The time axis starts at 0
and goes to the simulation stop time of 20. Because this simulation started from the initial operating
point from the first simulation, which ended after 10 simulation seconds, the plot shows the values of
the signals x1 and x2 only between simulation time 10 seconds and 20 seconds.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
4-37
4 Data Import/Export Parameters
Application Setting
Safety precaution No recommendation
Programmatic Use
Parameter: SaveOperatingPoint
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2019a
R2019a: Save complete SimState in final state parameter renamed to Save final operating
point
The Save complete SimState in final state parameter, which was introduced in R2009a, is
renamed and replaced with the Save final operating point parameter. To programmatically
configure the parameter in previous releases, you used the SaveCompleteFinalSimState
parameter. Starting in R2019a, use the SaveOperatingPoint parameter.
The SaveCompleteFinalSimState parameter continues to work and results in the same behavior
as the SaveOperatingPoint parameter.
See Also
Topics
“Specify Initial State for Simulation”
“Save Block States and Simulation Operating Points”
“Use Model Operating Point for Faster Simulation Workflow”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-38
Signal logging
Signal logging
Option to log data for signals marked for logging in model
Description
Specify whether to log data for signals marked for logging to the workspace and the Simulation Data
Inspector.
logsout = out.logsout;
Settings
on (default) | off
on
The software logs data for signals marked for logging in the model to the workspace and the
Simulation Data Inspector. By default, the logged signal data is saved in the variable logsout. To
save the data using a different variable name, specify a valid MATLAB variable name in the text
box.
The variable must not have a name that matches the name of any object functions or properties of
the Simulink.SimulationOutput object.
Data for variable-size signals is saved as a timetable that contains a cell array of values for
each time step.
off
The software does not log signal data during simulation, regardless of whether the signal is
marked for logging in the model.
Tips
• If you select Signal logging, you can use the Configure Signals to Log button to open the
Signal Logging Selector. You can use the Signal Logging Selector to:
• Review all signals in a model hierarchy that are configured for logging.
• Override signal logging settings for specific signals.
• Control signal logging throughout a model reference hierarchy.
You can use the Signal Logging Selector for both Simulink and Stateflow signals.
4-39
4 Data Import/Export Parameters
For details about the Signal Logging Selector, see “View Logging Configuration Using the Signal
Logging Selector” and “Override Signal Logging Settings”.
• For information about logging Simscape data, see “About Simscape Data Logging” (Simscape).
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: SignalLogging
Value: 'on' | 'off'
Default: 'on'
Parameter: SignalLoggingName
Type: character vector
Value: valid MATLAB variable name
Default: 'logsout'
Limitations
• Signal logging is not supported for:
• The model that contains the for-each subsystem simulates in rapid accelerator mode.
• The for-each subsystem is inside a referenced model simulated in accelerator mode.
For more information about logging signals in for-each subsystems, see “Log Signals in For-
Each Subsystems”.
• State port outputs of Integrator and Discrete-Time Integrator blocks.
Version History
Introduced before R2006a
4-40
Signal logging
In normal and accelerator mode simulations, you can log an unbounded variable-size signal using
signal logging. Logging is not supported for nonvirtual buses that contain unbounded variable-size
signals.
You can mark variable-size signals for logging when you use the Dataset format.
Data for variable-size signals is saved as a timetable that contains a cell array of values for each
time step.
R2019a: Signal logging parameter controls whether data streams to Simulation Data
Inspector
Since R2017a, signals you mark for logging also stream to the Simulation Data Inspector. Between
R2017a and R2019a, the data always streamed to the Simulation Data Inspector, even when you
disabled the Signal logging parameter. Starting in R2019a, data for signals you mark for logging
streams to the Simulation Data Inspector only when you enable the Signal logging parameter.
When you mark a signal for logging, the data for that signal streams to the Simulation Data Inspector
during simulation in addition to being logged to the workspace. In previous releases, you marked
signals for logging and streaming separately. Streaming badges are converted to logging badges.
Data for signals that are marked for logging always streams to the Simulation Data Inspector, even
when you disable the Signal logging parameter for the model. When you disable the Signal
logging parameter, the data does not log to the workspace.
See Also
Simulation Data Inspector
Topics
“Save Signal Data Using Signal Logging”
“Convert Data to Dataset Format”
4-41
4 Data Import/Export Parameters
4-42
Data stores
Data stores
Option to log data for Data Store Memory blocks
Description
Specify whether the software logs all Data Store Memory block variables for the model to the
specified MATLAB variable.
dsmout = out.dsmout;
Settings
on (default) | off
on
The software logs all Data Store Memory block variables to the workspace and the Simulation
Data Inspector during simulation. By default, the logged data is stored in the variable dsmout. To
save the data using a different variable name, specify a valid MATLAB variable name in the text
box.
The variable must not have a name that matches the name of any object functions or properties of
the Simulink.SimulationOutput object.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
4-43
4 Data Import/Export Parameters
Programmatic Use
Parameter: DSMLogging
Value: 'on' | 'off'
Default: 'on'
Parameter: DSMLoggingName
Type: string | character vector
Value: valid MATLAB variable name
Default: 'dsmout'
Version History
Introduced in R2010a
See Also
Blocks
Data Store Memory
Objects
Simulink.SimulationOutput | Simulink.SimulationData.Dataset |
Simulink.SimulationData.DataStoreMemory
Topics
“Save Simulation Data”
“Log Data Stores”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-44
Log Dataset data to file
Description
Specify whether to log simulation data that uses the Dataset format to a MAT file.
Settings
off (default) | on
off
Simulation data logged using the Dataset format logs to the workspace and does not log to a
MAT file.
on
Simulation data logged using Dataset format logs to a MAT file and does not log to the
workspace. By default, the data is saved in a file with the name out.mat in the current working
directory. To save the file in a different location or using a different filename, specify the path and
filename in the text box.
Tips
• To use the Log Dataset data to file option, select one or more of these types of data to log:
• States
• Final states
• Signal logging
• Output
• Data stores
• Stateflow states and data
To log states or output data to the MAT file, set the Format parameter to Dataset.
To log Final states data to the MAT file, clear Save final operating point.
• When the data in the MAT file fits into memory, use the load function to access the data.
• When the data in the MAT file is too large to fit into memory, access the data in the MAT file using
Simulink.SimulationData.DatasetRef and
matlab.io.datastore.SimulationDatastore objects.
• Except for parallel simulations, the software overwrites the contents of the MAT file during each
simulation unless you change the name of the file between simulations. For details, see “Save
Logged Data from Successive Simulations”.
4-45
4 Data Import/Export Parameters
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: LoggingToFile
Value: 'on' | 'off'
Default: 'off'
Parameter: LoggingFileName
Type: string | character vector
Value: valid path and file name
Default: 'out.mat'
Version History
Introduced in R2016a
See Also
Objects
Simulink.SimulationData.Dataset | Simulink.SimulationData.DatasetRef
Functions
load
Topics
“Log Data to Persistent Storage”
“Load Big Data for Simulations”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-46
Output options
Output options
Options to produce output values at specified times in variable-step simulation
Description
Select an option to produce output values at specified times in simulations that use a variable-step
solver.
Consider using these options when a variable-step solver takes too large of a time step during
simulation in a way that misses discontinuities or other system dynamics.
Dependencies
To enable this parameter, on the Solver pane, set the solver Type to Variable-step.
Settings
Refine output (default) | Produce additional output | Produce specified output only
Refine output
The solver produces additional output values based on the value you specify for the Refine factor
parameter. By default, the refine factor is 1, and the simulation does not produce additional
output values. When you specify a refine factor of 2, the simulation produces an additional output
value midway between each simulation time step.
The solver does not take additional major time steps to produce the additional output values.
Specifying a refine factor can provide more output points more efficiently than decreasing the
maximum step size for the simulation.
Produce additional output
The solver produces additional output values by taking a major time step at each time you specify
using the Output times parameter in addition to the major time steps determined by the solver.
Produce specified output only
The solver produces output values only at the simulation start time, simulation stop time, and the
times you specify using the Output times parameter. The solver might take additional steps as
required to accurately simulate the model and produce the output values for the specified times.
However, logged simulation data contains values for only the specified times.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
4-47
4 Data Import/Export Parameters
Application Setting
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: OutputOption
Value: 'RefineOutputTimes' | 'AdditionalOutputTimes' | 'SpecifiedOutputTimes'
Default: 'RefineOutputTimes'
Version History
Introduced before R2006a
See Also
Refine factor | Output times
Topics
“Save Simulation Data”
“Samples to Export for Variable-Step Solvers”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-48
Refine factor
Refine factor
Option to produce additional output values between simulation time steps
Description
Specify the amount of additional output values for the variable-step solver to produce. A refine factor
of 1 specifies that the simulation produce the same number of output values. A refine factor of 2
specifies that the simulation produce twice the number of output values. The solver does not produce
these values by taking additional major time steps.
This parameter is supported only for simulations that use a variable-step solver. In simulations that
use a fixed-step solver, this parameter is ignored.
This parameter is also ignored in simulations of purely discrete models, which contain no continuous
states.
The software always simulates purely discrete models using the discrete solver for the selected solver
type, regardless of the value you specify for the Solver parameter.
Dependencies
To enable this parameter, set Output options to Refine output.
Settings
1 (default) | positive integer greater than zero
By default, the refine factor is 1, and the simulation does not produce additional output values. When
you specify a refine factor of 2, the simulation produces approximately twice the number of output
values by calculating an additional output value midway between each major time step.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: Refine
Type: string | character vector
4-49
4 Data Import/Export Parameters
Version History
Introduced before R2006a
Simulations of purely discrete models that use variable-step solvers no longer log redundant data
values when you specify a value for the Refine factor parameter.
Continuous state and continuous state derivative values can change at any time in simulation. Solvers
compute continuous dynamics based on continuous states and continuous state derivatives in the
model. In variable-step simulations, solvers propagate simulation time and ensure the accuracy of
simulation results by checking whether taking a given step satisfies tolerance requirements for
continuous state values.
By contrast, discrete state values change only at simulation time hits that correspond to the discrete
sample time associated with the state. When a model contains no states or only discrete states,
specifying a refine factor for logged data does not provide additional information about the logged
signals or the simulation because, by definition, the system dynamics cannot change between the
major time steps of the simulation.
See Also
Output options | Output times
Topics
“Save Simulation Data”
“Samples to Export for Variable-Step Solvers”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-50
Output times
Output times
Option to specify times for which variable-step simulation produces output values
Description
Specify times at which the variable-step solver generates output values.
• When you set Output options to Produce additional output, the variable-step solver takes
major time steps at the specified times in addition to other major time steps the solver determines
during simulation.
• When you set Output options to Produce specified output only, simulation data logged
from simulation contains values only for the specified times. The solver might take additional
major time steps as required for accurate simulation results. However, output values are not
produced for these time steps.
This parameter is supported only for simulations that use a variable-step solver. In simulations that
use a fixed-step solver, the software ignores this parameter.
Dependencies
To enable this parameter, set Output options to Produce additional output or Produce
specified output only.
Settings
[] (default) | vector
By default, the value for Output times is []. If you set Output options to Produce additional
output, the simulation does not produce additional output values. If you specify Output options as
Produce specified output only, no data is logged from simulation.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
4-51
4 Data Import/Export Parameters
Programmatic Use
Parameter: OutputTimes
Type: string | character vector
Value: vector
Default: '[]'
Version History
Introduced before R2006a
See Also
Topics
“Save Simulation Data”
“Samples to Export for Variable-Step Solvers”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-52
Single simulation output
Description
By default, when you simulate a model, simulation results are returned as a single
Simulink.SimulationOutput object that contains complete simulation metadata and all
simulation data logged to the workspace. Using the single-output format makes processing results
from several simulations easier and provides better support for parallel and batch simulations. When
you return results as a single simulation output, the syntax to simulate a model programmatically is
the same for the sim, parsim, and batchsim functions.
Settings
on (default) | off
on
All simulation data logged to the workspace is returned as a single
Simulink.SimulationOutput object. By default, the name of the variable that stores the
SimulationOutput object is out. To use a different variable name, specify a valid MATLAB
variable name in the text box.
When you simulate a model programmatically, the name you specify in the text box does not
determine the name of the variable that stores the SimulationOutput object. The
SimulationOutput object is stored in the variable to which you assign the return argument. For
example, for this simulation, the SimulationOutput object variable name is simOut.
simOut = sim(simIn);
off
Logged simulation results are returned as one or more variables, depending on the logging
options configured in the model.
When you simulate the model using a syntax of the sim function that returns multiple output
arguments, the sim function does not return the logging variables. The logging variables are
available in the workspace after the simulation completes. Syntaxes of the sim function that
return multiple arguments are not recommended.
You can configure simulations using SimulationInput objects when you run simulations
using the sim, parsim, and batchsim functions.
• You simulate the model using a sim function syntax that returns results as a single simulation
output.
4-53
4 Data Import/Export Parameters
Tips
• When you log data using the To File block, the data logs to the specified file and does not appear
in the single Simulink.SimulationOutput object.
• When you select Log Dataset data to file, the data that logs to the MAT file is not included in the
single Simulink.SimulationOutput object.
• Enabling fast restart enables the Single simulation output parameter.
• Use the who function for the Simulink.SimulationOutput object to view a list of the variables
in the object.
• To use the Logging intervals parameter, you must select Single simulation output.
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: ReturnWorkspaceOutputs
Value: 'on' | 'off'
Default: 'on'
Parameter: ReturnWorkspaceOutputsName
Type: string | character vector
Value: valid MATLAB variable name
Default: 'out'
Version History
Introduced in R2009b
See Also
Objects
Simulink.SimulationOutput | Simulink.SimulationInput
Functions
sim | parsim | batchsim
Topics
“Model Configuration Parameters: Data Import/Export” on page 4-2
“Run Simulations Programmatically”
4-54
Single simulation output
4-55
4 Data Import/Export Parameters
Logging intervals
Option to specify time intervals in which to log simulation data
Description
Specify time intervals during which to log data.
• Time
• States
• Output
• Signal logging
• To Workspace blocks
• To File blocks
• Data logged to the workspace using a Record block
Logging intervals do not affect data displayed in the Record block or using dashboard blocks.
Dependencies
To enable this parameter, select Single simulation output.
Settings
[-inf,inf] (default) | 2-by-n matrix
By default, the parameter value is [-inf,inf], and data is logged throughout the entire simulation.
Specify the time intervals in which to log data as a matrix with two columns. Each row contains the
start and stop time for an interval in which the simulation logs simulation data. The first element is
the start time for the interval, and the second element is the stop time for the interval.
The matrix must specify the logging intervals in chronological order, and the specified intervals must
not overlap. The matrix must contain only real, double values and must not contain NaN values.
When you specify an interval that includes a time before the simulation start time or after the
simulation stop time, no data is logged for that interval.
4-56
Logging intervals
Tips
• The Decimation and Limit data points to last parameters also apply to logged data when you
specify logging intervals.
• When you change the logging intervals while stepping through a simulation using the Step
Forward and Step Backward buttons, the new logging intervals do not apply until you step
forward.
• Software-in-the-loop (SIL) simulations support logging intervals for data returned in a
Simulink.SimulationOutput object. In SIL simulations, specified logging intervals are ignored
without warning for:
Recommended Settings
The table summarizes recommended values for this parameter based on considerations related to
code generation.
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: LoggingIntervals
Type: 2-by-n matrix that contains real, double values
Default: [-inf,inf]
Version History
Introduced in R2015b
See Also
Model Settings
Single simulation output | Decimation | Limit data points to last
Blocks
To File | Record | To Workspace
Topics
“Specify Signal Values to Log”
“Run Simulations Programmatically”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-57
4 Data Import/Export Parameters
Description
Specify whether to send data logged in a format other than Dataset and data logged using To File or
Scope blocks to the Simulation Data Inspector after simulation pauses or stops.
This parameter does not affect data logged using the Dataset format or using other logging blocks,
such as the Record block and the To Workspace block. Data logged using the Dataset format and
other logging blocks streams to the Simulation Data Inspector during simulation.
Settings
off (default) | on
off
Data logged using a format other than Dataset or using To File or Scope blocks is not sent to the
Simulation Data Inspector.
on
These kinds of simulation data are sent to the Simulation Data Inspector when a simulation is
paused or stopped:
• States and output data logged in Array or Structure with time formats
• Data logged using To File blocks or Scope blocks
When you log data using the Array format, you must also log Time for the states and output data
to log to the Simulation Data Inspector.
When you select this option, a recording icon appears on the Data Inspector button.
Tips
To open the Simulation Data Inspector, on the Simulation tab, click Data Inspector.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
4-58
Record logged workspace data in Simulation Data Inspector
Programmatic Use
Parameter: InspectSignalLogs
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced before R2006a
See Also
Simulation Data Inspector
Topics
“View Simulation Data in Simulation Data Inspector”
“Inspect Simulation Data”
“Model Configuration Parameters: Data Import/Export” on page 4-2
4-59
5
The Math and Data Types pane includes parameters for specifying data types and net slope
calculations.
Parameter Description
Simulation behavior for denormal numbers Specify the desired behavior for denormal results
from arithmetic operations. Requires a Fixed-
Point Designer license.
Use algorithms optimized for row-major array Enable algorithms for row-major format code
layout generation and corresponding row-major
algorithms for simulation.
Default for underspecified data type Specify the default data type to use for inherited
data types if Simulink software could not infer
the data type of a signal during data type
propagation.
Use division for fixed-point net slope computation The Fixed-Point Designer software performs net
slope computation using division to handle net
slopes when simplicity and accuracy conditions
are met.
Gain parameters inherit a built-in integer type The data type of the gain parameter is a built-in
that is lossless integer when certain conditions are met.
Use floating-point multiplication to handle net The Fixed-Point Designer software uses floating-
slope corrections point multiplication to perform net slope
correction for floating-point to fixed-point casts.
Inherit floating-point output type smaller than Specify the desired inherited output data type
single precision behavior when block inputs are floating-point
data types smaller than single precision.
Parameter Description
Application lifespan (days) Specifies how long (in days) an application that
contains blocks depending on elapsed or absolute
time should be able to execute before timer
overflow.
Clock resolution (seconds, -1 for inherited) Specifies the clock resolution that the code
generator applies in generated code for functions
in a model that include blocks that request
absolute or elapsed time.
Implement logic signals as Boolean data (vs. Controls the output data type of blocks that
double) generate logic signals.
5-2
Simulation behavior for denormal numbers
Description
The Simulation behavior for denormal numbers parameter specifies the desired behavior for
denormal results from arithmetic operations. Denormal numbers are any non-zero numbers whose
magnitude is smaller than the smallest normalized floating-point number (see realmin). Some
hardware targets flush denormal results from arithmetic operations to zero. You can emulate this
behavior by setting the parameter to Flush To Zero (FTZ).
Dependencies
This parameter requires a Fixed-Point Designer license only when both of these conditions are met:
When the DenormalBehavior parameter is set to 'GradualUnderflow' for all models in the
model hierarchy, then no license is required.
Settings
Gradual Underflow (default) | Flush To Zero (FTZ)
Gradual Underflow
Denormal numbers are used in the results from arithmetic operations. This setting is supported
by all simulation modes.
Flush To Zero (FTZ)
Emulates flush-to-zero behavior for denormal numbers. Denormal results from arithmetic
operations are set to zero. Denormal inputs to arithmetic operations are treated as zero before
performing the operation.
This setting is supported for accelerator, rapid accelerator, SIL, and PIL modes. This setting is not
supported during normal mode simulation.
Tips
• In a model reference hierarchy, you can simulate a top model using gradual underflow with any
simulation mode.
• Normal mode simulation does not support flush to zero. If you simulate the model in normal mode,
gradual underflow is always used for that model.
Flush-to-zero may be enabled for models referenced by a top model simulated in normal mode
when the referenced models are simulated in accelerator, rapid accelerator, SIL, or PIL mode.
Gradual underflow is used for the top model.
5-3
5 Math and Data Types
• When you simulate a model reference hierarchy, the simulation mode of a parent model can
override the simulation mode of Model blocks that the parent model contains. For more
information, see “Simulation Mode Override Behavior in Model Reference Hierarchy” (Embedded
Coder). Flush-to-zero behavior is supported throughout the model reference hierarchy when the
top model is simulated in accelerator, rapid accelerator, SIL, or PIL mode.
• When a top model is simulated in accelerator, rapid accelerator, SIL, or PIL mode, any Model
blocks that the top model contains must use the same setting for the Simulation behavior for
denormal numbers parameter. Models referenced by the top model can simulate flush-to-zero
behavior only if the instance of the referenced model uses an accelerated simulation mode and has
the Simulation behavior for denormal numbers parameter set to Flush to zero (FTZ).
Recommended Settings
Application Setting
Debugging Match the behavior of your target hardware
Traceability Match the behavior of your target hardware
Efficiency No impact
Safety precaution Match the behavior of your target hardware
Programmatic Use
Parameter: DenormalBehavior
Value: 'GradualUnderflow' | 'FlushToZero'
Default: 'GradualUnderflow'
Version History
Introduced in R2019a
The Flush To Zero (FTZ) setting for the Simulation behavior for denormal numbers
parameter now has standardized behavior across hardware platforms. When this setting is selected,
denormal results from arithmetic operations are set to zero and denormal inputs to arithmetic
operations are treated as zero before performing the operation.
• For x86 processors, denormal results from arithmetic operations are set to zero.
• For ARM processors, denormal results from arithmetic operations are set to zero. Denormal inputs
to arithmetic operations are treated as zero before performing the operation.
See Also
Topics
“Exceptional Arithmetic” (Fixed-Point Designer)
Simulate with Flush to Zero to Avoid Pains in Model-Based Design Workflows
“Choose Simulation Modes for Model Hierarchies”
5-4
Simulation behavior for denormal numbers
5-5
5 Math and Data Types
Description
The Default for underspecified data type specifies the default data type to use for inherited data
types if the Simulink software could not infer the data type of a signal during data type propagation.
Settings
double (default) | single
double
Sets the data type for underspecified data types during data type propagation to double.
Simulink uses double as the data type for inherited data types.
single
Sets the data type for underspecified data types during data type propagation to single.
Simulink uses single as the data type for inherited data types.
Tips
• This setting affects both simulation and code generation.
• For embedded designs that target single-precision processors, set this parameter to single to
avoid the introduction of double data types.
• Use the Model Advisor Identify questionable operations for strict single-precision design check to
identify the double-precision usage in your model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency single (when target hardware supports efficient single
computations)
double (otherwise)
Safety precaution No impact
Programmatic Use
Parameter: DefaultUnderspecifiedDataType
Value: 'double' | 'single'
Default: 'double'
5-6
Default for underspecified data type
Version History
Introduced in R2013b
See Also
Topics
“Underspecified data types” on page 8-10
“Validate a Single-Precision Model”
“Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
5-7
5 Math and Data Types
Description
The Use division for fixed-point net slope computation parameter specifies whether the Fixed-
Point Designer software performs net scaling computation using division to handle net scaling when
simplicity and accuracy conditions are met.
Dependencies
This parameter requires a Fixed-Point Designer license.
Settings
Off (default) | On | Use division for reciprocals of integers only
Off
Performs net scaling computation using integer multiplication followed by shifts.
On
Performs net scaling computation using a rational approximation of the net scaling. This results
in integer division, multiplication, and addition when simplicity and accuracy conditions are met.
Use division for reciprocals of integers only
Performs net slope computation using division when the net slope can be represented by the
reciprocal of an integer and simplicity and accuracy conditions are met.
Tips
• This optimization affects both simulation and code generation.
• When a change of fixed-point slope is not a power of two, net scaling computation is necessary.
Normally, net scaling computation uses an integer multiplication followed by shifts. Enabling this
optimization replaces the multiplication and shifts with an integer division, multiplication, and
addition under certain simplicity and accuracy conditions.
• Performing net scaling computation using division is not always more efficient than using
multiplication followed by shifts. Ensure that the target hardware supports efficient division.
• To ensure that this optimization occurs:
• Set the word length of the block so that the software can perform division using the long data
type of the target hardware. That setting avoids use of multiword operations.
• Set the Signed integer division rounds to configuration parameter on the Hardware
Implementation pane to Zero or Floor. The optimization does not occur if you set this
parameter to Undefined.
• Set the Integer rounding mode parameter of the block to Simplest or to the value of the
Signed integer division rounds to configuration parameter setting on the Hardware
Implementation pane.
5-8
Use division for fixed-point net slope computation
• The following table summarizes how this parameter effects different fixed-point operations.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On (when target hardware supports efficient division)
Off (otherwise)
Safety precaution No impact
Programmatic Use
Parameter: UseDivisionForNetSlopeComputation
Value: 'off' | 'on' | 'UseDivisionForReciprocalsOfIntegersOnly'
Default: 'off'
Version History
Introduced in R2014b
See Also
Topics
“Net Slope Computation” (Fixed-Point Designer)
“Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
5-9
5 Math and Data Types
Description
The Gain parameters inherit a built-in integer type that is lossless parameter specifies whether
the data type of the gain parameter is a built-in integer when certain conditions are met.
Dependencies
• In cases where the data type of the gain parameter compiles to a fixed-point data type (non-zero
scaling), the software checks out a Fixed-Point Designer license.
Settings
off (default) | on
On
For Gain blocks with the Parameter data type set to Inherit:Inherit via internal rule,
the parameter data type compiles to a built-in integer type whenever possible.
Off
For Gain blocks with the Parameter data type set to Inherit:Inherit via internal rule,
the parameter data type is the type which maximizes precision.
Tips
• This optimization affects both simulation and code generation.
• This optimization affects only Gain blocks in the model.
• For more efficient code, specify the Parameter minimum and Parameter maximum values in
the Parameter Attributes tab of the Gain block parameters.
5-10
Gain parameters inherit a built-in integer type that is lossless
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On (when target hardware supports efficient
multiplication)
Off (otherwise)
Safety precaution No recommendation
Programmatic Use
Parameter: GainParamInheritBuiltInType
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2019a
5-11
5 Math and Data Types
Description
The Use floating-point multiplication to handle net slope corrections parameter specifies
whether the Fixed-Point Designer software uses floating-point multiplication to perform net slope
correction for floating-point to fixed-point casts.
Dependencies
• This parameter requires a Fixed-Point Designer license.
Settings
off (default) | on
On
Use floating-point multiplication to perform net slope correction for floating-point to fixed-point
casts.
Off
Use division to perform net slope correction for floating-point to fixed-point casts.
Tips
• This optimization affects both simulation and code generation.
• When converting from floating point to fixed point, if the net slope is not a power of two, slope
correction using division improves precision. For some processors, use of multiplication improves
code efficiency.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On (when target hardware supports efficient
multiplication)
Off (otherwise)
Safety precaution No recommendation
5-12
Use floating-point multiplication to handle net slope corrections
Programmatic Use
Parameter: UseFloatMulNetSlope
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2011b
See Also
Topics
“Floating-Point Multiplication to Handle a Net Slope Correction” (Simulink Coder)
“Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
5-13
5 Math and Data Types
Description
The Inherit floating-point output type smaller than single precision parameter specifies the
desired inherited output data type behavior when block inputs are floating-point data types smaller
than single precision.
Data types are smaller than single precision when the number of bits needed to encode the data type
is less than the 32 bits needed to encode the single precision data type. For example, half and int16
are smaller than single precision.
• Abs
• Add
• Difference
• Divide
• Dot Product
• Gain
• Math Function
• MinMax
• Product
• Product of Elements
• Sqrt
• Subtract
• Sum
• Sum of Elements
Dependencies
• This parameter requires a Fixed-Point Designer license.
Settings
off (default) | on
5-14
Inherit floating-point output type smaller than single precision
On
Inherit a floating-point output data type smaller than single precision when block inputs are
floating-point data types smaller than single precision. In cases of overflow, the output data type
is set to single precision.
Off
Use an internal rule to determine the output data type of the block. The internal rule chooses a
data type that optimizes numerical accuracy, performance, and generated code size, while taking
into account the properties of the embedded target hardware. It is not always possible for the
software to optimize efficiency and numerical accuracy at the same time.
Tips
• This parameter affects blocks whose output data type is set to Inherit: Inherit via
internal rule, Inherit: Keep MSB, Inherit: Keep LSB, or Inherit: Match scaling
when the input is a floating-point data type smaller than single precision.
• This parameter affects both simulation and code generation.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On (when targeting HDL code generation)
Off (otherwise)
Safety precaution No impact
Programmatic Use
Parameter: InheritOutputTypeSmallerThanSingle
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2021a
See Also
“The Half-Precision Data Type in Simulink” (Fixed-Point Designer)
5-15
5 Math and Data Types
Description
The Application lifespan (days) parameter specifies how long, in days, an application that contains
blocks or Stateflow charts that depend on absolute or elapsed time can execute before a timer
overflow occurs.
Settings
auto | positive scalar value | inf
You can specify a positive scalar value (for example, 0.5) or inf.
If you set the parameter to inf, the code generator uses a word size of 64 bits, which meets the 64-
bit integer data type requirement for continuous execution.
If you are generating production code, you should set the value of this parameter based on your
model timer requirements.
This parameter is ignored when you operate your model in external mode, select the model
configuration parameter MAT-file logging, or have a continuous sample time because a 64-bit timer
is required in those cases.
Tips
• If your model does not include blocks or Stateflow charts that depend on absolute or elapsed time,
this parameter does not affect simulation or generated code.
• Simulink evaluates this parameter first against the model workspace. If Simulink cannot resolve
the parameter by using the model workspace, Simulink evaluates the parameter against the base
workspace.
• For simulation, setting this parameter to a value greater than the simulation time prevents timer
overflows.
• For simulation, the application lifespan setting can be different for the parent and referenced
models. For code generation, the setting must be the same for parent and referenced models.
5-16
Application lifespan (days)
• For models intended for generating production code, avoid using blocks that depend on time.
• To minimize the amount of RAM used by time counters, specify the smallest application lifespan
possible and, for models that use asynchronous rates, the largest step size possible. For
information on how Simulink represents timers for absolute and elapsed time, see “Timer
Representation and Computation” (Simulink Coder).
• For GRT-based models and ERT-based models configured to use a data code interface, if you set
the application lifespan to inf, the code generator represents time as two 32-bit unsigned
integers. For ERT-based models configured to use a service code interface, the code generator
uses an unsigned 64-bit integer data type. If the target hardware does not support 64-bit integers,
the code generator represents a 64-bit timer as a multiword unsigned 64-bit integer data type.
• If your model contains blocks that depend on fixed-point data and time, this parameter affects
simulation and generated code.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Finite value
Safety precaution inf
Programmatic Use
Parameter: LifeSpan
Type: character vector
Value: positive scalar value or 'inf'
Default: GRT-based system target file — 'auto' with an underlying value of 'inf'; ERT-based
system target file and data code interface — 'auto' with an underlying value of 1; ERT-based system
target file and service code interface — 'inf'
Version History
Introduced in R2009b
See Also
Topics
“Specify Clock Resolution Used by Target Environment Clock” (Embedded Coder)
“Generate C Timer Service Interface Code for Component Deployment” (Embedded Coder)
“Timers” (Embedded Coder)
“Timers in Asynchronous Tasks” (Simulink Coder)
“Optimize Memory Usage for Time Counters” (Simulink Coder)
“Code Efficiency” (Simulink Coder)
5-17
5 Math and Data Types
Description
The Clock resolution parameter specifies the clock resolution that the code generator applies in
generated code for functions in a model that include blocks that request absolute or elapsed time.
Clock resolution is the smallest increment of a clock value. For example, if a clock increments its
value once per second, the clock resolution is 1 second. The parameter setting does not change solver
behavior for normal, accelerator, and rapid accelerator mode simulations. However, the parameter
setting does influence the data type that Simulink and the code generator use to represent time
values. For example, Simulink uses a specified clock resolution to deduce fixed-point data types,
which produces fixed-point simulation and generated code execution output that match.
How the code generator applies a specified clock resolution depends on the code interface configured
for a model. For models that you configure with a data code interface, the clock resolution that you
specify influences the clock tick in generated code. For models that you configure with a service code
interface, the clock resolution influences timer service interface calls in the code. When you configure
a model to use a service interface, you can specify a clock resolution that aligns with the clock
resolution of a target platform. This results in entry-point function code that reads time values that
are more accurate and can achieve improved real-time behavior.
Dependencies
• To enable this parameter, set the solver parameter Type (SolverType) to Fixed-step.
• This parameter requires an Embedded Coder® license for generating code.
Settings
-1 for inherited (default) | scalar
For models simulated in normal, accelerator, or rapid accelerator mode or configured with the
System target file parameter set to ert.tlc, you can specify a scalar value, which represents the
clock resolution in seconds.
• Simulink and the code generator use the value to determine the word size of the data type for
representing time values.
• The code generator applies that value in generated code for model functions that include blocks
that request absolute or elapsed time.
If a model includes a periodic function that includes a block that requests a time value, the value that
you specify must divide the sample times used in periodic functions in the model with no remainder.
For example, if a model includes periodic functions that use sample times 1, 0.2, and 0.1, then 0.05
is a valid clock resolution setting but value 0.03 is not valid. If the value that you specify for the
clock resolution is not a divisor, you must change the clock resolution setting or the offending sample
time.
5-18
Clock resolution (seconds, -1 for inherited)
For models configured with a system target file other than ert.tlc, or to get the clock resolution
behavior that was provided in previous releases, set Clock resolution (seconds, -1 for inherited)
to the default value (-1). When the parameter is set to -1, the code generator initializes clock
resolutions based on scheduling properties for the model style and type of an entry-point function.
For example, the code generator sets the clock resolution for an aperiodic function in an export-
function model to the model fixed-step size (fundamental sample time). For periodic functions, the
clock resolution is set to the function sample time.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Positive integer
Safety precaution -1
Programmatic Use
Parameter: ClockResolution
Type: double
Value: scalar
Default: -1
Version History
Introduced in R2023a
See Also
Topics
“Specify Clock Resolution Used by Target Environment Clock” (Embedded Coder)
“Generate C Timer Service Interface Code for Component Deployment” (Embedded Coder)
“Deploy Export-Function Component Configured for C Service Interface Code Generation”
(Embedded Coder)
“Deploy Multirate Rate-Based Component Configured for C Service Interface Code Generation”
(Embedded Coder)
5-19
5 Math and Data Types
Description
The Use algorithms optimized for row-major array layout parameter enables optimized
algorithms for row-major format code generation and corresponding row-major algorithms for model
simulation for certain blocks.
Settings
off (default) | on
When Array layout (Simulink Coder) is set to Row-major, the code generator uses algorithms to
maintain consistency of numeric results between the simulation and the generated code. Sometimes,
the generated code for these algorithms might be inefficient. You can enable the Use algorithms
optimized for row-major array layout configuration parameter to enable efficient algorithms that
are optimized for certain blocks. The Use algorithms optimized for row-major array layout
parameter affects the simulation and the generated code.
• Sum of Elements
• Product of Elements
• n-D Lookup Table
• Interpolation Using Prelookup
• Direct Lookup Table (n-D)
For these blocks, the column-major and row-major algorithms might differ in the order of output
calculations, possibly resulting in slightly different numeric values.
On
• When Array layout is set to Row-major, this parameter enables the use of efficient
algorithms that traverse the data in row-major order. The generated code is efficient.
• When Array layout is set to Column-major, this parameter enables the use of algorithms
that traverse the data in row-major order. The generated code is inefficient.
Off
• When Array layout is set to Row-major, the code generator uses algorithms that traverse the
data in column-major order. The generated code is inefficient.
• When Array layout is set to Column-major, the code generator uses algorithms that traverse
the data in column-major order. The generated code is efficient.
5-20
Use algorithms optimized for row-major array layout
Tips
When Array layout is set to Row-major, the row-major algorithm operates on table data that is
contiguous in memory. This table data leads to faster cache access, making these algorithms cache-
friendly.
This table summarizes the relationship between array layout and cache-friendly algorithms. It is a
best practice to use the algorithm that is optimized for the specified array layout to achieve good
performance. For example, select Use algorithms optimized for row-major array layout when the
Array layout is set to Row-major for code generation.
Recommended
Row-major 'off' Inefficient column-major
algorithm
Not recommended
Column-major 'on' Inefficient row-major algorithm
Not recommended
Row-major 'on' Efficient row-major algorithm
Recommended
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: UseRowMajorAlgorithm
Type: character vector
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2018b
5-21
5 Math and Data Types
See Also
Topics
“Math and Data Types Pane” on page 5-2
“Code Generation of Matrices and Arrays” (Simulink Coder)
“Row-Major Algorithms for Row-Major Array Layout” (Simulink Coder)
5-22
6
Diagnostics Parameters
6 Diagnostics Parameters
The Diagnostics category includes parameters for configuring the diagnostic behavior when the
software detects issues related to solvers and solver settings, such as algebraic loops.
Parameter Description
Algebraic loop Select the diagnostic action to take if Simulink
software detects an algebraic loop while
compiling the model.
Minimize algebraic loop Select the diagnostic action to take if artificial
algebraic loop minimization cannot be performed
for an atomic subsystem or Model block because
an input port has direct feedthrough.
Block priority violation Select the diagnostic action to take if Simulink
software detects a block priority specification
error.
Min step size violation Select the diagnostic action to take if Simulink
software detects that the next simulation step is
smaller than the minimum step size specified for
the model.
Consecutive zero-crossings violation Select the diagnostic action to take when
Simulink software detects that the number of
consecutive zero crossings exceeds the specified
maximum.
Automatic solver parameter selection Select the diagnostic action to take if Simulink
software changes a solver parameter setting.
State name clash Select the diagnostic action to take when a name
is used for more than one state in the model.
Operating point restore interface checksum Use this check to ensure that the interface
mismatch checksum is identical to the model checksum
before loading the OperatingPoint.
Parameter Description
Allow symbolic dimension specification Specify whether Simulink propagates dimension
symbols throughout the model and preserves
these symbols in the propagated signal
dimensions.
Allowed unit systems Specify unit systems allowed in the model.
Units inconsistency messages Specify if unit inconsistencies should be reported
as warnings. Select the diagnostic action to take
when the Simulink software detects unit
inconsistencies.
Allow automatic unit conversions Allow automatic unit conversions in the model.
6-2
Model Configuration Parameters: Diagnostics
Parameter Description
Check undefined subsystem initial output Specify whether to display a warning if the model
contains a conditionally executed subsystem in
which a block with a specified initial condition
drives an Outport block with an undefined initial
condition.
Solver data inconsistency Select the diagnostic action to take if Simulink
software detects S-functions that have continuous
sample times, but do not produce consistent
results when executed multiple times.
Ignored zero crossings Select the diagnostic action to take if Simulink
detects zero-crossings that are being ignored.
Masked zero crossings Select the diagnostic action to take if Simulink
detects zero-crossings that are being masked.
Block diagram contains disabled library links Select the diagnostic action to take when saving a
model containing disabled library links.
Block diagram contains parameterized library Select the diagnostic action to take when saving a
links model containing parameterized library links.
Initial state is array Message behavior when the initial state is an
array.
Insufficient maximum identifier length For referenced models, specify the diagnostic
action to take when the character length
specified in the configuration parameter
Maximum identifier length is not sufficient to
make global identifiers unique across models.
Combine output and update methods for code When output and update code is in one function,
generation and simulation force the simulation execution order to be the
same as the code generation order. For certain
modeling patterns, setting this parameter
prevents a potential simulation and code
generation mismatch. Setting this parameter
might cause artificial algebraic loops.
Behavior when pregenerated library subsystem When generating code for a model that contains
code is missing an instance of a reusable library subsystem with
a function interface, specify whether to display a
warning or an error when the model cannot use
pregenerated library code or pregenerated
library code is missing.
Behavior when a matching unit test for When using strong unit testing features to verify
subsystem reference is missing use of subsystem reference block in model,
specify whether to display a warning or error
when matching unit test signatures are not found.
FMU Import blocks When the debug execution mode is enabled, FMU
binaries are executed in a separate process.
6-3
6 Diagnostics Parameters
Parameter Description
Arithmetic operations in variant conditions Specify the diagnostic action to take when
arithmetic operations are found in variant
conditions.
Variant condition mismatch at signal source and Specify the diagnostic action to take when there
destination are variant-related modeling issues that may
result in unused Simulink variables in the
generated code.
Variant activation time inherited from Specify the diagnostic action to take when a
Simulink.VariantControl variant block with its activation time set to
inherit from Simulink.VariantControl
has no variant control variable of type
Simulink.VariantControl.
Variant configuration not used by top model Specify the diagnostic action to take when
Simulink detects during simulation or Variant
Manager activation that a top-level model does
not use a referenced model for any of the
published variant configurations of the
referenced model.
See Also
Related Examples
• “Algebraic Loop Concepts”
• Diagnosing Simulation Errors
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
6-4
Algebraic loop
Algebraic loop
Diagnostic behavior when algebraic loop detected during compilation
Description
This parameter specifies the diagnostic behavior when the software detects an algebraic loop while
compiling a model.
Settings
warning (default) | error | none
warning
The software issues a warning and tries to solve the algebraic loop during simulation. If the
solver is unable to solve the algebraic loop during simulation, the software issues an error and
terminates the simulation.
error
The software issues an error, terminates the simulation, and highlights the algebraic loop in the
block diagram when an algebraic loop is detected.
none
The software does not issue a diagnostic when it detects an algebraic loop. If the software is
unable to solve the algebraic loop during simulation, the software issues an error and terminates
the simulation.
Tips
• An algebraic loop generally occurs when both these conditions are true:
• The output value for a block depends on one or more of the input values.
• The output port for the block drives an input port on the same block through a direct
connection or an indirect connection, such as a feedback loop that contains other blocks with
input ports that have direct feedthrough.
For example, this scalar algebraic loop is created by connecting the output of a Subtract block to
its negative input port.
6-5
6 Diagnostics Parameters
Recommended Settings
Application Setting
Debugging error
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: AlgebraicLoopMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced before R2006a
See Also
Topics
“Algebraic Loop Concepts”
Diagnosing Simulation Errors
“Model Configuration Parameters: Diagnostics” on page 6-2
6-6
Minimize algebraic loop
Description
This parameter specifies the diagnostic behavior when the software is unable to resolve an artificial
algebraic loop because an input port of an atomic subsystem or model reference has direct
feedthrough.
When you select the Minimize algebraic loop occurrences parameter for an atomic subsystem or
a Model block, the software attempts to eliminate algebraic loops by checking whether the atomic
subsystems or referenced models contain blocks that do not have direct feedthrough before
simulating the model. A block has direct feedthrough when one or more of the input ports for the
block has direct feedthrough.
Settings
warning (default) | error | none
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
none
The software does not issue a diagnostic.
Tips
• When a port on an atomic subsystem or model reference is part of an artificial algebraic loop, the
software can eliminate the algebraic loop only when at least one other input port in the loop does
not have direct feedthrough.
• The software cannot eliminate artificial algebraic loops that contains signals designated as test
points. For more information, see Working with Test Points.
Recommended Settings
Application Setting
Debugging No impact
Efficiency No impact
Traceability No impact
Safety precaution error
6-7
6 Diagnostics Parameters
Programmatic Use
Parameter: ArtificialAlgebraicLoopMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced before R2006a
See Also
Topics
“How the Software Eliminates Artificial Algebraic Loops”
Diagnosing Simulation Errors
Working with Test Points
“Model Configuration Parameters: Diagnostics” on page 6-2
6-8
Block priority violation
Description
This parameter specifies the diagnostic behavior when a block priority specification error occurs.
You can specify a priority order for executing block output methods during simulation. The software
executes blocks with high priority order before blocks with lower priority order. The software uses
the priority you specify only when the order is consistent with the block sorting algorithm. If you
specify a priority order that is not consistent with the block sorting algorithm, a block priority
specification error occurs.
Settings
warning (default) | error
warning
The software issues a warning and ignores the specified block priorities.
error
The software issues an error and terminates the simulation.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: BlockPriorityViolationMsg
Value: 'warning' | 'error'
Default: 'warning'
Version History
Introduced before R2006a
See Also
Topics
Controlling and Displaying the Sorted Order
Diagnosing Simulation Errors
6-9
6 Diagnostics Parameters
6-10
Min step size violation
Description
This parameter specifies the diagnostic behavior when a minimum step size violation occurs. A
minimum step size violation occurs when the number of consecutive steps less than or equal to the
minimum step size exceeds the value specified for the Number of consecutive min steps
parameter.
By default, the value for the Number of consecutive in steps parameter is 1, and the software does
not allow any consecutive steps that are less than or equal to the minimum step size. Specify the
minimum step size using the Min step size parameter.
Settings
warning (default) | error
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: MinStepSizeMsg
Value: 'warning' | 'error'
Default: 'warning'
Version History
Introduced before R2006a
See Also
Topics
“Purely Discrete Systems”
6-11
6 Diagnostics Parameters
6-12
Consecutive zero-crossings violation
Description
This parameter specifies whether the software issues a warning, an error, or no diagnostic when a
zero-crossing violation occurs. A zero-crossing violation occurs when the number of consecutive zero
crossings detected in simulation exceeds the value specified for the Number of consecutive zero
crossings parameter.
This diagnostic applies only to simulations of models that have zero-crossing detection enabled and
use a variable-step solver.
Settings
error (default) | warning | none
error
The software issues an error and terminates the simulation.
warning
The software issues a warning.
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution warning or error
Programmatic Use
Parameter: MaxConsecutiveZCsMsg
Value: 'error' | 'none' | 'warning'
Default: 'error'
6-13
6 Diagnostics Parameters
Version History
Introduced before R2006a
See Also
Number of consecutive zero crossings | Zero-crossing control | Enable zero-crossing
detection for fixed-step simulation
Topics
“Preventing Excessive Zero Crossings”
“Zero-Crossing Detection”
Diagnosing Simulation Errors
“Model Configuration Parameters: Diagnostics” on page 6-2
6-14
Automatic solver parameter selection
Description
This parameter specifies whether the software issues no diagnostic, a warning, or an error when the
software changes the value of a solver parameter during simulation. This diagnostic behavior applies
when:
• The software changes the value of a parameter with an explicitly specified value.
For example, if you select a continuous solver for a model that does not contain continuous states,
the software changes the solver selection to the discrete solver.
• The software determines the value for a parameter with a value that specifies that the software
chooses the parameter value.
For example, when the Min step size parameter value is auto, the software determines the
minimum step size.
The software does not issue this diagnostic when determining the Solver parameter value for
simulation when the value in the model is auto.
Settings
none (default) | warning | error
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SolverPrmCheckMsg
Value: 'none' | 'warning' | 'error'
6-15
6 Diagnostics Parameters
Default: 'none'
Version History
Introduced before R2006a
See Also
Topics
Diagnosing Simulation Errors
Choosing a Solver
“Model Configuration Parameters: Diagnostics” on page 6-2
6-16
Extraneous discrete derivative signals
Note The Extraneous discrete derivative signals diagnostic configuration parameter has been
removed. Use the Solver Profiler instead. For more information, see “Version History”.
Description
This parameter specifies whether the software issues an error, a warning, or no diagnostic when a
discrete input to a Model block connects to the input of a block that has continuous states. In this
situation, the software cannot determine with certainty the appropriate rate at which to reset the
solver to ensure simulation accuracy.
When you do not specify this parameter value as error, the simulation proceeds. The software resets
the solver each time the discrete signal updates. This solver reset rate ensures that the simulation
results are accurate when the discrete signal is the source for the input signal to the block with
continuous states. When the discrete signal is not the source for the input signal to the block with
continuous states, the software can reset the solver more frequently than necessary, which can affect
simulation performance.
Settings
none (default) | error | warning
error
The software issues an error during model compilation and terminates the simulation.
warning
The software issues a warning and resets the solver each time the value of the discrete signal
changes.
none
The software does not issue a diagnostic and resets the solver each time the value of the discrete
signal changes.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
6-17
6 Diagnostics Parameters
Programmatic Use
Parameter: ModelReferenceExtraNoncontSigs
Value: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced before R2006a
R2024a: Removed
Errors starting in R2024a
The Extraneous discrete derivative signals diagnostic configuration parameter has been removed.
When a discrete input to a Model block connects to the input of a block that has continuous states,
the software resets the solver each time the discrete signal updates. The software does not issue a
warning or error. Previously, the default behavior of this diagnostic was for the software to issue an
error.
To diagnose solver resets, use the Solver Profiler instead. The Solver Profiler provides the number of
resets and the reset sources. For more information, see “Solver Resets”.
R2023b: To be removed
Not recommended starting in R2023b
The Extraneous discrete derivative signals diagnostic configuration parameter will be removed in
a future release.
See Also
Solver Profiler
Topics
Diagnosing Simulation Errors
Choosing a Solver
“Examine Model Dynamics Using Solver Profiler”
“Solver Resets”
“Model Configuration Parameters: Diagnostics” on page 6-2
6-18
State name clash
Description
This parameter specifies whether the software issues a warning when multiple states in a model have
the same name. The software checks for name duplication across both continuous and discrete states.
This diagnostic applies only for simulations configured to log states using a format other than array.
State names are not used when you do not log states or when you log states using the Array format.
When you use the Array format or do not log states, the software never issues a diagnostic.
Settings
warning (default) | none
warning
The software issues a warning.
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: StateNameClashWarn
Value: 'none' | 'warning'
Default: 'warning'
Version History
Introduced in R2008a
See Also
States | Format
Topics
“Save Block States and Simulation Operating Points”
Diagnosing Simulation Errors
6-19
6 Diagnostics Parameters
6-20
Operating point restore interface checksum mismatch
Description
This parameter specifies whether the software issues a warning, an error, or no diagnostic when the
model interface checksum differs from the interface checksum saved in the
Simulink.op.ModelOperatingPoint object specified as the value for the Initial state parameter.
The interface checksum tracks a collection of model settings that might affect the simulation results,
including the solver settings and the sample times in the model. A difference in the interface
checksum might indicate that a simulation started from the initial operating point could produce
different results than a simulation of the model that runs from the start. This diagnostic can flag that
the interface checksum has changed but cannot indicate the exact effect of the difference on the
simulation results.
The model operating point is meant to resume simulation from the specified operating point as
though the simulation ran from the beginning without interruption. Changes you make in a model
between saving and restoring an operating point might lead to differences in the results of a
simulation that starts from the operating point.
When changes to the model affect the structure or algorithmic behavior of the model, the model
operating point object is no longer valid, and the software always issues an error. For some
nonstructural changes in the model, the differences in simulation results might not be significant.
The software always issues an error when you make these structural or algorithmic changes between
saving and restoring a model operating point:
In general, you can make these kinds of nonstructural changes to a model between saving and
restoring the model operating point:
For example, you might use the ode15s stiff solver for the initial portion of a simulation then
switch to the ode45 solver for the remainder.
• Changing model-level logging settings using the model configuration parameters on the Data
Import/Export pane of the Configuration Parameters dialog box.
6-21
6 Diagnostics Parameters
While these changes generally do not affect your ability to restore a model operating point, they
might affect the interface checksum for the model or lead to differences in the simulation results.
When these changes affect the interface checksum, the software issues a diagnostic based on the
setting for this parameter when you specify the initial state for a simulation as an operating point
saved before modifying the model.
Settings
warning (default) | error | none
warning
The software issues a warning.
error
The software issues an error and terminates the simulation.
none
The software does not issue a diagnostic.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: OperatingPointInterfaceChecksumMismatchMsg
Value: 'warning' | 'error' | 'none'
Default: 'warning'
Version History
Introduced in R2019a
6-22
Operating point restore interface checksum mismatch
The Operating point restore interface checksum mismatch parameter replaces the SimState
interface checksum mismatch parameter, which was introduced in R2009b. To programmatically
configure the parameter in previous releases, you used the
SimStateInterfaceChecksumMismatchMsg parameter. Starting in R2019a, use the
OperatingPointInterfaceChecksumMismatchMsg parameter.
See Also
Objects
Simulink.op.ModelOperatingPoint
Model Settings
Operating point object from a different release | Initial state | Save final operating point
Functions
Simulink.BlockDiagram.getChecksum
Topics
“Use Model Operating Point for Faster Simulation Workflow”
“Specify Initial State for Simulation”
“Model Configuration Parameters: Diagnostics” on page 6-2
6-23
7
The Diagnostics > Sample Time category includes parameters for detecting issues related to
sample time and sample time specifications.
Parameter Description
“Source block specifies -1 sample time” on page Select the diagnostic action to take if a source
7-3 block (such as a Sine Wave block) specifies a
sample time of -1.
“Multitask data transfer” on page 7-5 Select the diagnostic action to take if an invalid
rate transition occurred between two blocks
operating in multitasking mode.
“Single task data transfer” on page 7-7 Select the diagnostic action to take if a rate
transition occurred between two blocks operating
in single-tasking mode.
“Multitask conditionally executed subsystem” on Select the diagnostic action to take if Simulink
page 7-9 software detects a subsystem that may cause
data corruption or non-deterministic behavior.
“Tasks with equal priority” on page 7-11 Select the diagnostic action to take if Simulink
software detects two tasks with equal priority
that can preempt each other in the target system.
“Exported tasks rate transition” on page 7-15 Select the diagnostic action to take if Simulink
software detects unspecified data transfers
between exported tasks.
“Enforce sample times specified by Signal Select the diagnostic action to take if the sample
Specification blocks” on page 7-13 time of the source port of a signal specified by a
Signal Specification block differs from the
signal's destination port.
“Unspecified inheritability of sample time” on Select the diagnostic action to take if this model
page 7-16 contains S-functions that do not specify whether
they preclude this model from inheriting their
sample times from a parent model.
See Also
Related Examples
• Diagnosing Simulation Errors
• Solver Diagnostics on page 6-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
7-2
Source block specifies -1 sample time
Description
Select the diagnostic action to take if a source block (such as a Sine Wave block) specifies a sample
time of -1.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• The Random Source block does not obey this parameter. If its Sample time parameter is set to -1,
the Random Source block inherits its sample time from its output port and never produces
warnings or errors.
• Some Communications Toolbox™ blocks internally inherit sample times, which can be a useful and
valid modeling technique. Set this parameter to none for these types of models.
Command-Line Information
Parameter: InheritedTsInSrcMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
7-3
7 Diagnostics Parameters: Sample Time
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-4
Multitask data transfer
Description
Select the diagnostic action to take if an invalid rate transition occurred between two blocks
operating in multitasking mode.
Category: Diagnostics
Settings
Default: error
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This parameter allows you to adjust error checking for sample rate transitions between blocks
that operate at different sample rates.
• Use this option for models of real-time multitasking systems to ensure detection of illegal rate
transitions between tasks that can result in a task's output being unavailable when needed by
another task. You can then use Rate Transition blocks to eliminate such illegal rate transitions
from the model.
Command-Line Information
Parameter: MultiTaskRateTransMsg
Value: 'warning' | 'error'
Default: 'error'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Rate Transition
7-5
7 Diagnostics Parameters: Sample Time
7-6
Single task data transfer
Description
Select the diagnostic action to take if a rate transition occurred between two blocks that both operate
in single-tasking mode.
Category: Diagnostics
Settings
Default: none
none
The software takes no action.
warning
The software issues a warning.
error
The software terminates the simulation and issues an error message.
Tips
• This parameter allows you to adjust error checking for sample rate transitions between blocks
that operate at different sample rates.
• Use this parameter when you are modeling a single-tasking system. In such systems, task
synchronization is not an issue.
• Since variable-step solvers are always single tasking, this parameter applies to them.
• The Single task data transfer parameter affects the blocks that are inserted if the
Automatically handle rate transition for data transfer parameter is also selected. Those
inserted blocks might change the simulation results and block sorted order in some cases.
Programmatic Use
Parameter: SingleTaskRateTransMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution none or error
7-7
7 Diagnostics Parameters: Sample Time
See Also
Related Examples
• Rate Transition
• “Time-Based Scheduling and Code Generation” (Simulink Coder)
• Single-Tasking and Multitasking Execution Modes (Simulink Coder)
• “Rate Transitions and Data Transfers” (Simulink Coder)
• Treat each discrete rate as a separate task
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-8
Multitask conditionally executed subsystem
Description
Select the diagnostic action to take if Simulink software detects a subsystem that may cause data
corruption or non-deterministic behavior.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• These types of subsystems can be caused by either of the following conditions:
• Your model uses multitasking solver mode and it contains an enabled subsystem that operates
at multiple rates.
• Your model contains a conditionally executed subsystem that can reset its states and that
contains an asynchronous subsystem.
These types of subsystems can cause corrupted data or nondeterministic behavior in a real-time
system that uses code generated from the model.
• For models that use multitasking solver mode and contain an enabled subsystem that operates at
multiple rates, consider using single-tasking solver mode or using a single-rate enabled subsystem
instead.
• For models that contain a conditionally executed subsystem that can reset its states and that
contains an asynchronous subsystem, consider moving the asynchronous subsystem outside the
conditionally executed subsystem.
Command-Line Information
Parameter: MultiTaskCondExecSysMsg
Value: 'none' | 'warning' | 'error'
Default: 'error'
7-9
7 Diagnostics Parameters: Sample Time
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Treat each discrete rate as a separate task
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-10
Tasks with equal priority
Description
Select the diagnostic action to take if Simulink software detects two tasks with equal priority that can
preempt each other in the target system.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This condition can occur when one asynchronous task of the target represented by this model has
the same priority as one of the target's asynchronous tasks.
• This option must be set to Error if the target allows tasks having the same priority to preempt
each other.
Command-Line Information
Parameter: TasksWithSamePriorityMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution none or error
7-11
7 Diagnostics Parameters: Sample Time
See Also
Related Examples
• Diagnosing Simulation Errors
• “Rate Transitions and Asynchronous Blocks” (Simulink Coder)
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-12
Enforce sample times specified by Signal Specification blocks
Description
Select the diagnostic action to take if the sample time of the source port of a signal specified by a
Signal Specification block differs from the signal's destination port.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Note The setting of this diagnostic is ignored when the Default parameter behavior parameter in
the Code Generation > Optimization pane of the model Configuration Parameters is set to
Tunable.
Tips
• The Signal Specification block allows you to specify the attributes of the signal connected to its
input and output ports. If the specified attributes conflict with the attributes specified by the
blocks connected to its ports, Simulink software displays an error when it compiles the model, for
example, at the beginning of a simulation. If no conflict exists, Simulink software eliminates the
Signal Specification block from the compiled model.
• You can use the Signal Specification block to ensure that the actual attributes of a signal meet
desired attributes, or to ensure correct propagation of signal attributes throughout a model.
Command-Line Information
Parameter: SigSpecEnsureSampleTimeMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
7-13
7 Diagnostics Parameters: Sample Time
Application Setting
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Diagnosing Simulation Errors
• Signal Specification
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-14
Exported tasks rate transition
Description
Select the diagnostic action to take if Simulink software detects unspecified data transfers between
exported tasks.
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Command-Line Information
Parameter: ExportedTasksRateTransMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
7-15
7 Diagnostics Parameters: Sample Time
Description
Select the diagnostic action to take if this model contains S-functions that do not specify whether
they preclude this model from inheriting their sample times from a parent model.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• Not specifying an inheritance rule may lead to incorrect simulation results.
• Simulink software checks for this condition only if the solver used to simulate this model is a fixed-
step discrete solver and the periodic sample time constraint for the solver is set to ensure sample
time independence
• For more information, see Periodic sample time constraint.
Command-Line Information
Parameter: UnknownTsInhSupMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
7-16
Unspecified inheritability of sample time
See Also
Related Examples
• Diagnosing Simulation Errors
• Periodic sample time constraint
• Solver Diagnostics on page 6-2
• “Model Configuration Parameters: Sample Time Diagnostics” on page 7-2
7-17
8
The Diagnostics > Data Validity category includes parameters for detecting issues related to data
(signals, parameters, and states). These issues include:
On the Configuration Parameters dialog box, the following configuration parameters are on the Data
Validity pane.
Parameter Description
“Signal resolution” on page 8-6 Select how Simulink software resolves signals
and states to Simulink.Signal objects.
“Division by singular matrix” on page 8-8 Select the diagnostic action to take if the
Product, Matrix Multiply block detects a singular
matrix while inverting one of its inputs in matrix
multiplication mode.
“Underspecified data types” on page 8-10 Select the diagnostic action to take if Simulink
software could not infer the data type of a signal
during data type propagation.
“Simulation range checking” on page 8-12 Select the diagnostic action to take when signals
exceed specified minimum or maximum values.
“String truncation checking” on page 8-14 Select the diagnostic action to take if the string
signal is truncated.
“Wrap on overflow” on page 8-15 Select the diagnostic action to take if the value of
a signal overflows the signal data type and wraps
around.
“Underspecified dimensions” on page 8-19 Select the diagnostic action to take if Simulink
software could not infer the signal dimension at
compile time.
“Saturate on overflow” on page 8-17 Select the diagnostic action to take if the value of
a signal is too large to be represented by the
signal data type, resulting in a saturation.
“Inf or NaN block output” on page 8-20 Select the diagnostic action to take if the value of
a block output is Inf or NaN at the current time
step.
“"rt" prefix for identifiers” on page 8-22 Select the diagnostic action to take during code
generation if a Simulink object name (the name of
a parameter, block, or signal) begins with rt.
“Detect downcast” on page 8-24 Select the diagnostic action to take when a
parameter downcast occurs during code
generation.
8-2
Model Configuration Parameters: Data Validity
Parameter Description
“Detect overflow” on page 8-26 Select the diagnostic action when Simulink
detects a parameter overflow.
Bits of error threshold Set a threshold of one bit, half bit, or zero bits for
parameter overflow detection.
“Detect underflow” on page 8-30 Select the diagnostic action when Simulink
detects a parameter underflow.
“Detect precision loss” on page 8-32 Select the diagnostic action to take when
Simulink detects parameter precision loss.
Suppress double to single detection Suppress the double to single parameter
precision loss detection.
Absolute difference threshold Report parameter precision loss when the
quantization error exceeds both absolute and
relative difference thresholds.
Relative difference threshold Report parameter precision loss when the
quantization error exceeds both absolute and
relative difference thresholds.
“Detect loss of tunability” on page 8-40 Select the diagnostic action to take when an
expression with tunable variables is reduced to
its numerical equivalent in the generated code.
“Detect read before write” on page 8-42 Select the diagnostic action to take if the model
attempts to read data from a data store to which
it has not written data in this time step.
“Detect write after read” on page 8-44 Select the diagnostic action to take if the model
attempts to write data to a data store after
previously reading data from it in the current
time step.
“Detect write after write” on page 8-46 Select the diagnostic action to take if the model
attempts to write data to a data store twice in the
current time step.
“Multitask data store” on page 8-48 Select the diagnostic action to take when one
task reads data from a Data Store Memory block
to which another task writes data.
“Duplicate data store names” on page 8-50 Select the diagnostic action to take when the
model contains multiple data stores that have the
same name. The data stores can be defined with
Data Store Memory blocks or Simulink.Signal
objects.
Parameter Description
Array bounds exceeded Ensure that Simulink-allocated memory used in
S-functions does not write beyond its assigned
array bounds when writing to its outputs, states,
or work vectors.
8-3
8 Diagnostics Parameters: Data Validity
Parameter Description
Model Verification block enabling Enable model verification blocks in the current
model either globally or locally.
Detect multiple driving blocks executing at the Select the diagnostic action to take when the
same time step software detects a Merge block with more than
one driving block executing at the same time
step.
Underspecified initialization detection Select how Simulink software handles
initialization of initial conditions for conditionally
executed subsystems, Merge blocks, subsystem
elapsed time, and Discrete-Time Integrator
blocks.
Detect ambiguous custom storage class final Detect if a signal using a Reusable custom
values storage class does not have a unique endpoint.
The run-time environment should not read the
variable because its value is ambiguous.
Detect non-reused custom storage classes Detect if a signal uses a Reusable custom storage
class that the code generator cannot reuse with
other uses of the same Reusable custom storage
class. If the code generator cannot implement
reuse, the generated code will likely contain
additional global variables.
See Also
Related Examples
• Diagnosing Simulation Errors
• “Data Types Supported by Simulink”
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
8-4
Data Validity Diagnostics Overview
Configuration
Set the parameters displayed.
Tips
• To open the Data Validity pane, in the Simulink Editor, in the Modeling tab, click Model
Settings, then select Diagnostics > Data Validity.
• The options are typically to do nothing or to display a warning or an error message.
• A warning does not terminate a simulation, but an error does.
See Also
Related Examples
• “Model Configuration Parameters: Data Validity” on page 8-2
8-5
8 Diagnostics Parameters: Data Validity
Signal resolution
Description
Select how a model resolves signals and states to Simulink.Signal objects. See “Explicit and
Implicit Symbol Resolution” for more information.
Category: Diagnostics
Settings
Default: Explicit only
None
Do not perform signal resolution. None of the signals, states, Stateflow data, and MATLAB
Function block data in the model can resolve to Simulink.Signal objects.
This setting does not affect data stores that you define by creating Simulink.Signal objects
(instead of using Data Store Memory blocks).
Explicit only
Do not perform implicit signal resolution. Only explicitly specified signal resolution occurs. This is
the recommended setting.
Explicit and implicit
Perform implicit signal resolution wherever possible, without posting any warnings about the
implicit resolutions.
Explicit and warn implicit
Perform implicit signal resolution wherever possible, posting a warning of each implicit resolution
that occurs.
Tips
• To reduce the dependency of the model on variables and objects in workspaces and data
dictionaries, which can improve model portability, readability, and ease of maintenance, use None.
When you use this setting, migrate design attributes from existing Simulink.Signal objects into
the model by using block parameters and signal properties (for example, in the Model Data Editor
or in Signal Properties dialog boxes).
• Use the Signal Properties dialog box to specify explicit resolution for signals. For more
information, see Signal Properties.
• Use the State Attributes pane on dialog boxes of blocks that have discrete states, e.g., the
Discrete-Time Integrator block, to specify explicit resolution for discrete states.
• Multiple signals can resolve to the same signal object and have the properties that the object
specifies. However, the signal object cannot use a storage class other than Auto or Reusable.
• MathWorks® discourages using implicit signal resolution except for fast prototyping, because
implicit resolution slows performance, complicates model validation, and can have
nondeterministic effects.
8-6
Signal resolution
Command-Line Information
Parameter: SignalResolutionControl
Value: 'None' | 'UseLocalSettings' | 'TryResolveAll' | 'TryResolveAllWithWarning'
Default: 'UseLocalSettings'
Recommended Settings
Application Setting
Debugging Explicit only or None
Traceability Explicit only or None
Efficiency Explicit only or None
Safety precaution Explicit only
See Also
Objects
Simulink.Signal
Tools
Signal Properties
Related Examples
• Diagnosing Simulation Errors
• Discrete-Time Integrator
• “Model Configuration Parameters: Data Validity” on page 8-2
8-7
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the Product, Matrix Multiply block detects a singular matrix
while inverting one of its inputs in matrix multiplication mode.
Category: Diagnostics
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
For models referenced in Accelerator mode, Simulink ignores the Division by singular matrix
parameter setting if you set it to a value other than None.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration parameter settings during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
Command-Line Information
Parameter: CheckMatrixSingularityMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
8-8
Division by singular matrix
See Also
Related Examples
• Diagnosing Simulation Errors
• Product, Matrix Multiply
• “Model Configuration Parameters: Data Validity” on page 8-2
8-9
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if Simulink software could not infer the data type of a signal
during data type propagation.
Category: Diagnostics
This example shows how to use the configuration parameter Underspecified data types to identify
and resolve an underspecified data type.
The data type of the Constant block output signal is underspecified because the source and
destination blocks each apply an inherited data type. The signal cannot identify an explicit data type
to inherit. In cases like this, Simulink applies heuristic rules to select a data type to use.
To resolve the underspecified data type, you can use one of these techniques:
• On the Signal Attributes tab of the Constant block dialog box, specify Output data type as a
particular numeric type, such as uint8.
• On the Signal Attributes tab of the Sum block dialog box, select the check box Require all
inputs to have the same data type. With this setting, the Sum block applies the data type of the
first input, uint8, to the underspecified data type of the second input.
Settings
Default: none
none
Simulink software takes no action.
8-10
Underspecified data types
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Command-Line Information
Parameter: UnderSpecifiedDataTypeMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Default for underspecified data type
• Diagnosing Simulation Errors
• “Use single Data Type as Default for Underspecified Types” (Embedded Coder)
• “Model Configuration Parameters: Data Validity” on page 8-2
8-11
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take when signals exceed specified minimum or maximum values.
Category: Diagnostics
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• For information about specifying minimum and maximum values for signals and about how
Simulink checks nondouble signals, see “Specify Signal Ranges”.
• For referenced models in Accelerator mode, Simulink performs signal range checking for only
root-level I/O signals. It does not check internal signals.
• If you have an Embedded Coder license, you can perform signal range checking in top-model or
Model block software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations (Embedded
Coder).
Command-Line Information
Parameter: SignalRangeChecking
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging warning or error
Traceability warning or error
Efficiency none
Safety precaution error
8-12
Simulation range checking
See Also
Related Examples
• “Specify Signal Ranges”
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-13
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the string signal is truncated.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Command-Line Information
Parameter:StringTruncationChecking
Value: 'none' | 'warning' | 'error'
Default: 'error'
Recommended Settings
Application Setting
Debugging error
Traceability No impact
Efficiency No impact
Safety precaution error
8-14
Wrap on overflow
Wrap on overflow
Description
Select the diagnostic action to take if the value of a signal overflows the signal data type and wraps
around.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation or code generation and displays an error message.
Tips
• This diagnostic applies only to overflows which wrap for integer and fixed-point data types.
• This diagnostic also reports division by zero for all data types, including floating-point data types.
• To check for floating-point overflows (for example, Inf or NaN) for double or single data types,
select the Inf or NaN block output diagnostic. (See “Inf or NaN block output” on page 8-20 for
more information.)
• If a floating-point to integer or floating-point to fixed-point overflow is signaled, set the model
parameter EfficientFloat2IntCast to 'off' to ensure that simulation and the generated
code agree. See Remove code from floating-point to integer conversions that wraps out-of-range
values (Simulink Coder) for more detail.
• For models referenced in accelerator mode, Simulink ignores the Wrap on overflow parameter
setting if you set it to a value other than None.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration parameter settings during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
• During code generation, Simulink may simulate a few blocks in the model for optimization
purposes. If simulation of these blocks triggers this diagnostic to report an error, the software
terminates code generation.
8-15
8 Diagnostics Parameters: Data Validity
Command-Line Information
Parameter: IntegerOverflowMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• “Handle Overflows in Simulink Models” (Fixed-Point Designer)
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• “Model Configuration Parameters: Data Validity” on page 8-2
8-16
Saturate on overflow
Saturate on overflow
Description
Select the diagnostic action to take if the value of a signal is too large to be represented by the signal
data type, resulting in a saturation.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation or code generation and displays an error message.
Tips
• This diagnostic applies only to overflows which saturate for integer and fixed-point data types.
• To check for floating-point overflows (for example, Inf or NaN) for double or single data types,
select the Inf or NaN block output diagnostic. (See “Inf or NaN block output” on page 8-20 for
more information.)
• During code generation, Simulink may simulate a few blocks in the model for optimization
purposes. If simulation of these blocks triggers this diagnostic to report an error, the software
terminates code generation.
Command-Line Information
Parameter: IntegerSaturationMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact
Safety precaution error
8-17
8 Diagnostics Parameters: Data Validity
See Also
Related Examples
• “Handle Overflows in Simulink Models” (Fixed-Point Designer)
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• “Model Configuration Parameters: Data Validity” on page 8-2
8-18
Underspecified dimensions
Underspecified dimensions
Description
Select the diagnostic action to take if Simulink software could not infer the signal dimension at
compile time.
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Command-Line Information
Parameter: UnderSpecifiedDimensionMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
8-19
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the value of a block output is Inf or NaN at the current time
step.
Category: Diagnostics
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This diagnostic applies only to floating-point overflows for double or single data types.
• To check for integer and fixed-point overflows, select the Wrap on overflow diagnostic. (See
“Wrap on overflow” on page 8-15 for more information.)
• For models referenced in accelerator mode, Simulink ignores the Info or NaN block output
parameter setting if you set it to a value other than None.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration parameter settings during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
Command-Line Information
Parameter: SignalInfNanChecking
Value: 'none' | 'warning' | 'error'
Default: 'none'
8-20
Inf or NaN block output
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• “Validate a Floating-Point Embedded Model”
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-21
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take during code generation if a Simulink object name (the name of a
parameter, block, or signal) begins with rt.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• The default setting (error) causes code generation to terminate with an error if it encounters a
Simulink object name (parameter, block, or signal), that begins with rt.
• This is intended to prevent inadvertent clashes with generated identifiers whose names begins
with rt.
Command-Line Information
Parameter: RTPrefix
Value: 'none' | 'warning' | 'error'
Default: 'error'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
8-22
"rt" prefix for identifiers
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-23
8 Diagnostics Parameters: Data Validity
Detect downcast
Description
Select the diagnostic action to take when a parameter downcast occurs during code generation.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates code generation and displays an error message.
Tips
• A parameter downcast occurs if the computation of block output required converting the
parameter's specified type to a type having a smaller range of values (for example, from uint32
to uint8).
• This diagnostic applies only to named tunable parameters (parameters with a non-Auto storage
class).
Command-Line Information
Parameter: ParameterDowncastMsg
Value: 'none' | 'warning' | 'error'
Default: 'error'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
8-24
Detect downcast
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-25
8 Diagnostics Parameters: Data Validity
Detect overflow
Description
Select the diagnostic action when Simulink detects a parameter overflow.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• A parameter overflow occurs if Simulink software encounters a parameter whose data type's
range is not large enough to accommodate the parameter's ideal value (the ideal value is either
too large or too small to be represented by the data type). For example, suppose that the
parameter's ideal value is 200 and its data type is int8. Overflow occurs in this case because the
maximum value that int8 can represent is 127.
• Parameter overflow differs from parameter precision loss, which occurs when the ideal parameter
value is within the range of the data type and scaling being used, but cannot be represented
exactly.
• Both parameter overflow and precision loss are quantization errors, and the distinction between
them can be a fine one. The Detect overflow diagnostic reports all quantization errors greater
than one bit. For very small parameter quantization errors, precision loss will be reported rather
than an overflow when
where
Command-Line Information
Parameter: ParameterOverflowMsg
Value: 'none' | 'warning' | 'error'
8-26
Detect overflow
Default: 'error'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-27
8 Diagnostics Parameters: Data Validity
Description
The Bits of error threshold parameter specifies a threshold of one bit, half bit, or zero bits for
diagnostic reporting of parameter overflows.
Dependencies
To enable this parameter, set the Detect overflow parameter to warning or error.
Settings
One bit (default) | Half bit | Zero bits
One bit
Parameter overflow diagnostics are reported when the overflow exceeds the representable range
by one bit or more.
Half bit
Parameter overflow diagnostics are reported when the overflow exceeds the representable range
by half bit or more.
Zero bits
Parameter overflow diagnostics are reported when the overflow exceeds the representable range
by zero bits or more.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Zero bits
Programmatic Use
Parameter: ParamOverflowErrorThreshold
Type: string | character vector
Values: 'OneBit' | 'HalfBit' | 'ZeroBit'
Default: 'OneBit'
Version History
Introduced in R2024a
8-28
Bits of error threshold
See Also
Model Settings
Detect overflow
Apps
Parameter Quantization Advisor
8-29
8 Diagnostics Parameters: Data Validity
Detect underflow
Description
Select the diagnostic action when Simulink detects a parameter underflow.
Category: Diagnostics
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• Parameter underflow occurs when Simulink software encounters a parameter whose data type
does not have enough precision to represent the parameter's ideal value because the ideal value is
too small.
• When parameter underflow occurs, casting the ideal non-zero value to the parameter's data type
causes the modeled value to become zero.
• Parameter underflow can occur for any data type, including floating-point, fixed-point, and integer
data types. For example, the ideal value 1e-46 will quantize to zero for single-precision, half-
precision, all integer types, and most commonly used fixed-point types.
• The absolute quantization error will be small relative to the precision of the data type, but the
relative quantization error will be 100%. Depending on how the parameter is used in your
algorithm, the effects of underflow will be significant. For example, if the parameter is directly
used in multiplication or division, then the impact of a 100% relative quantization error can be
significant.
Command-Line Information
Parameter: ParameterUnderflowMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
8-30
Detect underflow
Application Setting
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-31
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take when Simulink detects parameter precision loss.
Category: Diagnostics
Settings
Default: warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• Precision loss occurs when Simulink software encounters a parameter whose data type does not
have enough precision to represent the parameter's value exactly. As a result, the modeled value
differs from the ideal value.
• Parameter precision loss differs from parameter overflow, which occurs when the range of the
parameter's data type, i.e., that maximum value that it can represent, is smaller than the ideal
value of the parameter.
• Both parameter overflow and precision loss are quantization errors, and the distinction between
them can be a fine one. The Detect Parameter overflow diagnostic reports all parameter
quantization errors greater than one bit. For very small parameter quantization errors, precision
loss will be reported rather than an overflow when
where
Command-Line Information
Parameter: ParameterPrecisionLossMsg
Value: 'none' | 'warning' | 'error'
Default: 'warning'
8-32
Detect precision loss
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Related Examples
• Diagnosing Simulation Errors
• “Model Configuration Parameters: Data Validity” on page 8-2
8-33
8 Diagnostics Parameters: Data Validity
Description
The Suppress double to single detection parameter allows you to suppress parameter precision
loss diagnostic messages that result from double precision to single precision casts.
Dependencies
To enable this parameter, set the Detect precision loss parameter to warning or error.
Settings
off (default) | on
off
Report parameter precision loss diagnostics for double to single casts.
on
Suppress parameter precision loss diagnostics for double to single casts.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution off
Programmatic Use
Parameter: ParamSuppressDoubleToSinglePrecisionLossMsg
Type: string | character vector
Values: 'off' | 'on'
Default: 'off'
Version History
Introduced in R2024a
See Also
Model Settings
Detect precision loss | Absolute difference threshold | Relative difference threshold
8-34
Suppress double to single detection
Apps
Parameter Quantization Advisor
8-35
8 Diagnostics Parameters: Data Validity
Description
The Absolute difference threshold parameter allows you to specify a threshold for parameter
precision loss diagnostics. Precision loss is reported only when the quantization error exceeds both
the absolute and relative difference thresholds.
Dependencies
To enable this parameter, set the Detect precision loss parameter to warning or error.
Settings
0.0 (default) | nonnegative real scalar double
Threshold for the absolute difference between the ideal parameter value and the quantized
parameter value, specified as a nonnegative real scalar double. Parameter precision loss diagnostics
are reported when the quantization error exceeds both the absolute and relative difference
thresholds.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution 0.0
Programmatic Use
Parameter: ParamPrecisionLossAbsoluteDiffThreshold
Type: string | character vector
Values: 0.0 | non-negative real scalar double
Default: 0.0
Version History
Introduced in R2024a
8-36
Absolute difference threshold
See Also
Model Settings
Detect precision loss | Relative difference threshold | Suppress double to single detection
Apps
Parameter Quantization Advisor
8-37
8 Diagnostics Parameters: Data Validity
Description
The Relative difference threshold parameter allows you to specify a threshold for parameter
precision loss diagnostics. Precision loss is reported only when the quantization error exceeds both
the absolute and relative difference thresholds.
Dependencies
To enable this parameter, set the Detect precision loss parameter to warning or error.
Settings
0.0 (default) | nonnegative real scalar double
Threshold for the relative difference between the ideal parameter value and the quantized parameter
value, specified as a nonnegative real scalar double. Parameter precision loss diagnostics are
reported when the quantization error exceeds both the absolute and relative difference thresholds.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution 0.0
Programmatic Use
Parameter: ParamPrecisionLossRelativeDiffThreshold
Type: string | character vector
Values: 0.0 | non-negative real scalar double
Default: 0.0
Version History
Introduced in R2024a
See Also
Model Settings
Detect precision loss | Absolute difference threshold | Suppress double to single detection
8-38
Relative difference threshold
Apps
Parameter Quantization Advisor
8-39
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take when an expression with tunable variables is reduced to its
numerical equivalent in the generated code.
Category: Diagnostics
Settings
Default: warning for GRT targets | error for ERT targets
none
Take no action.
warning
Generate a warning.
error
Terminate simulation or code generation and generate an error.
Tips
• This diagnostic applies only to the following:
Command-Line Information
Parameter: ParameterTunabilityLossMsg
Type: character vector
Value: 'none' | 'warning' | 'error'
Default: 'warning' for GRT targets | 'error' for ERT targets
8-40
Detect loss of tunability
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Default parameter behavior
Related Examples
• Diagnosing Simulation Errors
• “Tunable Expression Limitations” (Simulink Coder)
• “Model Configuration Parameters: Data Validity” on page 8-2
8-41
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the model attempts to read data from a data store to which it
has not written data in this time step.
Category: Diagnostics
Settings
Default: Use local settings
Note During model referencing simulation in accelerator and rapid accelerator mode, if the Detect
read before write parameter is set to Enable all as warnings, Enable all as errors, or
Use local settings, Simulink temporarily changes the setting to Disable all.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration this parameter setting during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
Command-Line Information
Parameter: ReadBeforeWriteMsg
Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' |
'EnableAllAsError'
Default: 'UseLocalSettings'
8-42
Detect read before write
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Enable all as errors
See Also
Simulink.Signal
Related Examples
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• Data Store Memory
• “Model Configuration Parameters: Data Validity” on page 8-2
8-43
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the model attempts to write data to a data store after previously
reading data from it in the current time step.
Category: Diagnostics
Settings
Default: Use local settings
Note During model referencing simulation in accelerator and rapid accelerator mode, if the Detect
write after read parameter is set to Enable all as warnings, Enable all as errors, or Use
local settings, Simulink temporarily changes the setting to Disable all.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration this parameter setting during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
Command-Line Information
Parameter: WriteAfterReadMsg
Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' |
'EnableAllAsError'
Default: 'UseLocalSettings'
8-44
Detect write after read
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Enable all as errors
See Also
Simulink.Signal
Related Examples
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• Data Store Memory
• “Model Configuration Parameters: Data Validity” on page 8-2
8-45
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take if the model attempts to write data to a data store twice in the
current time step.
Category: Diagnostics
Settings
Default: Use local settings
Note During model referencing simulation in accelerator and rapid accelerator mode, if the Detect
write after write parameter is set to Enable all as warnings, Enable all as errors, or
Use local settings, Simulink temporarily changes the setting to Disable all.
You can use the Model Advisor to identify referenced models for which Simulink changes
configuration this parameter setting during accelerated simulation.
1 In the Simulink Editor, in the Modeling tab, click Model Advisor, then click OK.
2 Select By Task.
3 Run the Check diagnostic settings ignored during accelerated model reference
simulation check.
Command-Line Information
Parameter: WriteAfterWriteMsg
Value: 'UseLocalSettings' | 'DisableAll' | 'EnableAllAsWarning' |
'EnableAllAsError'
Default: 'UseLocalSettings'
8-46
Detect write after write
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Enable all as errors
See Also
Simulink.Signal
Related Examples
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• Data Store Memory
• “Model Configuration Parameters: Data Validity” on page 8-2
8-47
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take when one task reads data from a Data Store Memory block to
which another task writes data.
Category: Diagnostics
Settings
Default: error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• Such a situation is safe only if one of the tasks cannot interrupt the other, such as when the data
store is a scalar and the writing task uses an atomic copy operation to update the store or the
target does not allow the tasks to preempt each other.
• You should disable this diagnostic (set it to none) only if the application warrants it, such as if the
application uses a cyclic scheduler that prevents tasks from preempting each other.
Command-Line Information
Parameter: MultiTaskDSMMsg
Value: 'none' | 'warning' | 'error'
Default: 'error'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
See Also
Simulink.Signal
8-48
Multitask data store
Related Examples
• Diagnosing Simulation Errors
• “Local and Global Data Stores”
• Data Store Memory
• “Model Configuration Parameters: Data Validity” on page 8-2
8-49
8 Diagnostics Parameters: Data Validity
Description
Select the diagnostic action to take when the model contains multiple data stores that have the same
name. The data stores can be defined with Data Store Memory blocks or Simulink.Signal objects.
Category: Diagnostics
Settings
Default: none
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tip
This diagnostic is useful for detecting errors that can occur when a lower-level data store
unexpectedly shadows a higher-level data store that has the same name.
Command-Line Information
Parameter: UniqueDataStoreMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
See Also
Simulink.Signal
Related Examples
• Diagnosing Simulation Errors
8-50
Duplicate data store names
8-51
9
The Diagnostics > Type Conversion category includes parameters for detecting issues related to
data type conversions (for example, from int32 to single).
Parameter Description
Unnecessary type conversions Diagnostic action to take when unnecessary Data
Type Conversion block is detected
Vector/matrix block input conversion Diagnostic action to take when vector-to-matrix
or matrix-to-vector conversion occurs at block
input
32-bit integer to single precision float conversion Diagnostic action to take when 32-bit integer
value converted to floating-point value
Detect underflow Diagnostic action to take when fixed-point
constant underflow occurs
Detect precision loss Diagnostic action to take when fixed-point
constant precision loss occurs
Detect overflow Diagnostic action to take when fixed-point
constant overflow occurs
See Also
Related Examples
• Diagnosing Simulation Errors
• “Data Types Supported by Simulink”
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
9-2
Unnecessary type conversions
Description
The Unnecessary type conversions parameter specifies the diagnostic action to take when
Simulink software detects a Data Type Conversion block used where no type conversion is necessary.
Settings
none (default) | warning
none
Simulink software takes no action.
warning
Simulink software displays a warning.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution warning
Programmatic Use
Parameter: UnnecessaryDatatypeConvMsg
Value: 'none' | 'warning'
Default: 'none'
Version History
Introduced in R2008a
See Also
Topics
Diagnosing Simulation Errors
Data Type Conversion
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-3
9 Diagnostics Parameters: Type Conversion
Description
The Vector/matrix block input conversion parameter specifies the diagnostic action to take when
Simulink software detects a vector-to-matrix or matrix-to-vector conversion at a block input.
Settings
none (default) | warning | error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
Simulink software converts vectors to row or column matrices and row or column matrices to vectors
under the following circumstances:
• If a vector signal is connected to an input that requires a matrix, Simulink software converts the
vector to a one-row or one-column matrix.
• If a one-column or one-row matrix is connected to an input that requires a vector, Simulink
software converts the matrix to a vector.
• If the inputs to a block consist of a mixture of vectors and matrices and the matrix inputs all have
one column or one row, Simulink software converts the vectors to matrices having one column or
one row, respectively.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: VectorMatrixConversionMsg
9-4
Vector/matrix block input conversion
Version History
Introduced in R2008a
See Also
Topics
Diagnosing Simulation Errors
Determining Output Signal Dimensions
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-5
9 Diagnostics Parameters: Type Conversion
Description
The 32-bit integer to single precision float conversion parameter specifies the diagnostic action
to take when Simulink software detects a 32-bit integer value was converted to a floating-point value.
Settings
warning (default) | none
warning
Simulink software displays a warning.
none
Simulink software takes no action.
Tip
Converting a 32-bit integer value to a floating-point value can result in a loss of precision. See
Working with Data Types for more information.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution warning
Programmatic Use
Parameter: Int32ToFloatConvMsg
Value: 'none' | 'warning'
Default: 'warning'
Limitations
• The software only detects parameter conversions and not signal conversions.
• The software only detects conversions during code generation and not simulation.
Version History
Introduced in R2008a
9-6
32-bit integer to single precision float conversion
See Also
Topics
Diagnosing Simulation Errors
Working with Data Types
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-7
9 Diagnostics Parameters: Type Conversion
Detect underflow
Diagnostic action to take when fixed-point constant underflow occurs
Description
The Detect underflow parameter specifies the diagnostic action to take when a fixed-point constant
underflow occurs during simulation.
Dependencies
This parameter requires a Fixed-Point Designer license.
Settings
none (default) | warning | error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This diagnostic applies only to fixed-point constants (net slope and net bias).
• Fixed-point constant underflow occurs when Simulink software encounters a fixed-point constant
whose data type does not have enough precision to represent the ideal value of the constant
because the ideal value is too small.
• When fixed-point constant underflow occurs, casting the ideal value to the data type causes the
value of the fixed-point constant to become zero, and therefore to differ from its ideal value.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter:FixptConstUnderflowMsg
9-8
Detect underflow
Version History
Introduced in R2009b
See Also
Topics
Net Slope and Net Bias Precision Issues (Fixed-Point Designer)
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-9
9 Diagnostics Parameters: Type Conversion
Description
The Detect precision loss parameter specifies the diagnostic action to take when a fixed-point
constant precision loss occurs during simulation.
Dependencies
This parameter requires a Fixed-Point Designer license.
Settings
none (default) | warning | error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This diagnostic applies only to fixed-point constants (net slope and net bias).
• Precision loss occurs when Simulink software converts a fixed-point constant to a data type which
does not have enough precision to represent the exact value of the constant. As a result, the
quantized value differs from the ideal value.
• Fixed-point constant precision loss differs from fixed-point constant overflow. Overflow occurs
when the range of the parameter's data type, that is, the maximum value that it can represent, is
smaller than the ideal value of the parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
9-10
Detect precision loss
Programmatic Use
Parameter:FixptConstPrecisionLossMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2010b
See Also
Topics
Net Slope and Net Bias Precision Issues (Fixed-Point Designer)
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-11
9 Diagnostics Parameters: Type Conversion
Detect overflow
Diagnostic action to take when fixed-point constant overflow occurs
Description
The Detect overflow parameter specifies the diagnostic action to take when a fixed-point constant
overflow occurs during simulation.
Dependencies
This parameter requires a Fixed-Point Designer license.
Settings
none (default) | warning | error
none
Simulink software takes no action.
warning
Simulink software displays a warning.
error
Simulink software terminates the simulation and displays an error message.
Tips
• This diagnostic applies only to fixed-point constants (net slope and net bias).
• Overflow occurs when the Simulink software converts a fixed-point constant to a data type whose
range is not large enough to accommodate the ideal value of the constant. The ideal value is either
too large or too small to be represented by the data type. For example, suppose that the ideal
value is 200 and the converted data type is int8. Overflow occurs in this case because the
maximum value that int8 can represent is 127.
• Fixed-point constant overflow differs from fixed-point constant precision loss. Precision loss occurs
when the ideal fixed-point constant value is within the range of the data type and scaling being
used, but cannot be represented exactly.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
9-12
Detect overflow
Programmatic Use
Parameter:FixptConstOverflowMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2009b
See Also
Topics
Net Slope and Net Bias Precision Issues (Fixed-Point Designer)
“Model Configuration Parameters: Type Conversion Diagnostics” on page 9-2
9-13
10
The Diagnostics > Connectivity pane of the Configuration Parameters dialog box includes
parameters for detecting issues related to signal line connectivity.
To open the Configuration Parameters dialog box, in the Simulink Toolstrip, on the Modeling tab,
click Model Settings.
Parameter Description
Signal label mismatch Diagnostic action to take when signal has
multiple names through propagation
Unconnected block input ports Diagnostic action to take when block has
unconnected input
Unconnected block output ports Diagnostic action to take when block has
unconnected output
Unconnected line Diagnostic action to take when model has
unconnected line or unmatched Goto or From
block
Unspecified bus object at root Outport block Diagnostic action to take when root Outport block
of referenced model does not specify
Simulink.Bus object for bus output
Element name mismatch Diagnostic action to take when bus element name
does not match corresponding
Simulink.BusElement object name
Bus signal treated as vector Diagnostic action to take when virtual bus is
treated as vector
Non-bus signals treated as bus signals Diagnostic action to take when nonbus signals
are treated as buses
Repair bus selections Diagnostic action to take when upstream bus
hierarchy changes break selections
Context-dependent inputs Diagnostic action to take when function-call
subsystem can change its inputs
See Also
Related Examples
• Diagnosing Simulation Errors
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
10-2
Signal label mismatch
Description
The Signal label mismatch configuration parameter determines the diagnostic action to take when
a signal has different names as the signal propagates through blocks in a model. This diagnostic does
not check for signal label mismatches on a virtual bus.
Settings
none (default) | warning | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SignalLabelMismatchMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2006b
See Also
Topics
“Signal Names and Labels”
Diagnosing Simulation Errors
10-3
10 Diagnostics Parameters: Connectivity
10-4
Unconnected block input ports
Description
The Unconnected block input ports configuration parameter determines the diagnostic action to
take when the model contains a block with an unconnected input.
Settings
none (default) | warning | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: UnconnectedInputMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
The default behavior of new models is for the software to take no action when a block has an
unconnected input. For models created in previous releases, the default behavior was for the
software to display a warning.
10-5
10 Diagnostics Parameters: Connectivity
See Also
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-6
Unconnected block output ports
Description
The Unconnected block output ports configuration parameter determines the diagnostic action to
take when the model contains a block with an unconnected output.
Settings
none (default) | warning | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: UnconnectedOutputMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
The default behavior of new models is for the software to take no action when a block has an
unconnected output. For models created in previous releases, the default behavior was for the
software to display a warning.
10-7
10 Diagnostics Parameters: Connectivity
See Also
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-8
Unconnected line
Unconnected line
Diagnostic action to take when model has unconnected line or unmatched Goto or From block
Description
The Unconnected line configuration parameter determines the diagnostic action to take when the
model contains an unconnected line or an unmatched Goto or From block.
Settings
none (default) | warning | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: UnconnectedLineMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
The default behavior of new models is for the software to take no action when a block has an
unconnected line or an unmatched Goto or From block. For models created in previous releases, the
default behavior was for the software to display a warning.
10-9
10 Diagnostics Parameters: Connectivity
See Also
Goto | From
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-10
Unspecified bus object at root Outport block
Description
The Unspecified bus object at root Outport block configuration parameter determines the
diagnostic action to take when generating a simulation target for a referenced model if any root
Outport block of the referenced model receives a bus and does not specify a Simulink.Bus object.
Settings
warning (default) | none | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Tips
• This diagnostic applies only when a model is used as a referenced model. Simulating or updating
the model on its own does not invoke the diagnostic.
• A root Out Bus Element block does not require a Simulink.Bus object for the corresponding
Model block to output a bus.
• When a root Outport block receives a virtual bus and does not specify a Simulink.Bus object,
the corresponding Model block output is a vector.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: RootOutportRequireBusObject
Value: 'none' | 'warning' | 'error'
Default: 'warning'
10-11
10 Diagnostics Parameters: Connectivity
Version History
Introduced in R2006b
See Also
Objects
Simulink.Bus
Blocks
Outport | Out Bus Element
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-12
Element name mismatch
Description
The Element name mismatch configuration parameter determines the diagnostic action to take if
the name of a bus element does not match the name specified by the corresponding
Simulink.BusElement object.
Settings
warning (default) | none | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Tips
• You can use this diagnostic along with bus objects to ensure that your model meets bus element
naming requirements imposed by some blocks, such as the Switch block.
• With a Bus Creator block, you can enforce strong data typing by using the Use names from
inputs instead of from bus object block parameter.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: BusObjectLabelMismatch
Value: 'none' | 'warning' | 'error'
Default: 'warning'
10-13
10 Diagnostics Parameters: Connectivity
Version History
Introduced before R2006a
See Also
Simulink.Bus | Simulink.BusElement
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-14
Bus signal treated as vector
Description
The Bus signal treated as vector configuration parameter determines the diagnostic action to take
when the software treats a virtual bus as a vector.
Settings
none (default) | warning | error
none
The software does not check for virtual buses treated as vectors.
warning
The software displays a warning when it detects a virtual bus treated as a vector.
error
The software terminates the simulation and displays an error message when it builds a model
that treats a virtual bus as a vector.
Tips
• The diagnostic considers a virtual bus to be treated as a vector if the bus is input to a block that
does not accept virtual buses. For more information, see “Bus-Capable Blocks”.
• Virtual buses can be treated as vectors only when all constituent signals have the same attributes.
• To identify and correct buses used as vectors, use the Model Advisor check Check bus signals
treated as vectors or the function Simulink.BlockDiagram.addBusToVector.
• To replace an implicit bus-to-vector conversion with an explicit conversion, use the Bus to Vector
block.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: StrictBusMsg
Value1: 'ErrorLevel1' | 'WarnOnBusTreatedAsVector' | 'ErrorOnBusTreatedAsVector'
Default: 'ErrorLevel1'
10-15
10 Diagnostics Parameters: Connectivity
Version History
Introduced in R2006a
See Also
Blocks
Bus to Vector | Demux
Functions
Simulink.BlockDiagram.addBusToVector
Checks
Check virtual bus inputs to blocks | Check bus signals treated as vectors
Topics
Diagnosing Simulation Errors
“Bus-Capable Blocks”
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
1 This table maps the programmatic values to the equivalent interactive values of the Bus signal treated as
vector configuration parameter.
10-16
Non-bus signals treated as bus signals
Description
The Non-bus signals treated as bus signals configuration parameter determines the diagnostic
action to take when the software implicitly converts a nonbus signal to a bus to support connection to
a Bus Assignment or Bus Selector block. For the software to implicitly convert a nonbus signal to a
bus, the model must select the signal from a bus before passing it to a Bus Assignment or Bus
Selector block.
Settings
none (default) | warning | error
none
The software implicitly converts nonbus signals to buses.
warning
The software displays a warning that lists the converted signals and implicitly converts nonbus
signals to buses.
error
The software displays an error and terminates the simulation. The error message lists the nonbus
signals being treated as buses.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: NonBusSignalsTreatedAsBus
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2011b
10-17
10 Diagnostics Parameters: Connectivity
See Also
Functions
Simulink.BlockDiagram.addBusToVector
Blocks
Bus to Vector | Demux
Topics
Diagnosing Simulation Errors
“Bus-Capable Blocks”
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-18
Repair bus selections
Description
The Repair bus selections configuration parameter determines the diagnostic action to take when
changes to the upstream bus hierarchy break selections for Bus Selector and Bus Assignment blocks.
By default, the software repairs the selections.
Settings
Warn and repair (default) | Error without repair
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Warn and repair
Programmatic Use
Parameter: BusNameAdapt
Values: 'WarnAndRepair' | 'ErrorWithoutRepair'
Default: 'WarnAndRepair'
Version History
Introduced in R2010a
See Also
Topics
“Resolve Circular Dependencies in Buses”
Diagnosing Simulation Errors
10-19
10 Diagnostics Parameters: Connectivity
“Bus-Capable Blocks”
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-20
Context-dependent inputs
Context-dependent inputs
Diagnostic action to take when function-call subsystem can change its inputs
Description
The Context-dependent inputs configuration parameter determines the diagnostic action to take
when the software must compute any function-call subsystem inputs directly or indirectly during
execution of a call to a function-call subsystem. This situation occurs when executing a function-call
subsystem that can change its inputs.
To fix an error or warning generated by this diagnostic, use one of these approaches:
• For an Inport block in a function-call subsystem, select the Latch input for feedback signals of
function-call subsystem outputs parameter.
• For an Inport block at the root-level of a model that contains a Trigger block with Trigger type
set as function-call and that is referenced by a Model block, select the Latch input for
feedback signals of function-call subsystem outputs parameter.
• Place a Function-Call Feedback Latch block on the feedback signal.
For examples of function-call subsystems and these approaches, see “Simulink Subsystem
Semantics”.
Settings
error (default) | warning
error
The software displays an error for context-dependent inputs.
warning
The software displays a warning for context-dependent inputs.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Error
Programmatic Use
Parameter: FcnCallInpInsideContextMsg
Value: 'Error'| 'Warning'
Default: 'Error'
10-21
10 Diagnostics Parameters: Connectivity
Version History
Introduced in R2006b
See Also
Blocks
Function-Call Subsystem
Model Settings
Pass fixed-size scalar root inputs by value for code generation
Topics
“Using Function-Call Subsystems”
“Simulink Subsystem Semantics”
Diagnosing Simulation Errors
“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2
10-22
11
The Diagnostics > Compatibility category includes parameters for detecting issues when you use a
model that you created in an earlier release.
Parameter Description
S-function upgrades needed Select the diagnostic action to take if Simulink
software encounters a block that has not been
upgraded to use features of the current release.
Block behavior depends on frame status of signal Select the diagnostic action to take when
Simulink software encounters a block whose
behavior depends on the frame status of a signal.
Operating point object from a different release Use this check to report that a
Simulink.op.ModelOperatingPoint object
was generated by an earlier version of Simulink.
See Also
Related Examples
• Diagnosing Simulation Errors
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• “Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
11-2
Compatibility Diagnostics Overview
Configuration
Set the parameters displayed.
Tips
• To open the Compatibility pane, in the Simulink Editor, in the Modeling tab, click Model
Settings, then select Diagnostics > Compatibility.
• The options are typically to do nothing or to display a warning or an error message.
• A warning does not terminate a simulation, but an error does.
See Also
Related Examples
• “Model Configuration Parameters: Compatibility Diagnostics” on page 11-2
11-3
11 Diagnostics Parameters: Compatibility
Description
Select the diagnostic action to take if a model contains a block that has not been upgraded to use
features of the current release.
Settings
none (default) | warning | error
Default: none
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software terminates simulation and issues an error.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter:SFcnCompatibilityMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2006a
See Also
Topics
Diagnosing Simulation Errors
11-4
S-function upgrades needed
11-5
11 Diagnostics Parameters: Compatibility
Description
Select the diagnostic action to take when a model contains a block whose behavior depends on the
frame status of the signal.
Frame status is no longer a valid signal attribute. The blocks in the model must determine whether
they process the signal as frames of data or as samples of data. This diagnostic helps you identify
whether any of the blocks in your model rely on the frame status of a signal. If you do have such
blocks in your model, use the Upgrade Advisor. The Upgrade Advisor helps you upgrade existing
models to the current release, and improve models to use the latest features and settings in Simulink.
For more information, see “Model Upgrades”.
Category: Diagnostics
Settings
error (default) | warning | none
none
The software does not issue a diagnostic.
warning
The software issues a warning.
error
The software terminates simulation and issues an error.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: FrameProcessingCompatibilityMsg
Value: 'none' | 'warning' | 'error'
Default: 'error'
11-6
Block behavior depends on frame status of signal
Version History
Introduced in R2011b
See Also
Topics
“Sample- and Frame-Based Concepts” (DSP System Toolbox)
Diagnosing Simulation Errors
“Model Configuration Parameters: Compatibility Diagnostics” on page 11-2
11-7
11 Diagnostics Parameters: Compatibility
Description
The Operating point object from a different release parameter controls the diagnostic behavior
when the specified Initial state value is a Simulink.op.ModelOperatingObject that was
generated using a different version of Simulink software.
When you use a model operating point from a different release as the initial state for a simulation, the
software might not be able to restore the complete operating point.
Settings
error (default) | warning
error
The software terminates simulation and issues an error when the version of Simulink software
does not match the version that generated the model operating point specified as the initial state.
warning
The software issues a warning when the version of Simulink software does not match the version
that generated the model operating point specified as the initial state. The simulation proceeds,
and the software restores as much of the operating point as possible.
Tips
After you simulate a model with fast restart enabled for the first time, this diagnostic does not
interrupt execution of subsequent simulations or require recompilation.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: NonCurrentReleaseOperatingPointMsg
Value: 'error' | 'warning'
Default: 'error'
11-8
Operating point object from a different release
Version History
Introduced in R2019a
See Also
Objects
Simulink.op.ModelOperatingPoint
Model Settings
Initial state | Save final operating point | Initial state is array
Topics
“Specify Initial State for Simulation”
“Save Block States and Simulation Operating Points”
“Use Model Operating Point for Faster Simulation Workflow”
“Model Configuration Parameters: Compatibility Diagnostics” on page 11-2
11-9
12
The Diagnostics > Model Referencing pane of the Configuration Parameters dialog box includes
parameters for detecting issues related to Model blocks and referenced models.
To open the Configuration Parameters dialog box for the top model in a model hierarchy, in the
Simulink Toolstrip, on the Modeling tab, click Model Settings.
To open the Configuration Parameters dialog box for the current referenced model, on the Modeling
tab, click the Model Settings button arrow. Then, in the Referenced Model section, select Model
Settings.
See Also
Related Examples
• “Model Reference Basics”
• Diagnosing Simulation Errors
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
12-2
Model block version mismatch
Description
The Model block version mismatch configuration parameter determines the diagnostic action to
take when loading or updating this model and the version of the model used to create or refresh a
Model block does not match the current version of the referenced model.
Version mismatches can occur when you modify, save, and close a referenced model while the model
that references it is not loaded. For more information, see “Manage Model Versions and Specify
Model Properties”.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
none (default) | warning | error
none
The software refreshes the Model block.
warning
The software displays a warning and refreshes the Model block.
error
The software displays an error message and does not refresh the Model block.
When you receive an error related to a Model block version mismatch, you can manually refresh
the Model block. Select the Model block. Then, on the Model Block tab, select Refresh.
Alternatively, use the Simulink.ModelReference.refresh function.
Tips
Model block icons can display a message indicating version mismatches. To enable this feature, from
the parent model, on the Debug tab, select Information Overlays > Ref. Model Version. The
Model block displays a version mismatch, for example: Rev:1.0 != 1.2.
12-3
12 Diagnostics Parameters: Model Referencing
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: ModelReferenceVersionMismatchMessage
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
See Also
Topics
“Model Reference Basics”
Diagnosing Simulation Errors
“Model Version Numbers”
“Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
12-4
Port and parameter mismatch
Description
The Port and parameter mismatch configuration parameter determines the diagnostic action to
take when loading or updating this model when a port or parameter does not match between a Model
block and its referenced model.
Port mismatches occur when the input and output ports of a Model block do not match the root-level
input and output ports of the model it references.
Parameter mismatches occur when the parameter arguments recognized by the Model block do not
match the parameter arguments declared by the referenced model.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
none (default) | warning | error
none
The software refreshes the Model block.
warning
The software displays a warning and refreshes the Model block.
error
The software displays an error message and does not refresh the Model block.
When you receive an error related to a Model block port or parameter mismatch, you can
manually refresh the Model block. Select the Model block. Then, on the Model Block tab, select
Refresh. Alternatively, use the Simulink.ModelReference.refresh function.
12-5
12 Diagnostics Parameters: Model Referencing
Tips
Model block icons can display text that indicates a port or parameter mismatch. To enable this
feature, from the parent model, on the Debug tab, select Information Overlays > Ref Model I/O
Mismatch.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: ModelReferenceIOMismatchMessage
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
See Also
Topics
“Model Reference Basics”
Diagnosing Simulation Errors
“Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
12-6
Invalid root Inport/Outport block connection
Note The Invalid root Inport/Outport block connection diagnostic configuration parameter has
been removed. Use Model Advisor check hisl_0079 instead.
Description
The Invalid root Inport/Outport block connection configuration parameter determines the
diagnostic action to take when internal connections to the root-level port blocks of this model are
invalid.
By default, the software adds hidden blocks to satisfy the constraints wherever possible. In some
cases, such as function-call feedback loops, automatically inserted hidden blocks may introduce
delays that may change simulation results.
Auto-inserting hidden blocks to eliminate root input and output port problems stops at subsystem
boundaries. You must manually modify models with subsystems that have invalid internal
connections.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
none (default) | warning | error
none
The software silently inserts hidden blocks to satisfy the constraints wherever possible.
warning
The software warns you that a connection constraint has been violated and attempts to satisfy the
constraint by inserting hidden blocks.
error
The software terminates the simulation or code generation and displays an error message.
12-7
12 Diagnostics Parameters: Model Referencing
Note The software does not honor the none and warning settings for a referenced function-call
model. The software reports all invalid root port connections as errors.
Examples
• A root output port block connects directly or indirectly to more than one nonvirtual block port.
• An Outport block connects to some elements of a block output and not others.
12-8
Invalid root Inport/Outport block connection
• The signal that drives the root output port block is a test point.
• The driving block has a constant sample time and multiple output ports, and one of the other
output ports of the block is a test point.
• The root output port is conditionally computed and you are using function prototype control or an
encapsulated C++ target. The function prototype specification or C++ target specification states
that the output variable corresponding to that root output port is returned by value.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
12-9
12 Diagnostics Parameters: Model Referencing
Application Setting
Safety precaution error
Programmatic Use
Parameter: ModelReferenceIOMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced before R2006a
R2024a: Removed
Errors starting in R2024a
The Invalid root Inport/Outport block connection diagnostic configuration parameter has been
removed.
When internal connections to the root-level port blocks of a model are invalid, the software silently
inserts hidden blocks to satisfy the constraints wherever possible. This behavior matches the previous
default behavior.
To diagnose and fix invalid connections, use Model Advisor check mathworks.hism.hisl_0079
instead.
R2023b: To be removed
Not recommended starting in R2023b
The Invalid root Inport/Outport block connection diagnostic configuration parameter will be
removed in a future release.
See Also
Topics
“Model Reference Requirements and Limitations”
Diagnosing Simulation Errors
“Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
12-10
Unsupported data logging
Description
The Unsupported data logging configuration parameter determines the diagnostic action to take
when this model contains To Workspace or Scope blocks with data logging enabled. The default
action warns you that the software does not support use of these blocks to log data from referenced
models.
For information on how to log signals from a reference to this model, see “Override Signal Logging
Settings”.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
warning (default) | none | error
none
The software takes no action.
warning
The software displays a warning.
error
The software terminates the simulation and displays an error message.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
12-11
12 Diagnostics Parameters: Model Referencing
Application Setting
Safety precaution error
Programmatic Use
Parameter: ModelReferenceDataLoggingMessage
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced before R2006a
See Also
To Workspace | Scope
Topics
“Model Reference Basics”
Diagnosing Simulation Errors
“Override Signal Logging Settings”
“Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
12-12
No explicit final value for model arguments
Description
The No explicit final value for model arguments configuration parameter determines the
diagnostic action to take when the topmost Model block that can set the value for a model argument
uses a default value instead of providing an explicit value.
In the Model Data Editor, Property Inspector, or Model Explorer, the default value for a model
argument displays as either <inherited> or <from below>.
• If the Argument check box is selected, the software displays <inherited> to indicate that, in
the case that a model references the Model block, the model argument value is provided by the
parent.
• If the Argument check box is cleared, the software displays <from below> to indicate that its
value is provided by the last model to specify a value in the model hierarchy below.
In the MATLAB Command Window, a default value for a model argument is represented by an empty
string.
The value of this configuration parameter in the top model applies to each model argument in the
model hierarchy.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
none (default) | warning | error
Default:
none
If the topmost Model block uses the default value for a model argument, the software uses the
last value specified in the model hierarchy below.
12-13
12 Diagnostics Parameters: Model Referencing
warning
If the topmost Model block uses the default value for a model argument, the software uses the
last value specified in the model hierarchy below, but displays a warning that the model argument
does not have an explicit final value.
error
If the topmost Model block uses a default value for a model argument, the software displays an
error message at compile time.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: ModelReferenceNoExplicitFinalValueMsg
Value: 'none' | 'warning' | 'error'
Default: 'none'
Version History
Introduced in R2020b
See Also
Topics
Diagnosing Simulation Errors
“Configure Instance-Specific Values for Block Parameters in a Referenced Model”
“Parameterize a Referenced Model Programmatically”
“Model Configuration Parameters: Model Referencing Diagnostics” on page 12-2
12-14
13
The Diagnostics > Stateflow category includes parameters for detecting issues related to Stateflow
charts.
Parameter Description
Unused data, events, messages, and Select the diagnostic action to take for detection
functions of unused data, events, and messages in a chart.
Removing unused data, events, and messages can
minimize the size of your model.
Unexpected backtracking Select the diagnostic action to take when a chart
junction has both of the following conditions. The
junction:
13-2
Model Configuration Parameters: Stateflow Diagnostics
Parameter Description
Execute-at-Initialization disabled in Select the diagnostic action to take when
presence of input events Stateflow detects triggered or enabled charts
that are not running at initialization.
Unreachable execution path Select the diagnostic action to take when there
are chart constructs not on a valid execution
path.
See Also
Related Examples
• Diagnosing Simulation Errors
• Solver Diagnostics on page 6-2
• Sample Time Diagnostics on page 7-2
• Data Validity Diagnostics on page 8-2
• Type Conversion Diagnostics on page 9-2
• Connectivity Diagnostics on page 10-2
• Compatibility Diagnostics on page 11-2
• Model Referencing Diagnostics on page 12-2
13-3
13 Diagnostics Parameters: Stateflow
Description
The Unused data, events, messages, and functions parameter specifies the diagnostic action to
take when Stateflow detects unused data, events, messages, or functions in a chart. Removing
unused data, events, messages, and functions can minimize the size of your model.
This diagnostic does not detect input events or MATLAB function input and output data. Additionally,
this diagnostic does not detect unused data for Stateflow charts that include Simulink functions,
Simulink based states, or atomic subcharts.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears with a link to delete the unused data, event, or message in your chart..
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact (for simulation)
none (for production code generation)
Safety precaution warning
Programmatic Use
Parameter: SFUnusedDataAndEventsDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2010a
13-4
Unused data, events, messages, and functions
See Also
Topics
“Synchronize Model Components by Broadcasting Events” (Stateflow)
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
13-5
13 Diagnostics Parameters: Stateflow
Unexpected backtracking
Diagnostic action to take when unexpected backtracking is detected
Description
The Unexpected backtracking parameter specifies the diagnostic action to take when a chart
junction has both of the following conditions. The junction:
To avoid unwanted backtracking, consider adding an unconditional transition from the chart junction
to a terminal junction.
Settings
error (default) | none | warning
none
No warning or error appears.
warning
A warning appears with a link to examples of unwanted backtracking.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact (for simulation)
No impact (for production code generation)
Safety precaution error
Programmatic Use
Parameter: SFUnexpectedBacktrackingDiag
Value: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced in R2010a
13-6
Unexpected backtracking
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Best Practices for Creating Flow Charts” (Stateflow)
“Backtrack in Flow Charts” (Stateflow)
“Detect Modeling Errors During Edit Time” (Stateflow)
“Unexpected backtracking” (Stateflow)
13-7
13 Diagnostics Parameters: Stateflow
Description
The Invalid input data access in chart initialization parameter specifies the diagnostic action to
take when a chart:
In this chart configuration, blocks that connect to chart input ports might not initialize their outputs
during initialization. To locate this configuration in your model and correct it, use this diagnostic.
When using Embedded Coder for a component model configured with a service interface, you cannot
configure this parameter.
In charts that do not contain states, the ExecuteAtInitialization property has no effect.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact (for simulation)
No impact (for production code generation)
Safety precaution error
Programmatic Use
Parameter: SFInvalidInputDataAccessInChartInitDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
13-8
Invalid input data access in chart initialization
Version History
Introduced in R2010a
See Also
Topics
“Execution of a Chart at Initialization” (Stateflow)
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
13-9
13 Diagnostics Parameters: Stateflow
Description
The No unconditional default transitions parameter specifies the diagnostic action to take when a
chart does not have an unconditional default transition to a state.
This chart construct can cause inconsistency errors. To locate this construct in your model and
correct it, use this diagnostic. If a chart contains local event broadcasts or implicit events, detection
of a state inconsistency might not be possible until run time.
Settings
warning (default) | error | none
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability No impact
Efficiency No impact (for simulation)
none (for production code generation)
Safety precaution error
Programmatic Use
Parameter: SFNoUnconditionalDefaultTransitionDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2010a
13-10
No unconditional default transitions
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Transition Between Operating Modes” (Stateflow)
“Detect State Inconsistencies” (Stateflow)
“Detect Modeling Errors During Edit Time” (Stateflow)
“Default transition path does not terminate in a state” (Stateflow)
13-11
13 Diagnostics Parameters: Stateflow
Description
The Transition outside natural parent parameter specifies the diagnostic action to take when a
chart contains a transition that loops outside of the parent state or junction.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact (for simulation)
none (for production code generation)
Safety precaution error
Programmatic Use
Parameter: SFTransitionOutsideNaturalParentDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2010a
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Transition Between Operating Modes” (Stateflow)
“Detect Modeling Errors During Edit Time” (Stateflow)
13-12
Transition outside natural parent
13-13
13 Diagnostics Parameters: Stateflow
Description
The Undirected event broadcasts parameter specifies the diagnostic action to take when a chart
contains undirected local event broadcasts.
Undirected local event broadcasts can cause unwanted recursive behavior in a chart and inefficient
code generation. To flag these types of event broadcasts and fix them, use this diagnostic.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency warning
Safety precaution error
Programmatic Use
Parameter: SFUndirectedBroadcastEventsDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2012b
See Also
Topics
“Avoid Unwanted Recursion in a Chart” (Stateflow)
13-14
Undirected event broadcasts
13-15
13 Diagnostics Parameters: Stateflow
Description
The Transition action specified before condition action parameter specifies the diagnostic action
to take when a transition action executes before a condition action in a transition path with multiple
transition segments.
When a transition with a specified transition action precedes a transition with a specified condition
action in the same transition path, out-of-order execution can occur. To flag such behavior in your
chart and fix it, use this diagnostic.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability warning
Efficiency warning
Safety precaution error
Programmatic Use
Parameter: SFTransitionActionBeforeConditionDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2012b
13-16
Transition action specified before condition action
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Transition Between Operating Modes” (Stateflow)
“Detect Modeling Errors During Edit Time” (Stateflow)
“Transition action precedes a condition action along this path” (Stateflow)
13-17
13 Diagnostics Parameters: Stateflow
Description
The Read-before-write to output in Moore chart parameter specifies the diagnostic action to take
when a Moore chart uses a previous output value to determine the current state. This behavior
violates Moore machine semantics. In a Moore machine, output is a function of current state only. To
allow output values from the previous time step in calculating current state, set this diagnostic to
warning or none.
Settings
error (default) | none | warning
Default: error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability error
Efficiency error
Safety precaution error
Programmatic Use
Parameter: SFOutputUsedAsStateInMooreChartDiag
Value: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced in R2015a
13-18
Read-before-write to output in Moore chart
See Also
Topics
“Design Considerations for Moore Charts” (Stateflow)
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
13-19
13 Diagnostics Parameters: Stateflow
Description
The Absolute time temporal value shorter than sampling period parameter specifies the
diagnostic action to take when a state or transition absolute time operator uses a time value that is
shorter than the sample time for the Stateflow block. Stateflow cannot update states in smaller
increments than the sample time for the block. For example, a model with a sample rate of 0.1 sec
and an operator after(5,usec) triggers this diagnostic. If this parameter is set to warning or
none, then the operator is evaluated as true at every time step.
Settings
warning (default) | none | error
Default: warning
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability error
Efficiency error
Safety precaution error
Programmatic Use
Parameter: SFTemporalDelaySmallerThanSampleTimeDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2016b
13-20
Absolute time temporal value shorter than sampling period
See Also
Chart
Topics
“Control Chart Execution by Using Temporal Logic” (Stateflow)
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
13-21
13 Diagnostics Parameters: Stateflow
Description
The Self transition on leaf state parameter specifies the diagnostic action to take when you can
remove a self-transition on a leaf state. Some self-transitions with no actions in the leaf state or on
the self-transition have no effect on chart execution. Removing these transitions simplifies the state
diagram.
Settings
warning (default) | none | error
Default: warning
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability error
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SFSelfTransitionDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2016b
13-22
Self transition on leaf state
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
13-23
13 Diagnostics Parameters: Stateflow
Description
The Execute-at-Initialization disabled in presence of input events parameter specifies the
diagnostic action to take when Stateflow detects triggered or enabled charts that are not running at
initialization. When the chart does not execute at initialization, then the chart default transitions are
processed at the first input event. Until then, any data that you initialize in the chart or active state
data is not valid at time 0.
To initialize the chart configuration at time 0 rather than at the first input event, select the chart
property Execute (enter) chart at initialization. For more information, see Execute (enter) chart
at initialization.
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SFExecutionAtInitializationDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
Version History
Introduced in R2016b
13-24
Execute-at-Initialization disabled in presence of input events
See Also
Chart
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Execution of a Chart at Initialization” (Stateflow)
13-25
13 Diagnostics Parameters: Stateflow
Description
The Use of machine-parented data instead of Data Store Memory parameter specifies the
diagnostic action to take when Stateflow detects machine-parented data that you can replace with
chart-parented data of scope Data Store Memory.
Note This configuration parameter has been removed. Starting in R2023a, Stateflow charts no
longer support machine-parented data. Use the Upgrade Advisor to convert machine-parented data to
chart-parented data store memory. For more information, see “Upgrade Models Using Upgrade
Advisor” and “Check for machine-parented data”.
Settings
error (default) | none | warning
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging error
Traceability No impact
Efficiency No impact
Safety precaution error
Programmatic Use
Parameter: SFMachineParentedDataDiag
Value: 'none' | 'warning' | 'error'
Default: 'error'
13-26
Use of machine-parented data instead of Data Store Memory
Version History
Introduced in R2016b
13-27
13 Diagnostics Parameters: Stateflow
Description
The Unreachable execution path parameter specifies the diagnostic action to take when there are
chart constructs not on a valid execution path. These constructs can cause unreachable execution
paths:
• Transition shadowing caused by an unconditional transition that prevents other transitions from
the same source from executing
• States, junctions, or ports not connected with a transition from a reachable source
• Unconditional transitions leading out of a state that prevent the execution of the during actions
in the state and the transitions between child states
13-28
Unreachable execution path
This diagnostic does not detect unreachable execution paths caused by transition conditions that are
always true or false. For example, in this chart, the diagnostic does not detect that the unconditional
transition to state D is never valid.
If you have Simulink Design Verifier™, you can use dead logic detection to analyze your chart for this
type of unreachable execution path. For more information, see “Dead Logic Detection” (Simulink
Design Verifier).
Settings
warning (default) | none | error
none
No warning or error appears.
warning
A warning appears.
error
An error appears and stops the simulation.
Recommended Settings
Application Setting
Debugging warning
Traceability No impact
Efficiency No impact (for simulation)
none (for production code generation)
Safety precaution error
Programmatic Use
Parameter: SFUnreachableExecutionPathDiag
Value: 'none' | 'warning' | 'error'
Default: 'warning'
13-29
13 Diagnostics Parameters: Stateflow
Version History
Introduced in R2016b
See Also
Topics
“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2
“Detect Modeling Errors During Edit Time” (Stateflow)
“Dead Logic Detection” (Simulink Design Verifier)
13-30
14
The Hardware Implementation category includes parameters for configuring a hardware board to
run a model. Hardware implementation parameters specify different options for building models to
run on hardware boards or devices including communication connections and hardware specific
parameters. Hardware Implementation pane parameters do not control hardware or compiler
behavior. The parameters describe hardware and compiler properties for the MATLAB software.
• Specifying hardware characteristics enables simulation of the model to detect error conditions
that can arise when executing code, such as hardware overflow.
• MATLAB uses the information to generate code for the platform that runs as efficiently as
possible. MATLAB software also uses the information to give bit-true agreement for the results of
integer and fixed-point operations in simulation and generated code.
Parameter Description
“Hardware board” on page 14-5 Select the hardware board upon which to run
your model.
“Code Generation system target file” on page 14- System target file that you select on the Code
7 Generation pane.
“Device vendor” on page 14-8 Select the manufacturer of the hardware board to
use to implement the system that this model
represents.
“Device type” on page 14-10 Select the type of hardware to use to implement
the system that this model represents.
Parameter Description
“Number of bits: char” on page 14-23 Describe the character bit length for the
hardware.
“Number of bits: short” on page 14-25 Describe the data bit length for the hardware.
“Number of bits: int” on page 14-27 Describe the data integer bit length for the
hardware.
“Number of bits: long” on page 14-29 Describe the data bit lengths for the hardware.
“Number of bits: long long” on page 14-31 Describe the length in bits of the C long long
data type that the hardware supports.
“Number of bits: float” on page 14-33 Describe the bit length of floating-point data for
the hardware (read only).
“Number of bits: double” on page 14-34 Describe the bit-length of double data for the
hardware (read only).
“Number of bits: native” on page 14-35 Describe the microprocessor native word size for
the hardware.
“Number of bits: pointer” on page 14-37 Describe the bit-length of pointer data for the
hardware.
14-2
Hardware Implementation Pane
Parameter Description
“Number of bits: size_t” on page 14-39 Describe the bit-length of size_t data for the
hardware.
“Number of bits: ptrdiff_t” on page 14-41 Describe the bit-length of ptrdiff_t data for
the hardware.
“Largest atomic size: integer” on page 14-43 Specify the largest integer data type that can be
atomically loaded and stored on the hardware.
“Largest atomic size: floating-point” on page 14- Specify the largest floating-point data type that
45 can be atomically loaded and stored on the
hardware.
“Byte ordering” on page 14-47 Describe the byte ordering for the hardware
board.
“Signed integer division rounds to” on page 14- Describe how your compiler for the hardware
49 rounds the result of dividing two signed integers.
“Shift right on a signed integer as arithmetic Describe how your compiler for the hardware fills
shift” on page 14-51 the sign bit in a right shift of a signed integer.
“Support long long” on page 14-53 Specify that your C compiler supports the C long
long data type. Most C99 compilers support
long long.
Parameter Description
Test hardware is the same as production Specify whether the test hardware differs from
hardware the production hardware.
Test device vendor and type Select the manufacturer and type of the
hardware to use to test the code generated from
the model.
Number of bits: char Describe the character bit length for the
hardware that you use to test code.
Number of bits: short Describe the data bit length for the hardware
that you use to test code.
Number of bits: int Describe the data integer bit length of the
hardware that you use to test code.
Number of bits: long Describe the data bit lengths for the hardware
that you use to test code.
Number of bits: long long Describe the length in bits of the C long long
data type that the test hardware supports.
Number of bits: float Describe the bit length of floating-point data for
the hardware that you use to test code (read
only).
Number of bits: double Describe the bit-length of double data for the
hardware that you use to test code (read only).
Number of bits: native Describe the microprocessor native word size for
the hardware that you use to test code.
14-3
14 Hardware Implementation Parameters
Parameter Description
Number of bits: pointer Describe the bit-length of pointer data for the
hardware that you use to test code.
Number of bits: size_t Describe the bit-length of size_t data for the
hardware that you use to test code.
Number of bits: ptrdiff_t Describe the bit-length of ptrdiff_t data for
the hardware that you use to test code.
Largest atomic size: integer Specify the largest integer data type that can be
atomically loaded and stored on the hardware
that you use to test code.
Largest atomic size: floating-point Specify the largest floating-point data type that
can be atomically loaded and stored on the
hardware that you use to test code.
Byte ordering Describe the byte ordering for the hardware that
you use to test code.
Signed integer division rounds to Describe how your compiler for the test hardware
rounds the result of dividing two signed integers.
Shift right on a signed integer as arithmetic shift Describe how your compiler for the test hardware
fills the sign bit in a right shift of a signed integer.
Support long long Specify that your C compiler supports the C long
long data type.
“Use Simulink Coder Features” (Simulink Coder) Enable “Simulink Coder” features for models
deployed to “Simulink Supported Hardware”.
“Use Embedded Coder Features” (Embedded Enable “Embedded Coder” features for models
Coder) deployed to “Simulink Supported Hardware”.
Parameter Description
TargetPreprocMaxBitsSint Specify the maximum number of bits that the
int - 32 target C preprocessor can use for signed integer
math.
TargetPreprocMaxBitsUint Specify the maximum number of bits that the
int - 32 target C preprocessor can use for unsigned
integer math.
See Also
Related Examples
• “Simulink Supported Hardware”
14-4
Hardware board
Hardware board
Changing this parameter updates the dialog box display so that it displays parameters that are
relevant to your hardware board.
To install support for a hardware board, go to the MATLAB Home tab, and in the Environment
section, click Add-Ons > Get Hardware Support Packages.
After installing support for a hardware board, reopen the Configuration Parameters dialog box and
select the hardware board.
Settings
Default: None if the specified system target file is ert.tlc, realtime.tlc, or autosar.tlc.
Otherwise, the default is Determine by Code Generation system target file.
None
No hardware board is specified. The system target file specified for the model is ert.tlc,
realtime.tlc, or autosar.tlc.
Determine by Code Generation system target file
Specifies that the system target file setting determines the hardware board.
Get Hardware Support Packages
Opens the Add-Ons Explorer. Use the Add-Ons Explorer to install support packages. After you
install a hardware support package, the list includes relevant hardware board names.
Hardware board name
Specifies the hardware board to use to implement the system this model represents.
Tips
• When you select a hardware board, parameters for board settings appear in the dialog box display.
• After you select a hardware board, you can select a device vendor and type.
Dependencies
The Device vendor and Device type parameter values reflect available device support for the
selected hardware board.
When you select a hardware board, the selection potentially changes the Toolchain parameter
value and other configuration parameter values. For example, if you change the hardware board
selection to ARM Cortex-A9 (QEMU), the Toolchain parameter value changes to a supported
toolchain, such as Linaro Toolchain v4.8.
Command-Line Information
Parameter: HardwareBoard
Type: character array
14-5
14 Hardware Implementation Parameters
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
• “Get and Manage Add-Ons”
14-6
Code Generation system target file
System target file that you select on the Code Generation pane.
See Also
“Hardware Implementation Pane” on page 14-2
14-7
14 Hardware Implementation Parameters
Device vendor
Select the manufacturer of the hardware board to use to implement the system that this model
represents.
Settings
Default: Intel
If you have installed target support packages, the list of settings can include additional
manufacturers.
• AMD
• ARM Compatible
• Altera
• Analog Devices
• Apple
• Atmel
• Freescale
• Infineon
• Intel
• Microchip
• NXP
• Renesas
• STMicroelectronics
• Texas Instruments
• ASIC/FPGA
• Custom Processor
Tips
• The Device vendor and Device type fields share the command-line parameter
ProdHWDeviceType. When specifying this parameter at the command line, separate the device
vendor and device type values by using the characters ->. For example: 'Intel->x86-64
(Linux 64)'.
• If you have a Simulink Coder license and you want to add Device vendor and Device type values
to the default set, see “Register New Hardware Devices” (Simulink Coder).
Dependencies
The Device vendor and Device type parameter values reflect available device support for the
selected hardware board.
14-8
Device vendor
Command-Line Information
Parameter: ProdHWDeviceType
Type: string
Value: any valid value (see tips)
Default: 'Intel'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Select your Device vendor and Device type if they are
available in the drop-down list. If your Device vendor
and Device type are not available, set device-specific
values by using Custom Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-9
14 Hardware Implementation Parameters
Device type
Select the type of hardware to use to implement the system that this model represents.
Settings
Default: x86–64 (Windows64)
If you have installed target support packages, the list of settings includes additional types of
hardware.
AMD options:
• Athlon 64
• K5/K6/Athlon
• x86–32 (Windows 32)
• x86–64 (Linux 64)
• x86–64 (macOS)
• x86–64 (Windows64)
ARM options:
• ARM 10
• ARM 11
• ARM 64-bit (LLP64)
• ARM 64-bit (LP64)
• ARM 7
• ARM 8
• ARM 9
• ARM Cortex-A (32-bit)
• ARM Cortex-A (64-bit)
• ARM Cortex-M
• ARM Cortex-R
Altera options:
Apple options:
14-10
Device type
• ARM64
Atmel options:
• AVR
• AVR (32-bit)
• AVR (8-bit)
Freescale options:
• 32-bit PowerPC
• 68332
• 68HC08
• 68HC11
• ColdFire
• DSP563xx (16-bit mode)
• HC(S)12
• MPC52xx
• MPC5500
• MPC55xx
• MPC5xx
• MPC7xxx
• MPC82xx
• MPC83xx
• MPC85xx
• MPC86xx
• MPC8xx
• S08
• S12x
• StarCore
Infineon options:
• C16x, XC16x
• TriCore
Intel options:
• x86–32 (Windows32)
• x86–64 (Linux 64)
• x86–64 (macOS)
• x86–64 (Windows64)
Microchip options:
14-11
14 Hardware Implementation Parameters
• PIC18
• dsPIC
NXP options:
• Cortex—M0/M0+
• Cortex—M3
• Cortex—M4
Renesas options:
• M16C
• M32C
• R8C/Tiny
• RH850
• RL78
• RX
• RZ
• SH-2/3/4
• V850
STMicroelectronics:
• ST10/Super10
• C2000
• C5000
• C6000
• MSP430
• Stellaris Cortex—M3
• TMS470
• TMS570 Cortex—R4
ASIC/FPGA options:
• ASIC/FPGA
Tips
• Before you specify the device type, select the device vendor.
• To view parameters for a device type, click the arrow button to the left of Device details.
• Selecting a device type specifies the hardware device to define system constraints:
14-12
Device type
• Parameters with more than one possible value provide a list of valid values.
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
AMD
Athlon 64 8 16 3 64 64 64 64 64 64 Cha None Littl Zero ✓ □
2 r e
Endia
n
K5/K6/ 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
Athlon 2 r e
Endia
n
x86–32 8 16 3 32 64 32 32 32 32 Cha Floa Littl Zero ✓ □
(Windows3 2 r t e
2) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Linux 2 r t e
64) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(macOS) 2 r t e
Endia
n
x86–64 8 16 3 32 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Windows6 2 r t e
4) Endia
n
ARM Compatible
ARM 8 16 3 32 64 32 32 32 32 Lon Floa Littl Zero ✓ □
7/8/9/10 2 g t e
Endia
n
14-13
14 Hardware Implementation Parameters
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
ARM 11 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
ARM 64- 8 16 3 64 64 64 64 64 64 Lon Doub Littl Zero ✓ ✓
bit 2 g le e
(LP64) Endia
n
ARM 64- 8 16 3 32 64 64 64 64 64 Lon Doub Littl Zero ✓ ✓
bit 2 g le e
(LLP64) Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-A 2 g le e
(32-bit) Endia
n
ARM 8 16 3 64 64 32 64 64 64 Lon Doub Littl Zero ✓ ✓
Cortex-A 2 gLo le e
(64-bit) ng Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-M 2 g le e
Endia
n
ARM 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex-R 2 g le e
Endia
n
Altera
SoC (ARM 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
Cortex A) 2 r e
Endia
n
Analog Devices
14-14
Device type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
ADSP- 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
CM40x(ARM 2 g le e
Cortex-M) Endia
n
Blackfin 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
SHARC 32 32 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
2 g le Endia
n
TigerSHAR 32 32 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
C 2 g le e
Endia
n
Apple
ARM64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
2 r t e
Endia
n
Atmel
AVR 8 16 1 32 64 8 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
AVR (32- 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
bit) 2 r e
Endia
n
AVR (8- 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
bit) 6 r e
Endia
n
Freescale
14-15
14 Hardware Implementation Parameters
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
32-bit 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
PowerPC 2 g le Endia
n
68332 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
68HC08 8 16 1 32 64 8 8 16 8 Cha None Big Zero ✓ □
6 r Endia
n
68HC11 8 16 1 32 64 8 8 16 16 Cha None Big Zero ✓ □
6 r Endia
n
ColdFire 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
DSP563xx 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
(16-bit 6 r e
mode) Endia
n
DSP5685x 8 16 1 32 64 16 16 16 16 Cha Floa Littl Zero ✓ □
6 r t e
Endia
n
HC(S)12 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
14-16
Device type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
MPC52xx, 8 16 3 32 64 32 32 32 32 Lon None Big Zero ✓ □
MPC5500, 2 g Endia
MPC55xx, n
MPC5xx,
PC5xx,
MPC7xxx,
MPC82xx,
MPC83xx,
MPC86xx,
MPC8xx
MPC85xx 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
2 g le Endia
n
S08 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
S12x 8 16 1 32 64 16 16 16 16 Cha None Big Zero ✓ □
6 r Endia
n
StarCore 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
Infineon
C16x, 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
XC16x 6 r e
Endia
n
TriCore 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
Intel
14-17
14 Hardware Implementation Parameters
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
x86–32 8 16 3 32 64 32 32 32 32 Cha Floa Littl Zero ✓ □
(Windows3 2 r t e
2) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Linux 2 r t e
64) Endia
n
x86–64 8 16 3 64 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(macOS) 2 r t e
Endia
n
x86–64 8 16 3 32 64 64 64 64 64 Cha Floa Littl Zero ✓ □
(Windows6 2 r t e
4) Endia
n
Microchip
PIC18 8 16 1 32 64 8 8 24 24 Cha None Littl Zero ✓ □
6 r e
Endia
n
dsPIC 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
NXP
Cortex— 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
M0/M0+ 2 g le e
Endia
n
Cortex—M3 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
14-18
Device type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
Cortex—M4 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
Renesas
M16C 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
M32C 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
R8C/Tiny 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
RH850 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
RL78 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
RX 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
RZ 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
14-19
14 Hardware Implementation Parameters
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
SH-2/3/4 8 16 3 32 64 32 32 32 32 Cha None Big Zero ✓ □
2 r Endia
n
V850 8 16 3 32 64 32 32 32 32 Cha None Littl Zero ✓ □
2 r e
Endia
n
STMicroelectronics
ST10/ 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
Super10 6 r e
Endia
n
Texas Instruments
C2000 16 16 1 32 64 16 32 16 16 Int None Littl Zero ✓ □
6 e
Endia
n
C5000 16 16 1 32 64 16 16 16 16 Int None Big Zero ✓ □
6 Endia
n
C6000 8 16 3 40 64 32 32 32 32 Int None Littl Zero ✓ □
2 e
Endia
n
MSP430 8 16 1 32 64 16 16 16 16 Cha None Littl Zero ✓ □
6 r e
Endia
n
Stellaris 8 16 3 32 6 32 32 32 32 Lon Doub Littl Zero ✓ □
Cortex—M3 2 g le e
Endia
n
14-20
Device type
Key: float and double (not listed) always equal 32 and 64, respectively
Round to = Signed integer division rounds to
Shift right = Shift right on a signed integer as arithmetic shift
Long long = Support long long
Device Number of bits Largest Byte Round to Shift Long
vendor / atomic orderi right long
Device size ng
type ch sho in lon lon nativ poin size ptrdif inte float
ar rt t g g e ter _t f_t ger ing-
lon poin
g t
TMS470 8 16 3 32 64 32 32 32 32 Lon Doub Littl Zero ✓ □
2 g le e
Endia
n
TMS570 8 16 3 32 64 32 32 32 32 Lon Doub Big Zero ✓ □
Cortex—R4 2 g le Endia
n
ASIC/FPGA
ASIC/FPGA NA NA N NA NA NA NA NA NA NA NA NA NA NA NA
A
• The Device vendor and Device type fields share the command-line parameter
ProdHWDeviceType. When specifying this parameter at the command line, separate the device
vendor and device type values by using the characters ->. For example: 'Intel->x86-64
(Linux 64)'.
• If you have a Simulink Coder license and you want to add Device vendor and Device type values
to the default set, see “Register New Hardware Devices” (Simulink Coder).
Dependencies
The Device vendor and Device type parameter values reflect available device support for the
selected hardware board.
Menu options that are available in the menu depend on the Device vendor parameter setting.
With the exception of device vendor ASIC/FPGA, selecting a device type sets the following
parameters:
14-21
14 Hardware Implementation Parameters
Whether you can modify the setting of a device-specific parameter varies according to device type.
Command-Line Information
Parameter: ProdHWDeviceType
Type: string
Value: any valid value (see tips)
Default: 'Intel->x86–64 (Windows64)'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-22
Number of bits: char
Description
Describe the character bit length for the selected hardware.
Settings
Default: 8
Minimum: 8
Maximum: 32
Tip
All values must be a multiple of 8.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerChar
Type: integer
Value: any valid value
Default: 8
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-23
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-24
Number of bits: short
Description
Describe the data bit length for the selected hardware.
Settings
Default: 16
Minimum: 8
Maximum: 32
Tip
All values must be a multiple of 8.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerShort
Type: integer
Value: any valid value
Default: 16
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-25
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-26
Number of bits: int
Description
Describe the data integer bit length of the selected hardware.
Settings
Default: 32
Minimum: 8
Maximum: 32
Tip
All values must be a multiple of 8.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerInt
Type: integer
Value: any valid value
Default: 32
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-27
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-28
Number of bits: long
Description
Describe the data bit lengths for the selected hardware.
Settings
Default: 32
Minimum: 32
Maximum: 128
Tip
All values must be a multiple of 8 and from 32 through 128.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerLong
Type: integer
Value: any valid value
Default: 32
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-29
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-30
Number of bits: long long
Description
Describe the length in bits of the C long long data type for the selected hardware.
Settings
Default: 64
Minimum: 64
Maximum: 128
The number of bits that represent the C long long data type.
Tips
• Use the C long long data type only if your C compiler supports long long.
• You can change the value of this parameter for custom targets only. For custom targets, all values
must be a multiple of 8 and be between 64 and 128.
Dependencies
• Enable long long enables use of this parameter.
• The value of this parameter must be greater than or equal to the value of Number of bits: long.
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerLongLong
Type: integer
Value: any valid value
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-31
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-32
Number of bits: float
Description
Describe the bit length of floating-point data for the selected hardware (read only).
Settings
Default: 32
Command-Line Information
Parameter: ProdBitPerFloat
Type: integer
Value: 32 (read-only)
Default: 32
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-33
14 Hardware Implementation Parameters
Description
Describe the bit-length of double data for the selected hardware (read only).
Settings
Default: 64
Command-Line Information
Parameter: ProdBitPerDouble
Type: integer
Value: 64 (read only)
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-34
Number of bits: native
Description
Describe the microprocessor native word size for the selected hardware.
Settings
Default: 64
Minimum: 8
Maximum: 64
Tip
All values must be a multiple of 8.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdWordSize
Type: integer
Value: any valid value
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
14-35
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-36
Number of bits: pointer
Description
Describe the bit-length of pointer data for the selected hardware.
Settings
Default: 64
Minimum: 8
Maximum: 64
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerPointer
Type: integer
Value: any valid value
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
14-37
14 Hardware Implementation Parameters
14-38
Number of bits: size_t
Description
Describe the bit-length of size_t data for the selected hardware.
Settings
Default: 64
Value must be 8, 16, 24, 32, 40, 64, or 128 and greater than or equal to the value of int.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerSizeT
Type: integer
Value: any valid value
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
14-39
14 Hardware Implementation Parameters
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
• “Verification of Code Generation Assumptions” (Embedded Coder)
14-40
Number of bits: ptrdiff_t
Description
Describe the bit-length of ptrdiff_t data for the selected hardware.
Settings
Default: 64
Value must be 8, 16, 24, 32, 40, 64, or 128 and greater than or equal to the value of int.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdBitPerPtrDiffT
Type: integer
Value: any valid value
Default: 64
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
14-41
14 Hardware Implementation Parameters
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
• “Verification of Code Generation Assumptions” (Embedded Coder)
14-42
Largest atomic size: integer
Description
Specify the largest integer data type that can be atomically loaded and stored on the selected
hardware.
Settings
Default: Char
Char
Specifies that char is the largest integer data type that can be atomically loaded and stored on
the hardware.
Short
Specifies that short is the largest integer data type that can be atomically loaded and stored on
the hardware.
Int
Specifies that int is the largest integer data type that can be atomically loaded and stored on the
hardware.
Long
Specifies that long is the largest integer data type that can be atomically loaded and stored on
the hardware.
LongLong
Specifies that long long is the largest integer data type that can be atomically loaded and
stored on the hardware.
Tip
Use this parameter, where possible, to remove unnecessary double-buffering or unnecessary
semaphore protection, based on data size, in generated multirate code.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
• You can set this parameter to LongLong only if the hardware supports the C long long data
type and you have selected Enable long long.
Command-Line Information
Parameter: ProdLargestAtomicInteger
Type: string
14-43
14 Hardware Implementation Parameters
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency Target specific
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-44
Largest atomic size: floating-point
Description
Specify the largest floating-point data type that can be atomically loaded and stored on the selected
hardware.
Settings
Default: Float
Float
Specifies that float is the largest floating-point data type that can be atomically loaded and
stored on the hardware.
Double
Specifies that double is the largest floating-point data type that can be atomically loaded and
stored on the hardware.
None
Specifies that there is no applicable setting or not to use this parameter in generating multirate
code.
Tip
Use this parameter, where possible, to remove unnecessary double-buffering or unnecessary
semaphore protection, based on data size, in generated multirate code.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdLargestAtomicFloat
Type: string
Value: 'Float' | 'Double' | 'None'
Default: 'Float'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
14-45
14 Hardware Implementation Parameters
Application Setting
Efficiency Target specific
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
• “Verification of Code Generation Assumptions” (Embedded Coder)
14-46
Byte ordering
Byte ordering
Description
Describe the byte ordering for the selected hardware.
Settings
Default: Little Endian
Unspecified
Specifies that the code determines the endianness of the hardware. This choice is the least
efficient.
Big Endian
The most significant byte appears first in the byte ordering.
Little Endian
The least significant byte appears first in the byte ordering.
Dependencies
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdEndianess
Type: string
Value: 'Unspecified' | 'LittleEndian' | 'BigEndian'
Default: 'Little Endian'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
14-47
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-48
Signed integer division rounds to
Description
Describe how your compiler for the hardware rounds the result of dividing two signed integers.
Settings
Default: Zero
Undefined
Choose this option if neither Zero nor Floor describes the compiler behavior, or if that behavior
is unknown.
Zero
If the quotient is between two integers, the compiler chooses the integer that is closer to zero as
the result.
Floor
If the quotient is between two integers, the compiler chooses the integer that is closer to negative
infinity.
Tips
• To simulate rounding behavior of the C compiler that you use to compile generated code, use the
Integer rounding mode parameter for blocks. This setting appears on the Signal Attributes
pane of the parameter dialog boxes of blocks that can perform signed integer arithmetic, such as
the Product block.
• For most blocks, the value of Integer rounding mode completely defines rounding behavior. For
blocks that support fixed-point data and the Simplest rounding mode, the value of Signed
integer division rounds to also affects rounding. For details, see “Rounding Modes” (Fixed-Point
Designer).
• For more information on how this parameter affects code generation, see Hardware
Implementation Options (Simulink Coder).
• This table lists the compiler behavior described by the options for this parameter.
14-49
14 Hardware Implementation Parameters
Dependency
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdIntDivRoundTo
Type: string
Value: 'Floor' | 'Zero' | 'Undefined'
Default: 'Zero'
Recommended settings
Application Setting
Debugging No impact for simulation or during development.
Undefined for production code generation.
Traceability No impact for simulation or during development.
Zero or Floor for production code generation.
Efficiency No impact for simulation or during development.
Zero for production code generation.
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-50
Shift right on a signed integer as arithmetic shift
Description
Describe how your compiler for the hardware fills the sign bit in a right shift of a signed integer.
Settings
Default: On
On
Generates simple, efficient code whenever the Simulink model performs arithmetic shifts on
signed integers.
Off
Generates fully portable but less efficient code to implement right arithmetic shifts.
Tips
• Select this parameter if the C compiler implements a signed integer right shift as an arithmetic
right shift.
• An arithmetic right shift fills bits vacated by the right shift with the value of the most significant
bit. The most significant bit indicates the sign of the number in twos complement notation.
Dependency
• Selecting a device by using the Device vendor and Device type parameters sets a device-specific
value for this parameter.
• This parameter is enabled only if you can modify it for the selected hardware.
Command-Line Information
Parameter: ProdShiftRightIntArith
Type: string
Value: 'on' | 'off'
Default: 'on'
Recommended settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On
14-51
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
14-52
Support long long
Description
Specify that your C compiler supports the C long long data type. Most C99 compilers support long
long.
Settings
Default: Off
On
Enables use of C long long data type for simulation and code generation on the hardware.
Off
Disables use of C long long data type for simulation or code generation on the hardware.
Tips
• This parameter is enabled only if the selected hardware supports the C long long data type.
• If your compiler does not support C long long, do not select this parameter.
Dependencies
This parameter enables Number of bits: long long.
Command-Line Information
Parameter: ProdLongLongMode
Type: string
Value: 'on' | 'off'
Default: 'off'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency On (execution, ROM)
14-53
14 Hardware Implementation Parameters
Application Setting
Safety precaution No recommendation for simulation without code
generation.
For simulation with code generation, select your Device
vendor and Device type if they are available in the drop-
down list. If your Device vendor and Device type are
not available, set device-specific values by using Custom
Processor.
See Also
• “Hardware Implementation Pane” on page 14-2
• Hardware Implementation Options (Simulink Coder)
• Specifying Production Hardware Characteristics (Simulink Coder)
• “Number of bits: long long” on page 14-31
14-54
15
The Model Referencing pane of the Configuration Parameters dialog box allows you to specify
options for:
The option descriptions use the term this model to refer to the model that you are configuring and the
term referenced model to designate models referenced by this model.
To open the Configuration Parameters dialog box for the top model in a model hierarchy, in the
Simulink Toolstrip, on the Modeling tab, click Model Settings.
To open the Configuration Parameters dialog box for the current referenced model, on the Modeling
tab, click the Model Settings button arrow. Then, in the Referenced Model section, select Model
Settings.
15-2
Model Configuration Parameters: Model Referencing
See Also
Model
Related Examples
• “Model Reference Basics”
• Model Dependencies
15-3
15 Model Referencing Parameters
Rebuild
Option to conditionally, always, or never rebuild model reference targets
Description
The Rebuild configuration parameter determines when to rebuild simulation and Simulink Coder
targets for referenced models before updating, simulating, or generating code from the model.
Models in a model hierarchy can have different rebuild settings. When you update, simulate, or
generate code for a model, the rebuild setting for that model applies to all its referenced models.
Models that execute in normal mode do not generate simulation targets and are unaffected by the
Rebuild settings.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
If changes detected (default) | Always | If changes in known dependencies detected |
Never
Always
Always rebuild targets for referenced models. This setting requires the most processing time
because it can trigger unnecessary builds. To make all model reference targets up to date, use
this setting before you deploy a model.
If changes detected
Conditionally rebuild targets for referenced models when the software detects a change that
could affect simulation results. To perform extensive change detection on dependencies of
referenced models, use this setting.
If the software finds no changes in known dependencies, it computes the structural checksum of
the model. The structural checksum detects changes that occur in user-created dependencies
that are not specified using the Model dependencies configuration parameter. If the structural
checksum has changed, the software rebuilds the model reference target.
15-4
Rebuild
If the software finds no changes in known or potential dependencies, it does not compute the
structural checksum of the model and does not rebuild the model reference target. To avoid
invalid simulation results, you must list all user-created dependencies in the Model
dependencies parameter.
Never
Do not rebuild targets for referenced models. This setting requires the least processing time and,
when available, uses Simulink cache files for faster simulations. To avoid rebuilds when
developing a model, use this setting.
If model reference targets are out of date, the simulation may present invalid results. To have the
software check for changes in known target dependencies and report if the model reference
targets may be out of date, use the Never rebuild diagnostic parameter. To manually rebuild
model reference targets, use the slbuild function.
For information on using and sharing Simulink cache files, see “Share Simulink Cache Files for
Faster Simulation”.
Examples
You can conditionally rebuild model reference targets by setting Rebuild to If changes detected
or If changes in known dependencies detected.
Suppose you change a MATLAB script that executes as part of a callback script. The Model
dependencies configuration parameter does not list the MATLAB script as a model dependency.
The Rebuild setting determines whether to rebuild the affected model reference targets.
• If changes detected causes a rebuild because the change affects the structural checksum of
the model.
• If changes in known dependencies detected does not cause a rebuild because no known
target dependency has changed.
This flow chart describes the processing Simulink performs when you set Rebuild to either If
changes detected or If changes in known dependencies detected.
15-5
15 Model Referencing Parameters
Tips
To improve rebuild detection speed and accuracy, use the Model dependencies configuration
parameter to specify user-created dependencies.
15-6
Rebuild
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution If changes detected or Never
When you use the Never setting, set the Never rebuild
diagnostic configuration parameter to Error if
rebuild required.
Programmatic Use
Parameter: UpdateModelReferenceTargets
Value2: 'Force' | 'IfOutOfDateOrStructuralChange' | 'IfOutOfDate' | 'AssumeUpToDate'
Default: 'IfOutOfDateOrStructuralChange'
Limitations
The Rebuild configuration parameter does not apply to a Model block when both of these conditions
apply:
In this case, the code regeneration behavior for the referenced model is what you observe for a
standalone model. For more information, see “Control Regeneration of Top Model Code” (Embedded
Coder).
More About
Known Target Dependencies
Known target dependencies are files and data external to model files that Simulink examines for
changes when checking if a model reference target is up to date. Simulink automatically computes a
set of known target dependencies. Examples of known target dependencies are:
• Changes to the model workspace, if its data source is a MAT file or MATLAB (.m) file.
• Enumerated type definitions.
2 This table maps the programmatic values to the equivalent interactive values of the Rebuild configuration
parameter.
15-7
15 Model Referencing Parameters
Potential target dependencies are files and data external to model files and model configuration
settings that Simulink examines for changes when checking if a model reference target is up to date.
Simulink automatically computes a set of potential target dependencies. Examples of potential target
dependencies are:
Simulink examines each potential target dependency to determine whether its state triggers a
structural checksum check.
User-Created Dependencies
User-created dependencies are files that Simulink does not automatically identify, regardless of their
potential impact on simulation results. Examples of user-created dependencies are:
You can add user-created dependencies to the set of known target dependencies by using the Model
dependencies parameter.
Structural Checksum
A structural checksum is a computation used to detect changes in the model that can affect
simulation results. When Simulink computes the structural checksum, it loads and compiles the
model. To compile the model, Simulink must execute callbacks and access all variables that the model
uses. The structural checksum detects changes in user-created dependencies, regardless of whether
you have specified those user-created dependencies in the Model dependencies configuration
parameter.
For more information about the kinds of changes that affect the structural checksum, see
Simulink.BlockDiagram.getChecksum.
Version History
Introduced before R2006a
15-8
Rebuild
Starting in R2019b, If changes detected ignores cosmetic changes such as repositioning a block.
See Also
Blocks
Model
Model Settings
Never rebuild diagnostic | Model dependencies
Functions
Simulink.BlockDiagram.getChecksum
Topics
“Manage Simulation Targets for Referenced Models”
“Share Simulink Cache Files for Faster Simulation”
“Model Configuration Parameters: Model Referencing” on page 15-2
15-9
15 Model Referencing Parameters
Description
The Never rebuild diagnostic configuration parameter determines the diagnostic action to take
when a model reference target must be rebuilt.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Rebuild to Never.
Settings
Error if rebuild required (default) | Warn if rebuild required | None
None
The software takes no action.
Selecting None bypasses dependency checking, which enables faster updating, simulation, and
code generation. The None setting can cause models that are not up to date to malfunction or
generate incorrect results. For more information on the dependency checking, see Rebuild.
Warn if rebuild required
The software displays a warning.
Error if rebuild required
The software terminates the simulation and displays an error message.
Tips
When you set the Rebuild parameter to Never and set the Never rebuild diagnostic parameter to
Error if rebuild required or Warn if rebuild required, then Simulink software:
15-10
Never rebuild diagnostic
• Performs the same change detection processing as for the Rebuild setting If changes in
known dependencies detected, except it does not compare structural checksums
• Issues an error or warning, depending on the Never rebuild diagnostic setting, if it detects a
change
• Never rebuilds the model reference target
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution Error if rebuild required
Programmatic Use
Parameter: CheckModelReferenceTargetMessage
Value: 'none' | 'warning' | 'error'
Default: 'error'
Version History
Introduced before R2006a
See Also
Blocks
Model
Model Settings
Rebuild
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Model Referencing” on page 15-2
15-11
15 Model Referencing Parameters
Description
The Enable parallel model reference builds configuration parameter determines whether to build
a model reference hierarchy in parallel whenever possible. Parallel builds require Parallel Computing
Toolbox™.
To enable parallel builds for a model reference hierarchy, select Enable parallel model reference
builds for the top model of the hierarchy.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set the Never rebuild diagnostic configuration parameter to a value other
than None or set the Rebuild configuration parameter to a value other than Never.
Settings
off (default) | on
on
The software builds the model reference hierarchy in parallel whenever possible, based on
computing resources and the structure of the model reference hierarchy.
To specify how to initialize MATLAB workers for parallel builds, see MATLAB worker
initialization for builds.
off
The software never builds the model reference hierarchy in parallel.
15-12
Enable parallel model reference builds
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: EnableParallelModelReferenceBuilds
Value: 'on' | 'off'
Default: 'off'
Version History
Introduced in R2010a
See Also
Model
Topics
“Reduce Update Time for Referenced Models by Using Parallel Builds”
“Reduce Build Time for Referenced Models by Using Parallel Builds” (Simulink Coder)
“Model Configuration Parameters: Model Referencing” on page 15-2
15-13
15 Model Referencing Parameters
Description
The MATLAB worker initialization for builds configuration parameter determines how to initialize
MATLAB workers for parallel builds. Parallel building requires Parallel Computing Toolbox.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, select Enable parallel model reference builds.
Settings
None (default) | Copy base workspace | Load top model
None
The software takes no action. Specify this value if the referenced models in the model reference
hierarchy do not rely on anything in the base workspace beyond what they explicitly set up, for
example, with a model load function.
Copy base workspace
The software attempts to copy the base workspace to each MATLAB worker. Specify this value if
you use a setup script to prepare the base workspace for all models to use.
Load top model
The software loads the top model on each MATLAB worker. Specify this value if the top model in
the model reference hierarchy handles all of the base workspace setup, for example, with a model
load function.
15-14
MATLAB worker initialization for builds
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ParallelModelReferenceMATLABWorkerInit
Value: 'None' | 'Copy Base Workspace' | 'Load Top Model'
Default: 'None'
Limitation
For values other than None, limitations apply to global variables in the base workspace. Global
variables are not propagated across parallel workers and do not reflect changes made by top and
referenced model scripts.
Version History
Introduced in R2010a
See Also
Model
Topics
“Reduce Update Time for Referenced Models by Using Parallel Builds”
“Reduce Build Time for Referenced Models by Using Parallel Builds” (Simulink Coder)
“Model Configuration Parameters: Model Referencing” on page 15-2
15-15
15 Model Referencing Parameters
Description
The Enable strict scheduling checks for referenced models parameter enables these checks for
referenced models:
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
off (default) | on
on
The software enforces strict checks on scheduling order and sample time consistency in
referenced models.
off
The software does not enforce strict checks on scheduling order and sample time consistency in
referenced models.
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
15-16
Enable strict scheduling checks for referenced models
Application Setting
Efficiency No recommendation
Safety precaution No recommendation
Programmatic Use
Parameter: EnableRefExpFcnMdlSchedulingChecks
Value: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2015b
By default, the software no longer enforces strict checks on scheduling order and sample time
consistency in referenced models.
See Also
Model
Topics
“Export-Function Models Overview”
“Sorting Rules for Explicitly Scheduled Model Components”
“Model Configuration Parameters: Model Referencing” on page 15-2
15-17
15 Model Referencing Parameters
Description
The Total number of instances allowed per top model configuration parameter determines how
many references to this model can occur in another model.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
Multiple (default) | One | Zero
Zero
A model cannot reference this model. An error occurs if another model references this model.
One
A model hierarchy can reference this model at most once. An error occurs if more than one
reference exists in a model hierarchy.
Multiple
A model hierarchy can reference this model more than once, if it contains no constructs that
preclude multiple references. An error occurs if this model cannot be referenced multiple times,
even if only one reference exists. For model reuse requirements, see “Model Reuse”.
To use multiple instances of a referenced model in normal mode, use the Multiple setting. For
details, see “Simulate Multiple Referenced Model Instances in Normal Mode”.
Tips
Setting Total number of instances allowed per top model to Multiple for a model that is
referenced only once can reduce execution efficiency slightly. However, this setting does not affect
data values that result from simulation or from executing Simulink Coder generated code. Specifying
Multiple when only one model instance exists avoids having to change or rebuild the model when
reusing the model:
15-18
Total number of instances allowed per top model
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: ModelReferenceNumInstancesAllowed
Value: 'Zero' | 'Single' | 'Multi'
Default: 'Multi'
Version History
Introduced before R2006a
See Also
Model
Topics
Diagnosing Simulation Errors
“Model Configuration Parameters: Model Referencing” on page 15-2
15-19
15 Model Referencing Parameters
Description
The Propagate sizes of variable-size signals configuration parameter determines how variable-
size signals propagate through referenced models.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Total number of instances allowed per top model to One or
Multiple.
Settings
Infer from blocks in model (default) | Only when enabling | During execution
15-20
Propagate sizes of variable-size signals
The search stops at the boundary of enable, function-call, and action subsystems because these
subsystems can specify when to propagate the size of a variable-size signal.
This table describes how the software sets the propagation of variable-size signals for a
referenced model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: PropagateVarSize
Value: 'Infer from blocks in model' | 'Only when enabling' | 'During execution'
Default: 'Infer from blocks in model'
15-21
15 Model Referencing Parameters
Version History
Introduced in R2010a
See Also
Model
Topics
“Model Configuration Parameters: Model Referencing” on page 15-2
15-22
Minimize algebraic loop occurrences
Description
The Minimize algebraic loop occurrences configuration parameter tries to eliminate artificial
algebraic loops from a model that involve the current referenced model.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Total number of instances allowed per top model to One or
Multiple.
Settings
off (default) | on
on
The software tries to eliminate artificial algebraic loops from a model that involve the current
referenced model.
off
The software does not try to eliminate artificial algebraic loops from a model that involve the
current referenced model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
15-23
15 Model Referencing Parameters
Application Setting
Safety precaution No recommendation
Programmatic Use
Parameter: ModelReferenceMinAlgLoopOccurrences
Value: 'on' | 'off'
Default: 'off'
Limitations
Enabling this parameter together with the Simulink Coder Single output/update function
parameter results in an error.
Version History
Introduced before R2006a
See Also
Model
Topics
“Algebraic Loop Concepts”
“Model Blocks and Direct Feedthrough”
Diagnosing Simulation Errors
“Model Configuration Parameters: Model Referencing” on page 15-2
15-24
Propagate all signal labels out of the model
Description
The Propagate all signal labels out of the model configuration parameter determines whether to
pass propagated signal names to output signals of a Model block.
By default, each instance of a referenced model propagates signal labels. Clear the configuration
parameter for each referenced model that you do not want to propagate signal labels.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Total number of instances allowed per top model to One or
Multiple.
Settings
on (default) | off
on
The software propagates signal names to output signals of a Model block.
off
The software does not propagate signal names to output signals of a Model block.
Examples
These models illustrate the behavior when you use the default setting of the Propagate all signal
labels out of the model parameter of enabled for the referenced model.
15-25
15 Model Referencing Parameters
In the referenced model, a signal labeled chirp_sig connects to an Outport block named Out2.
In the parent model, the output signal from the Out2 port of the Model block displays the propagated
signal name chirp_sig.
These models illustrate the behavior when you enable signal label propagation for every eligible
signal and clear the Propagate all signal labels out of the model configuration parameter.
15-26
Propagate all signal labels out of the model
In the parent model, the output signal from the Out2 port of the Model block displays empty brackets
for the propagated signal label.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: PropagateSignalLabelsOutOfModel
Value: 'on' | 'off'
Default: 'on'
15-27
15 Model Referencing Parameters
Version History
Introduced in R2012a
See Also
Model
Topics
“Signal Label Propagation”
“Model Configuration Parameters: Model Referencing” on page 15-2
15-28
Use local solver when referencing model
Description
The Use local solver when referencing model configuration parameter specifies how the software
solves the system implemented by a referenced model. When you select this parameter, the software
solves the referenced model as a separate set of differential equations using the solver that the
current referenced model specifies for the Solver configuration parameter.
While the top solver can be a fixed-step or variable-step solver, the local solver must be a fixed-step
solver. Specify the fixed step size for the local solver using the Fixed-step size (fundamental
sample time) configuration parameter of the referenced model.
Using a local solver can facilitate system composition and integration. When you use local solvers,
you can solve referenced models in system-level simulations using the same solver and step size used
to design and test each model in isolation. Using local solvers can also reduce the amount of
configuration adjustments you need to make to configuration parameters in referenced models while
integrating the model into a larger system.
For some systems, using a local solver can improve simulation performance by allowing you to choose
a solver that is more appropriate to solve the system in the referenced model or by reducing the
number of redundant calculations in systems that have a wide range of dynamics among components.
For more information about local solvers, see “Use Local Solvers in Referenced Models”.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
off (default) | on
15-29
15 Model Referencing Parameters
on
The software uses a local solver to solve the referenced model as a separate set of differential
equations. Specify the local solver using the Solver configuration parameter of the referenced
model.
off
The software solves the referenced model as part of the parent system using the parent solver.
Examples
Open the model SecondOrderSystemTop. The model contains a Ramp block that provides the input
signal for a Model block that references a model of a second-order system. The Model block output
signal connects to an Outport block.
topmdl = "SecondOrderSystemTop";
open_system(topmdl)
To navigate inside the referenced model, double-click the Model block. Alternatively, create a
Simulink.BlockPath object for the Model block and use the open function to open the referenced
model in the context of the model hierarchy.
mdlblkpath = Simulink.BlockPath(topmdl + "/Model");
open(mdlblkpath)
The referenced model implements the second-order system using a Transfer Fcn block and contains a
Step block that models a change or disturbance to the system.
The system transfer function is specified in the Transfer Fcn block using two model workspace
variables, wn and z, which represent the natural frequency of the system, in radians per second, and
the system damping coefficient.
Configure the system with a natural frequency of 100 radians per second by specifying the value of
the variable wn as 100 in the model workspace.
refmdl = "SecondOrderSystem";
mdlwksp = get_param(refmdl,"ModelWorkspace");
assignin(mdlwksp,"wn",100)
15-30
Use local solver when referencing model
Configure the referenced model to use a local solver with a step size of 0.01 seconds. You can
configure the settings for the referenced model from the top model using the Property Inspector or
the Block Parameters dialog box.
1 Open the Property Inspector. On the Modeling tab, expand the Design section and select
Property Inspector, or press Ctrl+Shift+I.
2 To open the Configuration Parameters dialog box for the referenced model, select the Model
block. Then, in the Property Inspector, expand the Solver section and click the hyperlink next to
the Use local solver parameter.
3 Configure the model to use a local solver when referenced in a model hierarchy. In the
Configuration Parameters dialog box, on the Model Referencing pane, select Use local solver
when referencing model.
4 Select the fixed-step ode3 as the local solver. On the Solver pane, from the Type list, select
Fixed-step. Then, from the Solver list, select ode3 (Bogacki-Shampine).
5 Set the local solver step size to 0.01 seconds. On the Solver pane, expand Solver details. Then,
in the Fixed-step size (fundamental sample time) box, enter 0.01.
6 Click OK.
In the top model, the Model block indicates the local solver you specify.
Specify the communication step size for the model reference. The communication step size specifies
when the parent and local solvers exchange data and is registered as a discrete sample time in the
top model.
The Ramp block in the top model has a slope of 0.2, and the top solver uses a step size of 0.2 seconds.
Because the input signal from the top model changes slowly compared to the dynamics of the second-
order system, the communication step size can be much larger than the local solver step size without
significant effect on the accuracy of the simulation results.
Specify the communication step size as 0.4 seconds. Select the Model block. Then, in the Property
Inspector, under Solver, in the Communication step size box, enter 0.4.
Simulate the model, using the local solver to compute the response of the second-order system.
out = sim(topmdl);
To view the simulation results, open the Simulation Data Inspector. On the Simulation tab, under
Review Results, click Data Inspector. Alternatively, call the Simulink.sdi.view function.
Simulink.sdi.view
15-31
15 Model Referencing Parameters
Plot the signals named System Response and System Response - Top on separate subplots.
Alternatively, use the Simulink.sdi.loadView function to load the view named
FastSecondOrderSystem, which was created for this example.
Simulink.sdi.loadView("FastSecondOrderSystem.mldatx");
The System Response and System Response - Top signals are the same signal, logged in
different locations. The System Response signal is logged inside the referenced model at a rate
determined by the local solver step size. The System Response - Top signal is logged by the
Outport block in the top model at a rate determined by the top solver step size. Because the local
solver step size is much smaller than the top solver step size, the System Response signal captures
the system response to the change in the input signal when the Step block output value changes with
higher fidelity.
15-32
Use local solver when referencing model
In the System Response signal, you can see the effect of the local solver interpolating the input
signal with a zero-order hold between each communication step. If you zoom on the time axis around
5 seconds, you can see the oscillations in the system response to the step.
Open the model SecondOrderSystemTop. The model contains a Ramp block that provides the input
signal for a Model block that references a model of a second-order system. The Model block output
signal connects to an Outport block.
topmdl = "SecondOrderSystemTop";
open_system(topmdl)
To navigate inside the referenced model, double-click the Model block. Alternatively, create a
Simulink.BlockPath object for the Model block and use the open function to open the referenced
model in the context of the model hierarchy.
15-33
15 Model Referencing Parameters
The referenced model implements the second-order system using a Transfer Fcn block and contains a
Step block that models a change or disturbance to the system.
The system transfer function is specified in the Transfer Fcn block using two model workspace
variables, wn and z, which represent the natural frequency of the system, in radians per second, and
the system damping coefficient.
Configure the system with a natural frequency of 1 radian per second by specifying the value of the
variable wn as 1 in the model workspace.
refmdl = "SecondOrderSystem";
mdlwksp = get_param(refmdl,"ModelWorkspace");
assignin(mdlwksp,"wn",1)
Configure the referenced model to use a local solver with a step size of 0.4 seconds. You can
configure the settings for the referenced model from the top model using the Property Inspector or
the Block Parameters dialog box.
1 Open the Property Inspector. On the Modeling tab, expand the Design section and select
Property Inspector, or press Ctrl+Shift+I.
2 To open the Configuration Parameters dialog box for the referenced model, select the Model
block. Then, in the Property Inspector, expand the Solver section and click the hyperlink next to
the Use local solver parameter.
3 Configure the model to use a local solver when referenced in a model hierarchy. In the
Configuration Parameters dialog box, on the Model Referencing pane, select Use local solver
when referencing model.
4 Select the fixed-step ode3 as the local solver. On the Solver pane, from the Type list, select
Fixed-step. Then, from the Solver list, select ode3 (Bogacki-Shampine).
5 Set the local solver step size to 0.4 seconds. On the Solver pane, expand Solver details. Then, in
the Fixed-step size (fundamental sample time) box, enter 0.4.
6 Click OK.
set_param(refmdl,UseModelRefSolver="on",...
SolverType="Fixed-Step",Solver="ode3",FixedStep="0.4")
In the top model, the Model block indicates the local solver you specify.
15-34
Use local solver when referencing model
When the local solver step size is larger than the parent solver step size, inherit the communication
step size by specifying the Communication step size parameter as -1. The communication step size
specifies when the parent solver and local solver exchange data and is registered as a discrete
sample time in the parent model.
set_param(topmdl + "/Model",CommunicationStepSize="-1")
Simulate the model, using the local solver to compute the response of the second-order system.
out = sim(topmdl,StopTime="20");
To view the simulation results, open the Simulation Data Inspector. On the Simulation tab, under
Review Results, click Data Inspector. Alternatively, call the Simulink.sdi.view function.
Simulink.sdi.view
Plot the signals named System Response and System Response - Top on separate subplots.
Alternatively, use the Simulink.sdi.loadView function to load the view named
SlowSecondOrderSystem, which was created for this example.
Simulink.sdi.loadView("SlowSecondOrderSystem.mldatx");
15-35
15 Model Referencing Parameters
The System Response and System Response - Top signals are the same signal, logged in
different locations. The System Response signal is logged inside the referenced model at a rate
determined by the local solver step size. The System Response - Top signal is logged by the
Outport block in the top model at a rate determined by the top solver step size. Fewer data points are
logged for the System Response signal because the local solver step size is larger than the parent
solver step size.
Tips
• You can use Model block parameters to specify:
• The communication step size, which specifies the rate at which the local and parent solvers
exchange data
15-36
Use local solver when referencing model
• How the local solver extrapolates inputs from the parent solver
• How the local solver interpolates state or output values to provide output signal values to the
parent solver
• When the top solver is a fixed-step solver, the step size for the local solver must be an integer
multiple of the parent solver step size.
Recommended Settings
Application Setting
Debugging off
Traceability No impact
Efficiency No recommendation
Safety precaution No impact
Programmatic Use
Parameter: UseModelRefSolver
Value: "on" | "off"
Default: "off"
Version History
Introduced in R2022a
R2024b: Improved sample time propagation for output ports of model references that use
local solvers
Behavior changed in R2024b
Model blocks that reference models configured to use local solvers now propagate a discrete sample
time to the block output ports if the local solver uses zero-order hold output signal handling. The
Communication step size parameter of the Model block defines the discrete sample time
propagated to the block output ports. In previous releases, the Model block propagated the sample
time of the port in the referenced model to the block output ports.
• Simplifies the interactions between the parent solver and local solver
• More clearly reflects the effect of the zero-order hold output signal handling in the context of the
parent model
• Reduces the number of parent solver resets
In some cases, the change to sample time propagation causes warnings about sample time
discrepancies or collisions. For example, when a Model block output port that now has a discrete
sample time drives the input port of another model reference, the software issues a warning if the
sample time of the input port in the referenced model does not match the sample time of the input
signal in the top model. For more information, see “Improve Simulation Performance Using
Performance Advisor”.
15-37
15 Model Referencing Parameters
In most cases, this change does not affect numerical results and only results in fewer or different
points in logged data for the Model block output signals. The table summarizes the impact of this
change for different local solver configurations.
Local Solver Step Size Output signal handling Effect of Sample Time
Parameter Value Propagation Change
Local solver step size less than Zero-order hold Model block output ports have a
communication step size Auto discrete sample time defined by
the Communication step size
Only zero-order hold output parameter of the block.
signal handling is supported.
The change in sample time does
not affect the numerical results
of the simulation but can result
in different or fewer data points
in logged data for Model block
output signals in the top model.
Local solver step size equal to Auto No change to sample time
communication step size Use solver interpolant propagation.
You can use local solvers for system components with faster dynamics by specifying a local step size
that is smaller than the parent solver step size. The new Communication step size parameter
specifies the discrete rate for communication between the parent and local solver. The
communication step size is registered as a discrete rate in the parent model instead of the local
solver step size.
15-38
Use local solver when referencing model
R2024a: New default Output signal handling parameter value and improved behavior when
Input signal handling parameter value is Auto
Behavior changed in R2024a
The default value of the Output signal handling parameter is the new value Auto. When the
Output signal handling parameter value is Auto, the software determines the method to use to
interpolate continuous state or input signal values to the parent solver simulation time based on how
the local step size compares to the communication step size. In previous releases, the local step size
had to be greater than or equal to the parent solver step size, and the Auto option did not exist.
When the Input signal handling parameter value is Auto, the software now determines how to
extrapolate continuous derivative or input signal values to the local simulation time based on the
model structure and how the local step size compares to the communication step size. In previous
releases, the software did not consider the model structure when selecting the interpolation method.
Considering how the local step size compares to the communication step size was also not relevant
because the Communication step size parameter did not exist.
R2024a: Use local solver for model that contains blocks with wrapped states
You can configure a model that contains one or more blocks with wrapped states to use a local solver
when referenced in a model hierarchy. Wrapping states can improve numerical stability for systems
with cyclical state values and allows the state value to wrap to the start of the cycle without resetting
the solver, which can slow simulation performance.
For example, you can model the angular position of a wheel as having a value that is always between
0 and 2π. When the wheel rotates beyond an angular position of 2π, the angular position wraps back
to 0 rather than continually increasing.
R2023a: Use local solver for model reference at any location in model hierarchy
Model blocks at any location in a model hierarchy can use a local solver, including Model blocks
inside referenced models that use local solvers.
R2022b: Local solver support for accelerator and rapid accelerator simulation
Accelerator and rapid accelerator mode support simulating model reference hierarchies that use local
solvers.
See Also
Blocks
Model
Model Settings
Solver | Fixed-step size (fundamental sample time)
Topics
“Use Local Solvers in Referenced Models”
“Improve Simulation Performance by Using Local Solvers”
“Model Configuration Parameters: Model Referencing” on page 15-2
15-39
15 Model Referencing Parameters
Model dependencies
User-created files and data that potentially impact simulation results
Description
The Model dependencies configuration parameter improves rebuild detection speed and accuracy
by letting you specify user-created dependencies when the Rebuild configuration parameter is set to
either If changes detected or If changes in known dependencies detected.
The dependencies automatically include the model and linked library files, so you do not need to
specify those files in the Model dependencies configuration parameter.
To help identify model dependencies, use the Dependency Analyzer. For more information, see
“Analyze Model Dependencies”.
To prevent invalid simulation results when the Rebuild configuration parameter is set to If
changes in known dependencies detected, list all user-created dependencies in the Model
dependencies configuration parameter. When determining whether a model reference target is up to
date, the software examines dependencies that it automatically identifies and files specified by the
Model dependencies parameter.
If the software cannot find a specified dependent file when you update or simulate a model that
references this model, the software displays a warning.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Total number of instances allowed per top model to One or
Multiple.
15-40
Model dependencies
Settings
'' (default) | character vector | cell array of character vectors
Specify dependencies as a character vector or cell array of character vectors, where each cell array
entry is one of these values:
• File name — The software looks on the MATLAB path for a file with the given name. If the file is
not on the MATLAB path, specify the path to the dependent file. The file name must include a file
extension, such as .m or .mat.
• Path to the dependent file — The path can be relative or absolute and must include the file name.
• Folder — The software treats every file in that folder as a dependent file. Files of subfolders of the
folder you specify are not included.
• Spaces
• The token $MDL as a prefix to a dependency to indicate that the path to the dependency is relative
to the location of this model file
• An asterisk (*) as a wild card
• A percent sign (%) to comment out a line
• An ellipsis (...) to continue a line
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: ModelDependencies
Type: character vector
Value: any valid value
Default: ''
Version History
Introduced before R2006a
15-41
15 Model Referencing Parameters
See Also
Blocks
Model
Model Settings
Rebuild
Topics
“Model Configuration Parameters: Model Referencing” on page 15-2
15-42
Perform consistency check on parallel pool
Description
The Perform consistency check on parallel pool configuration parameter determines whether to
perform checks on the parallel pool before starting a parallel build.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Settings
on (default) | off
on
If a check fails, an error is issued and the parallel build stops.
off
If a check fails, a warning is issued and a serial build is performed.
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
15-43
15 Model Referencing Parameters
Application Setting
Safety precaution No recommendation
Programmatic Use
Parameter: ParallelModelReferenceErrorOnInvalidPool
Value: 'on' | 'off'
Default: 'on'
Version History
Introduced in R2021a
See Also
Topics
“Reduce Update Time for Referenced Models by Using Parallel Builds”
“Reduce Build Time for Referenced Models by Using Parallel Builds” (Simulink Coder)
“Model Configuration Parameters: Model Referencing” on page 15-2
15-44
Pass fixed-size scalar root inputs by value for code generation
Description
The Pass fixed-size scalar root inputs by value for code generation configuration parameter
determines whether a model that references this model passes its scalar root inputs to this model by
reference or by value.
Passing root inputs by value allows this model to read its scalar inputs from register or local memory,
which is faster than reading the inputs from their original locations and usually generates more
efficient code.
Passing root inputs by value for a model that contains a function-call subsystem might cause the
simulation behavior to differ from the generated code behavior. When the software provides an error
or warning about function-call subsystem inputs that might cause inconsistent behavior, latch the
function-call subsystem inputs. For more information, see Context-dependent inputs.
In a model reference hierarchy, how you open the Configuration Parameters dialog box determines
whether you edit the configuration parameter for the top model in the current model hierarchy or the
current referenced model.
• Top model in the current model hierarchy — In the Simulink Toolstrip, on the Modeling tab, click
Model Settings.
• Current referenced model — In the Simulink Toolstrip, on the Modeling tab, click the Model
Settings button arrow. Then, in the Referenced Model section, select Model Settings.
Alternatively, open the referenced model as a top model. Then, in the Simulink Toolstrip, on the
Modeling tab, click Model Settings.
Dependencies
To enable this parameter, set Total number of instances allowed per top model to One or
Multiple.
Settings
off (default) | on
on
A model that references this model passes scalar inputs to this model by value.
off
The parent model passes the inputs by reference. It passes the addresses of the inputs rather
than the input values.
15-45
15 Model Referencing Parameters
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
Programmatic Use
Parameter: ModelReferencePassRootInputsByReference
Value3: 'on' | 'off'
Default: 'on'
Limitations
• The Pass fixed-size scalar root inputs by value for code generation configuration parameter
setting is ignored in either of these two cases:
Version History
Introduced before R2006a
See Also
Model
Topics
“Using Function-Call Subsystems”
3 This table maps the programmatic values to the equivalent interactive values of the Pass fixed-size scalar
root inputs by value for code generation configuration parameter.
ModelReferencePassRootInputsByReference Equivalent Pass fixed-size scalar root inputs by value for code
Value generation Value
'on' off
'off' on
15-46
Pass fixed-size scalar root inputs by value for code generation
15-47
16
The Simulation Target category includes parameters for configuring the simulation target for a
model. In the Configuration Parameters dialog box, the following parameters are in the Simulation
Target pane.
16-2
Model Configuration Parameters: Simulation Target
Parameter Description
“Import custom code” on page 16-35 Specify whether or not to parse available custom
code variables and functions and compile custom
code into its own simulation target.
16-3
16 Simulation Target Parameters
Parameter Description
Block reduction Reduce execution time by collapsing or removing
groups of blocks.
Compiler optimization level Sets the degree of optimization used by the
compiler when generating code for acceleration.
Hardware acceleration Select whether or not to use hardware
acceleration and the level of hardware
acceleration.
Conditional input branch execution Improve model execution when the model
contains Switch and Multiport Switch blocks.
Verbose accelerator builds Select the amount of information displayed
during code generation for Simulink Accelerator
mode, referenced model Accelerator mode, and
Rapid Accelerator mode.
Dynamic memory allocation in MATLAB functions Use dynamic memory allocation (malloc) for
variable-size arrays whose size (in bytes) is
greater than or equal to the dynamic memory
allocation threshold. This parameter applies to
MATLAB code in a MATLAB Function block, a
Stateflow chart, or a System object associated
with a MATLAB System block.
Dynamic memory allocation threshold in MATLAB Use dynamic memory allocation (malloc) for
functions variable-size arrays whose size (in bytes) is
greater than or equal to a threshold. This
parameter applies to MATLAB code in a MATLAB
Function block, a Stateflow chart, or a System
object associated with a MATLAB System block.
Enable continuous-time MATLAB functions to Enable continuous-time MATLAB functions to
write to initialized persistent variables write to initialized persistent variables. If
disabled, continuous-time MATLAB functions can
only initialize and read persistent variables.
Enable memory integrity checks on page 2-113 Detects violations of memory integrity in code
generated for MATLAB Function blocks and stops
execution with a diagnostic.
Compile-time recursion limit for MATLAB For compile-time recursion, control the number of
functions copies of a function that are allowed in the
generated code.
Enable run-time recursion for MATLAB functions Allow recursive functions in code that is
generated for MATLAB code that contains
recursive functions.
Enable implicit expansion in MATLAB functions Enable implicit expansion in code that is
generated for MATLAB code that contains binary
operations and functions.
Use precompiled libraries for MATLAB functions Instruct the code generator to favor either usage
of precompiled libraries or usage of alternative
implementations.
16-4
Model Configuration Parameters: Simulation Target
Parameter Description
Generate typedefs for imported bus and Determines typedef handling and generation for
enumeration types imported bus and enumeration data types in
Stateflow and MATLAB Function blocks.
Break on Ctrl+C on page 2-95 Enables responsiveness checks in code generated
for MATLAB Function blocks, Stateflow charts,
and dataflow domains.
Echo expressions without semicolons Enable run-time output in the MATLAB Command
Window, such as actions that do not terminate
with a semicolon.
Allow setting breakpoints during simulation Enable adding breakpoints in MATLAB Function
blocks, Stateflow charts, State Transition blocks,
and Truth Table blocks during simulation.
“Reserved names” on page 16-37 Enter the names of variables or functions in the
generated code that match the names of variables
or functions specified in custom code for a model
that contains MATLAB Function blocks, Stateflow
charts, or Truth Table blocks.
See Also
Related Examples
• “What Is Acceleration?”
• “How Acceleration Modes Work”
• “Determine Why Simulink Accelerator Is Regenerating Code”
• “Manage Simulation Targets for Referenced Models”
• “Speed Up Simulation” (Stateflow)
16-5
16 Simulation Target Parameters
Language
Description
Specify C or C++ code generation for simulation targets. This configuration parameter affects:
The Simulation cache folder configuration parameter determines where to save the generated C or
C++ files.
Settings
Default: C
C
Generates C code for simulation targets.
C++
Generates C++ code for simulation targets.
• Generate MATLAB Function block or Stateflow chart MEX code as C++ files and compile code
using C++. For MATLAB Function and MATLAB System blocks, if you add C++ code to
buildInfo using coder.updateBuildInfo or coder.ExternalDependency, set
Language to C++.
• Simulate a MATLAB System block through code generation and compilation using C++.
• Use a C Function block to interface with C++ classes defined in your custom code. See
“Interface with C++ Classes Using C Function Block”.
A model cannot have a C++ simulation target if it contains a Simscape block with a source file that
contains MATLAB functions.
Before you build a system, configure Simulink to use a compiler system using mex -setup.
Command-Line Information
Parameter: SimTargetLang
Value: 'C' | 'C++'
Default: 'C'
16-6
Language
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
See Also
Related Examples
• “Model Configuration Parameters: Simulation Target” on page 16-2
• “Manage Simulation Targets for Referenced Models”
16-7
16 Simulation Target Parameters
GPU acceleration
Description
Speed up the execution of MATLAB Function block on NVIDIA GPUs by generating CUDA code. This
option requires a GPU Coder license.
Settings
Default: Off
On
Enables simulation acceleration by using GPU Coder. When this option is on, the software
generates CUDA MATLAB executable (MEX) code from the block and dynamically links the
generated code to Simulink during simulation.
Off
Disables simulation acceleration by using GPU Coder.
Command-Line Information
Parameter: GPUAcceleration
Type: character vector
Value: 'on' | 'off'
Default: 'off'
Recommended Settings
Application Setting
Debugging On
Traceability No impact
Efficiency No impact
Safety precaution On
See Also
Related Examples
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-8
Enable custom code analysis
Description
Specify whether or not to enable Simulink Coverage and Simulink Design Verifier support for custom
code. This option affects the C Caller block, the C Function block, the MATLAB Function block, the
MATLAB System block, and Stateflow charts.
Settings
Default: Off
On
Enables Simulink Coverage and Simulink Design Verifier support for custom code.
Off
Disables Simulink Coverage and Simulink Design Verifier support for custom code.
Command-Line Information
Parameter: SimAnalyzeCustomCode
Value: 'on' | 'off'
Default: 'off'
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Coverage for Custom C/C++ Code in Simulink Models” (Simulink Coverage)
16-9
16 Simulation Target Parameters
Additional code
Description
Specify additional custom code to import into Simulink.
Settings
Default: ' '
Command-Line Information
Parameter: SimCustomSourceCode
Type: character vector
Value: any C code
Default: ''
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-10
Include headers
Include headers
Description
Specify interface header code containing types and function declarations to import into Simulink.
Settings
Default: ' '
Tips
• Write valid C/C++ code. When you include a custom header file, use the #include directive. You
can also include extern declarations of variables or functions.
• Additionally, for versions R2024a or later, you can include a custom header file without the
#include directive. However, mixed declarations in a single configuration parameter set are not
supported. For this parameter, mixed declarations occur when any one of the following conditions
is met.
16-11
16 Simulation Target Parameters
Command-Line Information
Parameter: SimCustomHeaderCode
Type: character vector or string scalar
Value: any C code
Default: ""
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Specify and Configure Custom C/C++ Code”
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-12
Initialize code
Initialize code
Description
Specify C/C++ code to execute at the start of simulation.
Settings
Default: ' '
Tip
• Use this code to invoke functions that allocate memory or to perform other initializations of your
custom code.
Command-Line Information
Parameter: SimCustomInitializer
Type: character vector
Value: any C code
Default: ''
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-13
16 Simulation Target Parameters
Terminate code
Description
Specify C/C++ code to execute at the end of simulation.
Settings
Default: ' '
Tip
• Use this code to invoke functions that free memory allocated by the custom code or to perform
other cleanup tasks.
Command-Line Information
Parameter: SimCustomTerminator
Type: character vector
Value: any C code
Default: ''
Recommended Settings
Application Setting
Debugging No recommendation
Traceability No recommendation
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-14
Include directories
Include directories
Description
Specify directories containing header and source files.
Settings
Default:''
Note If you specify a Windows® path containing one or more spaces, you must enclose the character
vector in double quotes. For example, the second and third paths in the Include directories entry
below must be double-quoted:
If you set the equivalent command-line parameter SimUserIncludeDirs, each path containing
spaces must be separately double-quoted within the single-quoted third argument, for example,
Command-Line Information
Parameter: SimUserIncludeDirs
Type: character vector or string scalar
Value: any folder path
Default: ""
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
16-15
16 Simulation Target Parameters
See Also
Related Examples
• “Specify and Configure Custom C/C++ Code”
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-16
Source files
Source files
Description
Specify custom code source files.
Settings
Default:''
You can separate source files with a comma, a space, or a new line.
Limitation
This parameter does not support Windows file names that contain embedded spaces.
Tip
• The file name is sufficient if the file is in the current MATLAB folder or in one of the directories
specified in Include directories.
Command-Line Information
Parameter: SimUserSources
Type: character vector or string scalar
Value: any file name
Default: ""
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
See Also
Related Examples
• “Specify and Configure Custom C/C++ Code”
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-17
16 Simulation Target Parameters
Libraries
Description
Specify a list of static libraries and/or shared libraries that contain custom object code to link into the
target.
Settings
Default:''
Limitation
This parameter does not support Windows file names that contain embedded spaces.
Tips
• The file name is sufficient if the file is in the current MATLAB folder or in one of the directories
specified in Include directories.
Command-Line Information
Parameter: SimUserLibraries
Type: character vector or string scalar
Value: any library file name
Default: ""
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
See Also
Related Examples
• “Specify and Configure Custom C/C++ Code”
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-18
Defines
Defines
Description
Specify preprocessor macro definitions to be added to the compiler command line.
Settings
Default: ''
Enter a list of macro definitions for the compiler command line. Specify the parameters with a space-
separated list of macro definitions. If a makefile is generated, these macro definitions are added to
the compiler command line in the makefile. The list can include simple definitions (for example, -
DDEF1), definitions with a value (for example, -DDEF2=1), and definitions with a space in the value
(for example, -DDEF3="my value"). Definitions can omit the -D (for example, -DFOO=1 and FOO=1
are equivalent). If the toolchain uses a different flag for definitions, the code generator overrides the
-D and uses the appropriate flag for the toolchain.
Command-Line Information
Parameter: SimUserDefines
Type: character vector
Value: preprocessor macro definition
Default: ''
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-19
16 Simulation Target Parameters
Compiler flags
Description
Specify additional flags to be added to the compiler command line.
Settings
Default: ''
Enter a list of additional flags for the compiler command line. Specify the flags with a space-
separated list. If a makefile is generated, these flags are added to the compiler command line in the
makefile. Acceptable flag content and syntax depend on the compiler being used.
Command-Line Information
Parameter: SimCustomCompilerFlags
Type: character vector
Value: compiler flags
Default: ''
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-20
Linker flags
Linker flags
Description
Specify additional flags to be added to the linker command line.
Settings
Default: ''
Enter a list of flags for the linker command line. Specify the flags with a space-separated list. If a
makefile is generated, these macro definitions are added to the linker command line in the makefile.
Acceptable flag content and syntax depend on the linker being used.
Command-Line Information
Parameter: SimCustomLinkerFlags
Type: character vector
Value: linker flags
Default: ''
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-21
16 Simulation Target Parameters
Deterministic functions
Description
Specify which custom code functions are deterministic, that is, always producing the same outputs
for the same inputs. If a custom code function is specified as deterministic, then a C Caller or C
Function block that calls that function can be used in a For Each subsystem or with continuous
sample time, and the block is optimized for use in conditional input branch execution. When a block is
optimized for use in conditional input branch execution, it is executed only if it is in the active branch
of a Switch or Multiport Switch block, both in simulation and in generated code. See Conditional
input branch execution. This parameter is enabled only if Import custom code is selected.
Settings
Default: None
None
None of the custom code functions are deterministic.
All
All of the custom code functions are deterministic.
By function
The custom code functions that are deterministic are listed in “Specify by function” on page 16-
24.
Note If a C Function block references any custom code global variables in its code, then this
parameter must be set to All in order for the block to be used in a For Each subsystem or with
continuous sample time, or to be optimized for use in conditional input branch execution.
Command-Line Information
Parameter: DefaultCustomCodeDeterministicFunctions
Type: character vector
Value: 'None' | 'All' | 'ByFunction'
Default: 'None'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
16-22
Deterministic functions
See Also
Related Examples
• “Model Configuration Parameters: Simulation Target” on page 16-2
• C Caller
• C Function
• For Each Subsystem
• Conditional input branch execution
16-23
16 Simulation Target Parameters
Specify by function
Description
Specify which custom code functions are deterministic, that is, always producing the same outputs
for the same inputs. This parameter is enabled only when the “Deterministic functions” on page 16-22
parameter is set to By Function. If a custom code function is specified as deterministic, then a C
Caller or C Function block that calls that function can be used in a For Each subsystem or with
continuous sample time, and the block is optimized for use in conditional input branch execution.
When a block is optimized for use in conditional input branch execution, it is executed only if it is in
the active branch of a Switch or Multiport Switch block, both in simulation and in generated code.
See Conditional input branch execution.
Settings
Specify the names of custom code functions that are deterministic, that is, always producing the same
outputs for the same inputs.
Add
Add a name to the list of custom code deterministic functions.
Remove
Remove a name from the list of custom code deterministic functions.
Tip If you do not see a list of your custom code functions in the Specify by function dialog, close
the dialog, click Validate custom code, and click Specify by function again.
Command-Line Information
Parameter: CustomCodeDeterministicFunctions
Type: character vector
Value: names of custom code functions, separated by commas
Default: ''
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
16-24
Specify by function
See Also
Related Examples
• “Model Configuration Parameters: Simulation Target” on page 16-2
• C Caller
• C Function
• For Each Subsystem
• Conditional input branch execution
16-25
16 Simulation Target Parameters
Description
Specify how input array data is handled by external C/C++ functions and class methods. This
parameter affects C/C++ functions and methods called by C Caller, C Function, MATLAB Function,
and MATLAB System blocks and Stateflow charts.
Settings
Default: Not specified
Column-major
External C/C++ functions and class methods assume input array data is in column-major layout.
Row-major
External C/C++ functions and class methods assume input array data is in row-major layout.
Any
External C/C++ functions and class methods are indifferent about input data array layout. If your
external function and class method algorithms do not require the matrix data to be in a specific
array layout, for example if they perform only element-wise operations on input array data, use
this option.
Not specified
External C/C++ functions and class methods make no assumption about input data array layout.
However, if Array layout (Simulink Coder) is set to Row-major, Simulink reports an error. You
can turn off the error by changing the External functions compatibility for row-major code
generation (Simulink Coder) to warning or none.
The Default function array layout parameter controls the default array layout of custom code
functions and class methods. To specify array layout for individual functions or class methods, click
Exception by function on page 16-33.
Command-Line Information
Parameter: DefaultCustomCodeFunctionArrayLayout
Type: character vector
Value: 'Column-major' | 'Row-major' | 'Any' | 'NotSpecified'
Default: 'NotSpecified'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
16-26
Default function array layout
Application Setting
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
• “Integrate C Code Using C Caller Blocks”
16-27
16 Simulation Target Parameters
Description
Specify the behavior of undefined functions and variables in the C source code file of a model that
contains Stateflow charts or C Caller, C Function, MATLAB Function, or MATLAB System blocks. If
you declare a function or variable in the header file but do not implement it in the source code,
Simulink behaves according to this setting. Depending on the setting, Simulink takes functions and
variables from the header file and creates stub functions and variables equal to zero if they are not
defined in the C source code file. If your code is not compatible with desktop simulation, or you want
to introduce the interface to external code with the relevant header files, set this parameter to Use
interface only.
Settings
Default: Filter out
Throw error
Return an error if a function or variable in the C source code is undefined. Simulink does not
generate stub functions or variables equal to zero, but shows the functions and variables in the
Port Specification table of the C Caller block.
Filter out
Filter out undefined functions and variables in the C source code. Simulink does not automatically
generate stub functions or variables equal to zero, and the Port Specification table of the C
Caller block does not show these functions and variables.
If you have undefined functions or variables in the C source code and a model that contains a
Stateflow chart, MATLAB Function, or MATLAB System block calls these functions or variables,
Simulink returns an error. If the custom code in the blocks in your model has undefined functions
or variables, Simulink displays a warning.
Do not detect
Do not detect undefined functions or variables in the source code. Simulink does not
automatically generate stub functions or variables equal to zero, but shows the functions and
variables in the Port Specification table of the C Caller block.
Use interface only
Detect undefined functions and variables in the C source code. Simulink generates stub functions
and variables equal to zero, makes them visible in the model, and allows you to call them from
Stateflow charts and C Function, MATLAB Function, and MATLAB System blocks.
Command-Line Information
Parameter: CustomCodeUndefinedFunction
Value: 'ThrowError' | 'FilterOut' | 'DoNotDetect' | 'UseInterfaceOnly'
Default: 'FilterOut'
16-28
Undefined function and variable handling
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
• C Caller
16-29
16 Simulation Target Parameters
Description
Run custom code in a separate process outside of MATLAB during model simulation. This option
applies to external code integrated into the model using C Caller, C Function, MATLAB Function, and
MATLAB System blocks and Stateflow charts.
Settings
Default: Off
On
Custom code runs in a separate process during model simulation, thus preventing a MATLAB
crash due to unexpected exceptions in the custom code or errors in the interface between
Simulink and the custom code. A run-time exception in the custom code produces an error
message in Simulink that provides detailed information about the exception, such as which block
or line number is responsible, to help resolve any issues with the code. If a supported external
debugger is installed, the error message provides a button to launch the external debugger. For
more information, see “Debug Custom C/C++ Code”.
Selecting this parameter allows you to map a pointer type argument of a custom code C function
to an output port of a C Caller block without explicitly specifying its size in the Port
Specification table of the block. See “Map C Function Arguments to Simulink Ports”.
Off
Custom code runs in the same process as the rest of the model during simulation. Simulation
usually runs faster, but a run-time exception in the custom code could cause MATLAB to crash.
Command-Line Information
Parameter: SimDebugExecutionForCustomCode
Value: 'on' | 'off'
Default: 'off'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
16-30
Simulate custom code in a separate process
See Also
“Model Configuration Parameters: Simulation Target” on page 16-2 | C Caller | C Function | MATLAB
Function | MATLAB System
More About
• “Integrate C Code Using C Caller Blocks”
• “Integrate External C/C++ Code into Simulink Using C Function Blocks”
16-31
16 Simulation Target Parameters
Description
Specify the behavior of global variables in custom code called by the C Caller block. If you select this
option, the C Caller block automatically infers global variables from the custom code on the block
interface.
Settings
Default: Off
On
Enables automatic addition or deletion of global variables from the custom code called by C
Caller block. C Caller block treats the global variables in your custom code as global arguments
on the block interface. These arguments appear in bold on the Port Specification table.
Off
Disables automatic addition or deletion of global variables from the custom code called by the C
Caller block. From the MATLAB command line, use the addGlobalArg function to add or the
deleteGlobalArg function to delete global arguments.
Command-Line Information
Parameter: CustomCodeGlobalsAsFunctionIO
Value: 'on' | 'off'
Default: 'off'
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
See Also
“Model Configuration Parameters: Simulation Target” on page 16-2 | C Caller |
FunctionPortSpecification | getGlobalArg | addGlobalArg | deleteGlobalArg
More About
• “Integrate C Code Using C Caller Blocks”
16-32
Exception by function
Exception by function
Description
Specify how input array data is handled by each external C/C++ function and class method.
Settings
Specify how input array data is handled by each external C/C++ function and class method in your
custom code. The array layout specified for an individual function or class method takes precedence
over the option specified in Default function array layout on page 16-26. Use these options to add
or remove the array layout setting for an individual function or class method:
Add
Add custom C/C++ function or class method and specify its array layout setting. To specify a
class method, use the syntax ClassName::MethodName.
Remove
Remove custom C/C++ function or class method from the exception list and apply default array
layout to the function or class method.
Tip If you do not see a list of your custom code functions in the Exception by function dialog, close
the dialog, click Validate custom code, and click Exception by function again.
Command-Line Information
Parameter: CustomCodeFunctionArrayLayout
Type: structure array
Value: structure with 'FunctionName' and 'ArrayLayout' fields. 'ArrayLayout' can be
'Column-major', 'Row-major' or 'Any'.
Default: ' '
Example
Consider the model foo_model. If you have external C/C++ functions and class methods that you
interface with the model, execute these MATLAB commands to specify array layouts for the functions
and class methods.
arrayLayout(1).FunctionName = 'MyCFunction1';
arrayLayout(1).ArrayLayout = 'Column-major';
arrayLayout(2).FunctionName = 'MyCFunction2';
arrayLayout(2).ArrayLayout = 'Row-major';
arrayLayout(3).FunctionName = 'myClass::getboolRes';
arrayLayout(3).ArrayLayout = 'Row-major';
set_param('foo_model', 'CustomCodeFunctionArrayLayout', arrayLayout)
16-33
16 Simulation Target Parameters
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No recommendation
Safety precaution No recommendation
See Also
Related Examples
• “Integrate External Code by Using Model Configuration Parameters” (Simulink Coder)
• “Model Configuration Parameters: Simulation Target” on page 16-2
• C Caller
16-34
Import custom code
Description
Specify whether or not to parse available custom code variables and functions and compile custom
code into its own simulation target. This option affects the C Caller block, the C Function block, the
MATLAB Function block, the MATLAB System block, and Stateflow charts.
Settings
Default: On
On
When this option is on, Simulink:
• Uses the same custom code for simulation with the C Caller block, the C Function block, the
MATLAB Function block, the MATLAB System block, and Stateflow charts. When using the C
Caller block or the C Function block, this option must be turned on.
• Automatically rebuilds the custom code simulation target when specified custom code
dependencies change.
• Automatically rebuilds simulation targets for blocks using custom code when custom code
changes.
• Enables Just-In-Time (JIT) compilation of the C Caller block, the C Function block, the
MATLAB Function block, the MATLAB System block, and Stateflow charts.
• Allows the Enable custom code analysis option to enable Simulink Coverage and Simulink
Design Verifier support for custom code.
• Allows edit and compile time error detection for C interface errors from your model.
• Calls specified initialize code and terminate code at the start and end of model simulation,
respectively, regardless of whether any block in the model calls external custom code. See
Initialize function and Terminate function.
• Enables parsing of custom code to report unresolved symbols in Stateflow charts in your
model.
• Requires that your custom code be complete and not dependent on any other files in order to
be built.
Off
When this option is off, Simulink:
• Combines Simulation Target custom code dependencies with those specified by other means
(coder.cinclude, coder.updateBuildInfo, and coder.ExternalDependency) in
Stateflow charts that use MATLAB as the action language, MATLAB Function blocks, and
MATLAB System blocks.
• Calls specified initialize code and terminate code only if necessary. If no block in the model
calls external custom code, Simulink does not call the initialize code or the terminate code.
See Initialize function and Terminate function.
16-35
16 Simulation Target Parameters
Note When this option is on, if you use the same custom code across different unique configurations,
each unique configuration is treated as a separate unit even if the configurations refer to the same
custom code. For instance, if you have a root-level model and a library subsystem that refer to the
same custom code, then the custom code global variables accessed by the library block and the root-
level model are different.
Note In most cases, Import custom code should be selected. Clear the Import custom code
parameter only if your custom code is incompatible with this parameter.
Command-Line Information
Parameter: SimParseCustomCode
Value: 'on' | 'off'
Default: 'on'
Recommended Settings
Application Setting
Debugging On
Traceability No impact
Efficiency No impact
Safety precaution On
See Also
Related Examples
• “Reuse Custom Code in Stateflow Charts” (Stateflow)
• “Manage Symbols in the Stateflow Editor” (Stateflow)
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-36
Reserved names
Reserved names
Description
Enter the names of variables or functions in the generated code that match the names of variables or
functions specified in custom code for a model that contains MATLAB Function blocks, Stateflow
charts, or Truth Table blocks.
Settings
Default: {}
This action changes the names of variables or functions in the generated code to avoid name conflicts
with identifiers in custom code. Reserved names must be shorter than 256 characters.
Tips
• Start each reserved name with a letter or an underscore to prevent error messages.
• Each reserved name must contain only letters, numbers, or underscores.
• Separate the reserved names using commas or spaces.
• You can also specify reserved names by using the command line:
config_param_object.set_param('SimReservedNameArray', {'abc','xyz'})
where config_param_object is the object handle to the model settings in the Configuration
Parameters dialog box.
Command-Line Information
Parameter: SimReservedNameArray
Type: cell array of character vectors or string array
Value: any reserved names shorter than 256 characters
Default: {}
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No recommendation
16-37
16 Simulation Target Parameters
See Also
Related Examples
• “Model Configuration Parameters: Simulation Target” on page 16-2
16-38
17
In this section...
“Specify data transfer settings” on page 17-2
“Data transfer handling option” on page 17-2
“Extrapolation method (continuous-time signals)” on page 17-2
“Initial condition” on page 17-2
This tab displays the data transfer options for configuring models for targets with multicore
processors.
Initial condition
For discrete signals, this parameter specifies the initial input on the reader side of the data transfer.
It applies for data transfer types Ensure Data Integrity Only and Ensure deterministic
transfer (maximum delay). Simulink does not allow this value to be Inf or NaN.
For continuous signals, the extrapolation method of the initial input on the reader side of the data
transfer uses this parameter. It applies for data transfer types Ensure Data Integrity Only and
Ensure deterministic transfer (maximum delay). Simulink does not allow this value to be
Inf or NaN.
For more information, see “Configure Data Transfer Settings Between Concurrent Tasks”.
17-2
Data Transfer Options for Concurrent Execution
See Also
Signal Properties
17-3
18
Configuration
New models use these styles. For details, see “Customize Model Fonts”.
1 Use the lists to specify font types, styles, and sizes to apply to new block diagrams.
2 Click OK.
18-2
19
A mask is a custom user interface for a block that hides the block's contents, making it appear to the
user as an atomic block with its own icon and parameter dialog box.
The Mask Editor dialog box helps you create and customize the block mask. The Mask Editor
dialog box opens when you create or edit a mask. You can access the Mask Editor dialog box by any
of these options:
To create mask,
To edit mask,
Note You can also use the keyboard shortcut CTRL + M to open Mask Editor.
The Mask Editor dialog box contains a set of tabbed panes, each of which enables you define a
feature of the mask. These tabs are:
• “Parameters & Dialog Pane” on page 19-2: To design mask dialog boxes.
• “Code Pane” on page 19-17: To initialize a masked block using MATLAB code.
• “Icon Pane” on page 19-20: To create block mask icons.
• “Constraints” on page 19-29: To create constraints.
Note For information on creating and editing a block mask from command line, see “Control Masks
Programmatically”.
19-2
Mask Editor Overview
The Parameters & Dialog pane enables you to design mask dialog boxes using the dialog controls in
the Parameters, Display, and Action palettes.
19-3
19 Simulink Mask Editor
Controls
The controls section is sub divided into Parameters, Display, and Action sections. The Controls Table
lists the different controls and their description.
19-4
Mask Editor Overview
Controls Table
Controls Description
Parameters
Edit Allows you to enter a parameter
value by typing it into the field.
19-5
19 Simulink Mask Editor
Controls Description
Radio button Allows you to select a parameter
value from a list of possible
values. All options for a radio
button are displayed on the mask
dialog.
19-6
Mask Editor Overview
Controls Description
Dial Allows you to dial to values
within a range defined by
minimum and maximum values. A
Dial parameter can accept input
as a number or a variable name.
If the specified variable is a base
workspace or a model workspace
variable, you can tune the
variable value through the Dial.
19-7
19 Simulink Mask Editor
Controls Description
Unit Allows you to set the
measurement units for output or
input values of a masked block.
The Unit parameter can accept
any units of measurement as
input. For example, rad/sec for
angular velocity, meters/sec2 for
acceleration, or distance in km or
m.
Custom Table Allows you to add tables in the
mask dialog box. You can add
values as a nested cell array in
the Values section of the
Property editor.
Promote One-to-One Allows you to selectively promote
block parameters from
underlying blocks to the mask.
Click the Promote One-to-One
to open the Promoted
Parameter Selector dialog box.
In this dialog box, you can select
the block parameters that you
want to promote. Click OK to
close it.
Promote Many-to-One Allows you to promote all
underlying block parameters to
the mask. When you promote all
parameters, the promote
operation deletes parameters
that have been promoted
previously.
Container
Group box Container to group other dialog
controls and containers in the
mask dialog box.
Tab Tab to group dialog controls in
the mask dialog box. A tab is
contained within a tab container.
A tab container can have multiple
tabs.
19-8
Mask Editor Overview
Controls Description
Table Container to group the Edit,
Check box, and the Popup
parameters in a tabular form. You
can also search and sort the
content listed within the Table
container.
19-9
19 Simulink Mask Editor
Controls Description
Tree Control Allows you to display value in a
hierarchical tree of possible
values. You can select multiple
values (Ctrl + click). See
“Examples” for more
information.
Lookup Table Control Allows you to visualize n-
dimensional table and breakpoint
data.
Web Browser Allows you to open a website on
previewing the dialog. Enter the
address in the URL property.
Action
Hyperlink Hyperlink text displayed on the
mask dialog box.
Button Button controls on the mask
dialog box. You can program
button for specific actions. You
can also add an image on a
button controls.
For more information on the mask parameters, explore the example model “Types of Mask
Parameters” on page 19-48.
Dialog box
You can build a hierarchy of dialog controls by dragging them from a Controls section to the
Parameters and Dialog tab. You can also click the palettes on the Controls section to add the
required control to the Parameters and Dialog tab. You can add a maximum of 32 levels of
hierarchy in the Parameters and Dialog tab.
The Parameters and Dialog displays three fields: Type, Prompt, and Name.
• The Type field shows the type of the dialog control and it cannot be edited. It also displays a
sequence number for parameter dialog controls.
• The Prompt field shows the prompt text for the dialog control.
• The Name field is auto-populated and uniquely identifies the dialog controls. You can choose to
add a different value (valid MATLAB name) in the Name field and must not match the built-in
parameter name.
The Parameter controls are displayed in light blue background whereas the Display and Action
controls are displayed in white background on the Dialog box.
You can move a dialog control in the hierarchy, you can copy and paste a dialog control, you can also
delete a node. For more information, see “Dialog Control Operations” on page 19-32.
Property editor
The Property editor allows you to view and set the properties for Parameter, Display, Container,
and Action dialog controls. The Property editor for Parameter is shown:
19-10
Mask Editor Overview
You can set the following properties for Parameter, Action, and Display dialog controls. For more
information, see the Property editor table.
19-11
19 Simulink Mask Editor
Property editor
Property Description
Properties
Name Uniquely identifies the dialog control in the mask dialog box. The
Name property must be set for all dialog controls.
Alias Alternate name for the dialog control. For example, you can also
use the alternate name of the parameter to set the value of the
parameter.
Value Value of the Parameter. The Value property applies only to the
Parameter dialog controls.
Prompt Label text that identifies the parameters in a mask dialog box. The
Prompt property applies to all dialog controls except Panel and
Image dialog control.
Type Type of the dialog control. You can use the Type field to change
the Parameter and Container types. You cannot change any
container type to Tab and vice versa.
Expand Allows you to specify if the collapsible panel dialog control is
expanded or collapsed, by default.
Type options The Type options property allows you to set specific Parameter
properties. The Type options property applies to the Popup,
Radio button, DataTypeStr, and Promoted parameters.
File path You can add an image to a mask using the Image dialog control.
You can also display an image on a Button dialog control. In
either case, provide the path to the image in the File path
property that is enabled for these two dialog controls. For the
Button dialog control, specify an empty character vector for the
Prompt property in order for the image to be displayed.
Note that, when you provide the filepath, do not use the quote
marks (' '). For example, if you want to add an image, provide the
filepath as: C:\Users\User1\Image_Repositort\motor.png
Word wrap The Word wrap property enables word wrapping for long text.
The Word wrap property applies only for Text dialog control.
Maximum and Minimum The Maximum and Minimum properties enable you to specify a
range for controls like Spinbox, Slider, and Dial.
Step size Allows you to specify a step size for the values. This property
applies only for Spinbox dialog control.
Tooltip Allows you to specify a tooltip for the selected dialog control type.
The tooltip is visible when you hover the cursor over a dialog
control on the mask dialog box. You can add tooltips for all dialog
controls type except for Group box, Tab, CollapsiblePanel, and
Panel.
Scale Allows you to set the tuning scale as linear or log for Slider
and Dial dialog controls.
Table Parameter Specify table data for the Lookup Table parameter.
19-12
Mask Editor Overview
Property Description
Table Unit Specify units for the table data.
Table Display Name Specify display name for the Lookup Table control.
Breakpoint Parameters Specify breakpoint parameters for the Lookup Table control. For
example, {'torque','engine speed'}
Breakpoint Units Specify the units for breakpoint parameters. For example,
{'Nm','rpm'}
Data Specification You can specify data for table and breakpoint parameters by
explicitly specifying the values in the parameters or through a
data object
Lookup Table Object Specify the name of the data object for the table and breakpoint
parameters values
Text Type Specify the type of text for the Text Area parameter. It can accept
Plain Text, HTML Text, and MATLAB code. The Text Area
parameter has the capability to process the HTML code and
display the output in the mask dialog box. Similarly, it can process
the MATLAB code and display the output.
Attributes
Evaluate If you enter a MATLAB expression as a mask parameter input,
Simulink handles the entry in one of two ways:
19-13
19 Simulink Mask Editor
Property Description
Tunable Set the Tunable property of the mask parameter to change the
value of a mask parameter during simulation.
off on run-to-run
Normal read-only read-write
Fast Restart read-only read-write read-write
19-14
Mask Editor Overview
Property Description
Enable By default Enable is selected. If you clear this option, the
selected control becomes unavailable for edit. Masked block users
cannot set the value of the parameter.
Visible The selected control appears in the mask dialog box only if this
option is selected.
Callback MATLAB code that you want Simulink to execute when a user
applies a change to the selected control. Simulink uses a
temporary workspace to execute the callback code.
Note The Enable/Visible properties allows to create dynamic block dialogs where parameters are
enabled or displayed based on a change in other parameter’s value.
Layout
Item location Allows you to set the location for the dialog control to appear in
the current row or a new row.
Align Prompts Allows you to align the parameters on the mask dialog box. This
option is supported for all the Display control types except Table.
Prompt location Allows you to set the prompt location for the dialog control on
either the top or to the left of the dialog control.
You cannot set the Prompt location property for Check box,
Dial, DataTypeStr, Collapsible Panel and Radiobutton.
Orientation Allows you to specify horizontal or vertical orientation for sliders
and radio buttons.
Horizontal Stretch By default, all controls stretch horizontally when you resize the
mask dialog. This option helps manage the stretch properties of
controls in the same row inside a container. For example, consider
a popup parameter and a button in the same row within a
container. Upon resizing, you may want the popup parameter to
stretch but not the button. To achieve this, set the Horizontal
Stretch property of the popup parameter to On and the button to
Off. See “Design Mask Dialog Box Layout” on page 19-52 for
more information.
Documentation Pane
The Documentation pane enables you to define or modify the type, description, and help text for a
masked block.
19-15
19 Simulink Mask Editor
Type
The mask type is a block classification that appears in the mask dialog box and on all Mask Editor
panes for the block. When Simulink displays a mask dialog box, it suffixes (mask) to the mask type.
To define the mask type, enter it in the Type field. The text can contain any valid MATLAB character,
but cannot contain line breaks.
Description
The mask description is summary help text that describes the block's purpose or function. By default,
the mask description is displayed below the mask type in the mask dialog box. To define the mask
description, enter it in the Description field. The text can contain any legal MATLAB character.
Simulink automatically wraps long lines. You can force line breaks by using the Enter key.
Help
The Online Help for a masked block provides information in addition to that provided by the Type and
Description fields. This information appears in a separate window when the masked block user
clicks the Help button on the mask dialog box. To define the mask help, type one of these in the Help
field:
• URL specification
• web or eval command
• Literal or HTML text
19-16
Mask Editor Overview
Provide a URL
If the first line of the Help field is a URL, Simulink passes the URL to your default web browser. The
URL can begin with https:, www:, file:, ftp:, or mailto:. Examples:
https://www.mathworks.com
file:///c:/mydir/helpdoc.html
Once the browser is active, MATLAB and Simulink have no further control over its actions.
If the first line of the Help field is a web command, Simulink passes the command to MATLAB, which
displays the specified file in the MATLAB web browser. Example:
See the MATLAB web command documentation for details. A web command used for mask help
cannot return values.
If the first line of the Help field is an eval command, Simulink passes the command to MATLAB,
which performs the specified evaluation. Example:
eval('open My_Spec.doc')
See MATLAB eval command documentation for details. An eval command used for mask help
cannot return values.
If the first line of the Help field is not a URL, or a web or an eval command, Simulink displays the
text in the system web browser under a heading that is the value of the Mask type field. The text can
contain any legal MATLAB character, line breaks, and any standard HTML tag, including tags like
img that display images.
Simulink first copies the text to a temporary folder, then displays the text using the web command. If
you want the text to display an image, you can provide a URL path to the image file, or you can place
the image file in the temporary folder. Use tempdir to find the temporary folder that Simulink uses
for your system.
Code Pane
The Code pane gives you an integrated view of block initialization and parameter callback code. The
Mask Editor code functionalities are like those in the MATLAB Editor, with some limitations. For
example, the autocomplete functionality is supported, but you cannot set a breakpoint in your code.
You can organize mask initialization and mask callback code in a separate MATLAB class file. See
“Organize Mask Initialization and Callbacks in a MATLAB File” for more information.
19-17
19 Simulink Mask Editor
When you open a model, Simulink locates the visible masked blocks that reside at the top level of the
model or in an open subsystem. Simulink only executes the initialization commands for these visible
masked blocks if they meet either of the following conditions:
Note Simulink does not initialize masked blocks that do not have icon drawing commands, even if
they have initialization commands.
• The masked block belongs to a library and has the Allow mask initialization code to modify
the subsystem's content setting enabled.
Initialization commands for all masked blocks in a model run when you:
19-18
Mask Editor Overview
• Change any of the mask parameters that define the mask, such as MaskDisplay and
MaskInitialization, by using the Mask Editor or the set_param command.
• Rotate or flip the masked block, if the icon depends on the initialization commands.
• Cause the icon to be drawn or redrawn, and the icon drawing depends on initialization code.
• Change the value of a mask parameter by using the block dialog box or the set_param command.
• Copy the masked block within the same model or between different models.
Click to add the initialization code template and parameter callback template in the editor. You can
enter any valid MATLAB expression, consisting of MATLAB functions and scripts, operators, and
variables defined in the mask workspace. Initialization commands run in the mask workspace, not the
base workspace.
The Code pane provides you an integrated view of the mask initialization code and the mask callback
code. To add parameter callback code, click the plus button next to the parameter from the
Parameter list, the skeleton for the callback code appears. Enter MATLAB commands for the
callback.
• Do not use initialization code for dynamic mask dialogs as initialization is not generally performed
when the mask dialog box changes. Instead, use the mask callbacks for the relevant parameters,
which are executed immediately when the given parameter is updated.
19-19
19 Simulink Mask Editor
This check box is enabled only if the masked block resides in a library. Selecting this option allows
you to modify the parameters of the masked block. If the masked block is a masked subsystem, this
option allows you to add or delete blocks and set the parameters of the blocks within that subsystem.
If this option is not selected, an error is generated when a masked library block tries to modify its
contents in any way.
Icon Pane
The Icon pane helps you to create a block icon that contains descriptive text, state equations, image,
and graphics. You can author block icon using either Graphical Editor or Mask Drawing Commands.
Graphical Editor: You can create and edit the mask icon of a block through a graphical environment.
The various features in Graphical Icon Editor helps you to create icons with ease. Launch Graphical
Icon Editor from Mask Editor.
• Interactive graphical environment: Use graphical tools like pen, curvature, text, scissor,
connector, and equation (which supports LaTeX) to create rich graphical icons. Grids, smart
19-20
Mask Editor Overview
guides, and rulers help you to create pixel-perfect icons. Apart from the drawing tools, a few built-
in shapes, such as Resistor, Inductor, and Rotational Damper, are readily available.
• Element browser: Element browser lists all the elements in the icon.
To know more about Graphical Icon Editor, see “Graphical Icon Editor Overview”.
Mask editor provides you the skeleton for each of the drawing commands. You can set an image for
the mask icon. Click Add Image to import an image.
19-21
19 Simulink Mask Editor
The Mask Icon Drawing Commands pane is divided into these sections:
• “Properties” on page 19-22: Provides a list of different controls that can be applied on the mask
icon.
• “Preview” on page 19-26: Displays the preview of the block mask icon.
• “Icon drawing commands” on page 19-27: Enables you to draw mask icon by using MATLAB
code.
Note You can create static and dynamic block mask icon. For more information, see “Mask Display
and Initialization Commands”.
Properties
Properties available in the right pane are a list of controls that allow you to specify attributes on the
mask icon. These options are,
19-22
Mask Editor Overview
The block frame is the rectangle that encloses the block. You can choose to show or hide the frame by
setting the Block Frame parameter to Visible or Invisible. The default is to make the block
frame visible. For example, this figure shows visible and invisible block frames for an AND gate block.
Icon Transparency
The icon transparency can be set to Opaque, Opaque with ports, or Transparent, based on
whether you want to hide or show what is underneath the icon. The default option Opaque hides
information such as port labels. The block frame is displayed for a transparent icon, and hidden for
the opaque icon.
For a subsystem block, if you set the icon transparency to Opaque with ports the port labels are
visible.
Note
• For the Opaque option to hide the port labels, there must be an icon drawing command added in
the mask editor.
• If you set the icon transparency to Transparent, Simulink does not hide the block frame even if
you set the Block Frame property to Invisible.
Icon Units
This option controls the coordinate system used by the drawing commands. It applies only to the
plot, text, and patch drawing commands. You can select from among these choices: Autoscale,
Normalized, and Pixel.
19-23
19 Simulink Mask Editor
• Autoscale scales the icon to fit the block frame. When the block is resized, the icon is also
resized. For example, this figure shows the icon drawn using these vectors:
X = [0 2 3 4 9]; Y = [4 6 3 5 8];
The lower-left corner of the block frame is (0,3) and the upper-right corner is (9,8). The range of
the x-axis is 9 (from 0 to 9), while the range of the y-axis is 5 (from 3 to 8).
• Normalized draws the icon within a block frame whose bottom-left corner is (0,0) and whose top-
right corner is (1,1). Only X and Y values from 0 through 1 appear. When the block is resized, the
icon is also resized. For example, this figure shows the icon drawn using these vectors:
X = [.0 .2 .3 .4 .9]; Y = [.4 .6 .3 .5 .8];
• Pixel draws the icon with X and Y values expressed in pixels. The icon is not automatically
resized when the block is resized. To force the icon to resize with the block, define the drawing
commands in terms of the block size.
Icon Rotation
When the block is rotated or flipped, you can choose whether to rotate or flip the icon or to have it
remain fixed in its original orientation. The default is not to rotate the icon. The icon rotation is
consistent with block port rotation. This figure shows the results of choosing Fixed and Rotates
icon rotation when the AND gate block is rotated.
Port Rotation
This option enables you to specify a port rotation type for the masked block. The choices are:
• default
Ports are reordered after a clockwise rotation to maintain a left-to-right port numbering order for
ports along the top and bottom of the block and a top-to-bottom port numbering order for ports
along the left and right sides of the block.
• physical
Ports rotate with the block without being reordered after a clockwise rotation.
The default rotation option is appropriate for control systems and other modeling applications where
block diagrams typically have a top-down and left-right orientation. It simplifies editing of diagrams,
by minimizing the need to reconnect blocks after rotations to preserve the standard orientation.
19-24
Mask Editor Overview
Similarly, the physical rotation option is appropriate for electronic, mechanical, hydraulic, and other
modeling applications where blocks represent physical components and lines represent physical
connections. The physical rotation option more closely models the behavior of the devices
represented (that is, the ports rotate with the block as they would on a physical device). In addition,
the option avoids introducing line crossings as the result of rotations, making diagrams easier to
read.
For example, the following figure shows two diagrams representing the same transistor circuit. In
one, the masked blocks representing transistors use default rotation and in the other, physical
rotation.
Both diagrams avoid line crossings that make diagrams harder to read. The next figure shows the
diagrams after a single clockwise rotation.
19-25
19 Simulink Mask Editor
Note The rotation introduces a line crossing the diagram that uses default rotation but not in the
diagram that uses physical rotation. Also that there is no way to edit the diagram with default
rotation to remove the line crossing. See “Flip or Rotate Blocks” for more information.
Run Initialization
The Run initialization option enables you to control the execution of the mask initialization
commands. The choices are:
• Off (Default): Does not execute the mask initialization commands. When the mask drawing
commands do not have dependency on the mask workspace, it is recommended to specify the
value of Run initialization as Off. Setting the value to Off helps in optimizing Simulink
performance as the mask initialization commands are not executed.
• On: Executes the mask initialization commands if the mask workspace is not up-to-date. When this
option is specified, the mask initialization commands are executed before executing the mask
drawing commands irrespective of the mask workspace dependency of the mask drawing
commands.
• Analyze: Executes the mask initialization commands only if there is mask workspace dependency.
When this option is specified, Simulink executes the mask initialization commands before
executing the mask icon drawing commands. The Analyze option is for backward compatibility
and is not recommended otherwise. It is recommended that the Simulink models from R2016b or
before are upgraded using the Upgrade Advisor.
For more information, see “Draw Mask Icon Using Mask Drawing Commands”.
Preview
This section displays the preview of block mask icon. Block mask preview is available only if the mask
contains an icon drawing.
19-26
Mask Editor Overview
When you add an icon drawing command and click Apply, the preview image refreshes and is
displayed in the Preview section of Icon pane.
Icon drawing commands
Add code to the editor to draw a block icon. You can use the list of commands in the left pane to draw
a block icon.
19-27
19 Simulink Mask Editor
19-28
Mask Editor Overview
Note Simulink does not support mask drawing commands within anonymous functions.
The drawing commands execute in the same sequence as they are added in the text box. Drawing
commands have access to all variables in the mask workspace. If any drawing command cannot
successfully execute, the block icon displays question marks .
The drawing commands execute after the block is drawn in these cases:
Constraints
Mask parameter constraints help you to create validations on a mask parameter without having to
write your own validation code. There are three types of constraints, Parameter Constraint, Cross
Parameter Constraints, and Port Constraints.
19-29
19 Simulink Mask Editor
Parameter Constraint: A mask can contain parameters that accept user input values. You can
provide input values for mask parameters using the mask dialog box. Constraints ensure that the
input for the mask parameter is within a specified range. For example, consider a masked Gain block.
You can set a constraint where the input value must be between 1 and 10. If you provide an input that
is outside the specified range, an error displays. Constraint Browser on the left pane helps you to
manage Shared Constraints.
Cross Parameter Constraint: Cross-parameter constraints are applied among two or more Edit or
Combobox type mask parameters. You can use a cross parameter constraint when you want to
specify scenarios such as, Parameter1 must be greater than Parameter2.
Port Constraint: You can specify constraints on the input and output ports of a masked block. The
port attributes are checked against the constraints when you compile the model.
Cross Port Constraint: Create cross port constraints to validate compile-time signal attributes
among ports of the same masked block. For example, you can set a constraint among the input and
output port signals of the masked block to have the same data type.
Additionally, you can also author parameter and port constraints without associating them to a block
mask. See “Author Parameter and Port Constraints Using Standalone Constraint Manager”.
Additional Options
Following buttons appear on the Mask Editor:
19-30
Mask Editor Overview
• Save Mask applies the mask settings and leaves the Mask Editor open.
• The Preview Dialog applies the changes you made, and opens the mask dialog box.
• The Delete Mask deletes the mask and closes the Mask Editor. To create the mask again, select
the block and on the Block tab, in the Mask group, click Create Mask.
• Copy Mask copies the mask definitions from Simulink library blocks. Search for the desired block
and click Copy Mask to import the mask definition from an existing block.
• Evaluate Block evaluates the callback and initialization code.
See Also
More About
• “Masking Fundamentals”
• “Create a Simple Mask”
• “Author Block Masks”
• Creating a Mask
19-31
19 Simulink Mask Editor
In this section...
“Moving Dialog Controls in the Dialog box” on page 19-32
“Cut, Copy, and Paste Controls” on page 19-32
“Delete Nodes” on page 19-33
“Error Display” on page 19-33
• Drag and drop on the container dialog control in the Dialog box
• Drop before it: Adds the dialog control as a sibling before the current dialog control.
• Drop after it: Adds the dialog control as a sibling after the current dialog control.
• Drag and drop on the non-container dialog control in the Dialog box
• Drop before it: Adds the dialog control before the current dialog control.
• Drop after it: Adds the dialog control after the current dialog control.
19-32
Dialog Control Operations
Delete Nodes
Right-click the control that you want to delete in the Dialog box. Select, Delete from the context
menu. For example, to delete a Check box dialog control, right-click and select Delete. You can also
use the Delete menu option to delete a dialog control.
Error Display
If you have errors in parameters names, such as, duplicate, invalid parameter names, or empty
names, the mask editor displays the parameter names in red outline. When you edit the parameters
to fix errors, the modified fields are identified by a yellow background.
19-33
19 Simulink Mask Editor
1 Duplicate Parameter, Display, and Action control names are not allowed.
2 Parameter names must be unique and are case insensitive. Names varying only in lowercase and
uppercase letters, are treated as duplicates. For example, Parameter1 and parameter1 are not
allowed.
3 Parameter , Display, and Action control names can be same as long as different lowercase and
uppercase characters are used. For example, while a and A are allowed, b and b are not allowed.
4 Action and Display control names are case-sensitive. For example, while Control3 and
control3 are allowed, control3 and control3 are not allowed.
See Also
“Author Block Masks”
19-34
Specify Data Types for an Edit Parameter Using Data Type Parameter
You can specify the acceptable data types for a mask edit parameter with a data type parameter.
Associating a data type for the edit parameter defines a rule for the input value that can be provided
through the mask dialog box. You can also use the datatype parameter to associate the minimum and
maximum value for the edit parameter. You can use datatype parameter to do fixed-point analysis.
The model demonstrates all the mask parameter types. Use the block DataTypeStr for specifying
data types and minimum and maximum values for an edit parameter. The masked block
DataTypeStr has an edit parameter Gain, a min parameter Minimum, a max parameter Maximum,
and a data type parameter DataTypeStrParameter.
open_system("slexMaskParameterOptionsExample.slx")
19-35
19 Simulink Mask Editor
19-36
Specify Data Types for an Edit Parameter Using Data Type Parameter
The block DataTypeStr is masked and the required parameters are created. Follow these steps if
you want to create a similar model.
2. Create an edit parameter Gain, a min parameter Minimum, a max parameter Maximum, and a data
type parameter DataTypeStrParameter.
3. To specify the allowed data types and minimum and the maximum values for the Gain parameter,
select Data Type parameter in the Parameter pane and then double-click Type options in the
Property Editor pane. The type options editor opens. The type options editor has these tabs that you
can use to specify data types for the selected parameter:
19-37
19 Simulink Mask Editor
• Inherit rules — Specify inheritance rules for determining the data types. The inheritance rules
are grouped under three categories: Common Simulink rules, Custom rules, and Advanced
Simulink rules. The Advanced rules section allows you to inherit rules from the blocks such as
Lookup table, Constant, and Gain. For example, breakpoint data, constant value, gain, table data,
logic data, accumulator, product output, and Simulink. It also allows you to have same word length
as input and have same data types for all ports. The Custom rules section lists any custom
inheritance rules registered on the MATLAB™ search path. For definitions of some Inheritance
rules, see “Data Type Inheritance Rules”.
• Built-in types — Specify one or more built-in Simulink data types, such as double or single.
For more information, see “Data Types Supported by Simulink”.
19-38
Specify Data Types for an Edit Parameter Using Data Type Parameter
• Fixed-point — Specify the scaling and signed modes for a fixed-point data type. For more
information, see “Specifying a Fixed-Point Data Type”.
• User-defined — Specify a bus object, an enumerated data type, or a string. For more information,
see “Specify an Enumerated Data Type”.
• Associations — Associate a data type parameter with an Edit parameter. Select the a min
parameter Minimum, a max parameter Maximum in Design minimum and Design maximum to
associate the minimum and maximum parameter to the edit parameter Gain parameter.
19-39
19 Simulink Mask Editor
Note: Setting the acceptable datatypes through the data type parameter does not set the signal
attribute or output data type for the associated edit parameter. Explicitly set the data type associated
with the edit parameter directly on the underlying block of the masked subsystem that uses the edit
parameter.
maskObj = Simulink.Mask.get(gcb);
maskObj.addParameter('Name','Gain', 'Type','edit');
maskObj.addParameter('Name','minimum', 'Type','min');
maskObj.addParameter('Name','maximum', 'Type','max');
3. Add a data type parameter and associate it to the edit parameter Gain.
maskObj.addParameter('Name','DataType',...
'Type','unidt({a=DataType|Min|Max|Gain}{i=Inherit: auto|Inherit:Inherit via internal rule}{b=doub
Where, Type displays the values specified for the DataType parameter and has these definitions:
• Inherit rules are defined by i and its corresponding value is Inherit: Same as first input.
• Built-in types are defined by b and its corresponding value are double and single.
See Also
“Author Block Masks”
19-40
Design a Mask Dialog Box
This example shows how to create a mask dialog box using the Parameters & Dialog pane of the Mask
Editor. When you mask a block, you encapsulate the details of the block logic and create a custom
interface for the block.
Consider this model containing a masked Subsystem block called AC System. The AC System block
contains an air conditioning system. For more on masking subsystems, see “Create a Simple Mask”.
model = 'slexMaskACSystemExample';
%open the model
open_system(model);
To open the Mask Editor, right-click the AC System block, then select Mask > Edit Mask.
In the Mask Editor, use the Parameters & Dialogs pane to add controls on the mask dialog box and
manage the mask dialog box layout. Select items from the Controls section to add parameters to the
mask dialog box. Use the Property editor section to edit parameter properties.
19-41
19 Simulink Mask Editor
For example, in the Controls panel, click Collapsible Panel. Observe that a collapsible panel
container is now added in the Dialog box section. In the Prompt column, type a value to be
displayed on the mask dialog box. For example, Manufacturer's Information. The Name column
gets populated automatically when a you add a control. You can change this value. You can change
the name and the type of this parameter from the Property editor.
Edit the properties of collapsible panel in the Property editor. Click Preview to view the mask dialog
box as you build it.
19-42
Design a Mask Dialog Box
Similarly, you can add and configure various controls from the Mask Editor to build the mask dialog
box.
Observe the mask layout. Containers like group boxes, collapsible panels, and tabs group the controls
together. Here, yellow represents Group Box, pink represents Tab, and green represents the
Collapsible Panel.
19-43
19 Simulink Mask Editor
The Button controls type is used to create the Power On button on the mask dialog box. To manage
the button placement, apply the Horizontal Stretch property. You can also add callback code to
execute when the button is pressed. You can view a sample callback code for the Button controls
type in the attached model.
The collapsible panel for Manufacturer's information contains Text and Hyperlink control types.
19-44
Design a Mask Dialog Box
The General Controls section contains tabs to segregate and categorize information under Main
Controls and Ancillary Controls. The Main Controls tab uses Dials and Slider to accept inputs
19-45
19 Simulink Mask Editor
for air conditioner parameters. You can edit the property of dial and slider in the property editor
section of Mask Editor to place them horizontally or vertically.
The Ancillary Controls use Popup, Check Box, and Radio Buttons.
The Advanced Controls section is a collapsible panel that contains spinbox, minimum, and maximum
parameters to accept inputs.
19-46
Design a Mask Dialog Box
See Also
More About
• “Mask Editor Overview” on page 19-2
19-47
19 Simulink Mask Editor
This example shows the various mask parameters and their functionalities.
open_system("slexMaskParameterOptionsExample")
19-48
Types of Mask Parameters
19-49
19 Simulink Mask Editor
Mask Callback
This example shows the conditions that trigger the execution of various mask callbacks.
open_system("slexMaskCallbacksExample")
19-50
Mask Callback
19-51
19 Simulink Mask Editor
This example shows the various options available for designing the mask dialog box using the layout
options.
open_system("slexMaskLayoutOptionsExample.slx")
19-52
20
Specify whether you want to manually map tasks (explicit mapping) or use the rate-based tasks.
Settings
Default: On
On
Enable manual mapping of tasks to blocks.
Off
Allow implicit rate-based tasks.
Command-Line Information
Parameter: ExplicitPartitioning
Value: 'on' | 'off'
Default: 'off'
Dependencies
• Allows custom task-to-block mappings. The node name changes to Tasks and Mapping label and
the icon changes.
• Disables the Automatically handle rate transition for data transfer check box on the Data
Transfer pane.
• Causes the software to ignore the task-to-block mappings. The node name changes to (Ignored)
Tasks and Mapping.
• Enables the Automatically handle rate transition for data transfer check box on the Data
Transfer pane.
20-2
Data Transfer
Data Transfer
In this section...
“Data Transfer” on page 20-3
“Periodic signals” on page 20-3
“Continuous signals” on page 20-3
“Extrapolation method” on page 20-4
Data Transfer
Periodic signals
Settings
Dependency
This parameter is enabled if the Enable explicit task mapping to override implicit rate-based
tasks check box on the Concurrent Execution pane is selected.
Continuous signals
Settings
20-3
20 Concurrent Execution Window
Dependency
This parameter is enabled if the Enable explicit task mapping to override implicit rate-based
tasks check box on the Concurrent Execution pane is cleared.
Extrapolation method
Settings
Default: None
None
Do not use any extrapolation method for task transitions.
Zero Order Hold
User zero order hold extrapolation method for task transitions.
Linear
User linear extrapolation method for task transitions.
Quadratic
User quadratic extrapolation method for task transitions.
Dependency
This parameter is enabled if the Enable explicit task mapping to override implicit rate-based
tasks check box on the Concurrent Execution pane is selected.
20-4
Software Node
Software Node
Software Node
Name
Settings
Default: CPU
• Alternatively, enter a unique character vector to identify the software node. This value must be a
valid MATLAB variable.
20-5
20 Concurrent Execution Window
Hardware Node
Hardware Node
Name
Settings
Default: FPGAN
• Alternatively, enter a unique character vector to identify the hardware node. This value must be a
valid MATLAB variable.
Settings
Default: 33
Color
Settings
20-6
Periodic Trigger
Periodic Trigger
In this section...
“Periodic Trigger” on page 20-7
“Name” on page 20-7
“Periodic Trigger” on page 20-7
“Color” on page 20-7
“Template” on page 20-8
Periodic Trigger
Name
Settings
Default: Periodic
• Alternatively, enter a unique character vector to identify the periodic task trigger configuration.
This value must be a valid MATLAB variable.
Periodic Trigger
Settings
Default:
Color
20-7
20 Concurrent Execution Window
Settings
Default: Blue
• Click the color picker icon to select a color for the periodic trigger icon.
Template
Specify the XML-format custom architecture template file that code generation properties use for the
task, periodic trigger or aperiodic triggers.
Settings
Default: None
20-8
Task
Task
In this section...
“Task” on page 20-9
“Name” on page 20-9
“Period” on page 20-9
“Color” on page 20-9
Task
Specify concurrent execution tasks. You can add tasks for periodic and interrupt-driven (aperiodic)
tasks.
Name
Settings
Default: Task
• Alternatively, enter a unique character vector to identify the periodic task trigger configuration.
This value must be a valid MATLAB variable.
Period
Settings
Default: 1
Minimum: 0
Tip
You can parameterize this value by using MATLAB expression character vectors as values.
Color
20-9
20 Concurrent Execution Window
Settings
Default: Blue
• Click the color picker icon to select a color for the task icon.
Tips
The task icon appears on the top left of the Model block. It indicates the task to which the Model
block is assigned.
• As you add a task, the software automatically assigns a color to the task icon, up to six colors.
When the current list of colors is exhausted, the software reassigns previously used colors to the
new tasks, starting with the first color assigned.
• If you select a different color for an icon and then use the software to automatically assign colors,
the software assigns a preselected color.
20-10
Aperiodic Trigger
Aperiodic Trigger
In this section...
“Aperiodic Trigger” on page 20-11
“Name” on page 20-11
“Color” on page 20-11
“Aperiodic trigger source” on page 20-12
“Signal number [2,SIGRTMAX-SIGRTMIN-1]” on page 20-12
“Event name” on page 20-13
Aperiodic Trigger
Name
Settings
Default: Interrupt
• Enter a unique character vector to identify the interrupt-driven task configuration. This value
must be a valid MATLAB variable.
Color
Settings
Default: Blue
• Click the color picker icon to select a color for the interrupt icon.
Tips
The interrupt icon appears on the top left of the Model block. It indicates the task to which the Model
block is assigned.
• As you add an interrupt, the software automatically assigns a color to the interrupt icon, up to six
colors. When the current list of colors is exhausted, the software reassigns previously used colors
to the new interrupts, starting with the first color assigned.
20-11
20 Concurrent Execution Window
• If you select a different color for an icon and then use the software to automatically assign colors,
the software assigns a preselected color.
Settings
Dependencies
Event name
Settings
Default: 2
Minimum: 2
Maximum: SIGRTMAX-SIGRTMIN-1
Dependencies
Aperiodic trigger source > Posix signal (Linux/VxWorks 6.x) enables this parameter.
20-12
Aperiodic Trigger
Event name
Settings
Default: ERTDefaultEvent
Dependencies
20-13
20 Concurrent Execution Window
System Tasks
System Tasks
20-14
System Task
System Task
In this section...
“System Task” on page 20-15
“Name” on page 20-15
“Period” on page 20-15
“Color” on page 20-16
System Task
Name
Settings
Default: DiscreteN
Tip
To change the name, period, or color of this task, right-click the task node and select Convert to
editable periodic task.
Period
Settings
Default: 1
Minimum: 0
Tip
• To change the name, period, or color of this task, right-click the task node and select Convert to
editable periodic task.
20-15
20 Concurrent Execution Window
Color
Settings
Default: Blue
Tips
The task icon appears on the top left of the Model block. It indicates the task the Model block is
assigned to.
• To change the name, period, or color of this task, right-click the task node and select Convert to
editable periodic task.
20-16
System Aperiodic Trigger
In this section...
“System Aperiodic Trigger” on page 20-17
“Name” on page 20-17
“Color” on page 20-17
Name
Settings
Default: Asynchronous
Tip
To change the name or color of this task, right-click the task node and select Convert to editable
aperiodic trigger.
Color
Tips
The task icon appears on the top left of the Model block. It indicates the task the Model block is
assigned to.
• To change the name or color of this task, right-click the task node and select Convert to editable
aperiodic task.
20-17
20 Concurrent Execution Window
Profile Report
In this section...
“Profile Report Pane” on page 20-18
“Number of time steps” on page 20-18
Settings
Default: 100
20-18
21
In Model-Based Design for system development, you might have to use multiple design alternatives
for components in the system. For example, in a model that represents an automobile, you might have
several exhaust temperature sensors supplied by different vendors. Throughout the development life
cycle, from requirements to deployment, you may need to switch between these design choices.
You might also model systems that represent a product line such as cars, aeroplanes, and
communication systems. Product lines are created by adding variation points to a system. For
example, vehicles in a product line of passenger cars can have multiple variation points such as fuel
consumption, motor type, or engine size.
Instead of designing multiple models to represent all possible variants, you can use variant elements
in Simulink to represent all the variations in a single model. For an introduction to variants in
Simulink, see “What Are Variants and When to Use Them”.
Variant Manager
Variant Manager is a tool that allows you to visualize the model hierarchy and centrally manage the
usage of variant elements such as variant blocks, variant parameters, and variant transitions across
the hierarchy.
The tool is available as a support package named Variant Manager for Simulink with these main
capabilities:
• Variant Manager — Visualize the model hierarchy, manage the usage of variant elements across
the hierarchy, and create and manage variant configurations.
• Variant Reducer — Generate a reduced model that contains only selected variant configurations.
• Variant Analyzer — Compare and contrast variant configurations to identify errors or
inconsistencies.
21-2
Variant Manager for Simulink
Variant Manager
Gene rate
Visualize and
Reduced Model
Compare Variant
for Specific Variant
Configu rations
Configu rations
Explore
• Model hie rarchy Manage Variant
Create and Auto Gene rate Run Simulations and
• Variant pa rameters Configu rations
Activate Variant Variant Tests Using Variant
view Using Variant
Configu rations Configu rations Configu rations
Configu ration Object
•Stateflow variant
transitions view
21-3
21 Variant Manager for Simulink
1 In Simulink, on the Modeling tab, open the Design section and click Variant Manager. You
can also use any of the alternate methods to open Variant Manager.
2 In the Install Variant Manager for Simulink dialog box, click Add. This action opens the
Variant Manager for Simulink page in Add-On Explorer from where you can install the add-on.
• Use Add-On Explorer:
1 In MATLAB, on the Home tab, in the Environment section, click Add-Ons and then select
Get Add-ons.
2 In the Add-On Explorer, find and click the Variant Manager for Simulink support package, and
click Install.
When you execute any Variant Manager related APIs from the MATLAB Command-Line, the APIs
return an error with a hyperlink to launch the installer.
For information on the behavior changes in the support package, see “Compatibility Considerations
When Using Variant Manager for Simulink Support Package”.
• Right-click the variant badge icon on any variant block and select Open in Variant Manager.
• On the Modeling tab, open the Design section and click Variant Manager.
• Right-click a variant block and select Variant > Open in Variant Manager.
• Select a variant block, for example, a Variant Subsystem block, and then in the Variant
Subsystem tab of the Simulink toolstrip select Variant Manager.
• Click Open block in Variant Manager available on the variant block’s Block Parameter dialog
box.
Tip You can also open Variant Manager without a Simulink model to manage variant configurations
and constraints. See “Use Variant Manager Without Simulink Model” on page 21-15.
21-4
Variant Manager for Simulink
openExample("simulink_variants/VariantManagementInSimulinkExample","supportingFile","slexVariantM
• You can change the layout of the window according to your preference. To move a pane, click at
the top of the pane and drag.
• You can minimize unused panes. When you want to work on a minimized pane again, restore it to
stop it from collapsing automatically.
• The Getting Started pane appears on the right side of the window by default and provides a
quick overview of the common workflows.
21-5
21 Variant Manager for Simulink
•
You can use the Help button in the top right corner of the Variant Manager window to access
the documentation.
• The Diagnostics pane appears at the bottom of the window by default and displays messages,
errors, and warnings related to the actions performed from the Variant Manager.
The model hierarchy table presents a tree view of the model where each node represents a block or a
referenced component. You can expand the nodes and navigate the hierarchy.
21-6
Variant Manager for Simulink
Note When you open the Variant Manager for a top-level model, variant elements inside referenced
components such as Model blocks, Subsystem Reference blocks, and libraries are not loaded. The
referenced components are loaded and activated only when you explicitly activate the model or
expand them in the model hierarchy.
The Component Configurations tab is not shown by default. To open the tab, click the Show
Component Configurations button in the Control Variables section of a selected variant
configuration.
21-7
21 Variant Manager for Simulink
21-8
Variant Manager for Simulink
These images show the views for the Choice and Bank options for a
model.
By Choice:
By Bank:
Search
Use the Search in model hierarchy view button to search for any
element in the hierarchy.
21-9
21 Variant Manager for Simulink
21-10
Variant Manager for Simulink
• Open and Highlight Block: Opens the selected block in the model
and highlights it. This provides traceability to the model.
• Open Model: Opens the selected model or referenced model.
• Open As Top Model: Opens the selected referenced model as a top
model in a separate window.
• Open Referenced Subsystem: Opens the selected referenced
subsystem in a separate window.
• Open Block Parameters: Opens the block parameter dialog box
for the selected block. You can modify the parameter values.
• Open Parent Block Parameters: Opens the block parameter
dialog box for the parent block of the selected block. You can
modify the parameter values.
• Open and Highlight Paired Block: For the selected Variant Start
or Variant End block, highlight the corresponding paired block in
the model.
• Open Paired Block Parameters: For the selected Variant Start or
Variant End block, open the block parameter dialog box of the
corresponding paired block.
• Set as Label Mode Active Choice: Sets the selected choice of
Variant Subsystem, Variant Sink, or Variant Source blocks as active
choice. This option is available only if the Variant Control mode
block parameter is set to label.
• Edit Simulink.VariantVariable: Open the
Simulink.VariantVariable dialog box from where you can edit
the selected variant parameter.
• Open and Highlight Chart: Open the selected Stateflow chart and
highlight it in the model.
• Open and Highlight Transition: Open the Stateflow chart and
highlight the selected transition.
• Open Chart Parameters: Open the Chart properties dialog box of
the selected Stateflow chart.
• Open Parent Chart Parameters: Open the Chart properties
dialog box of the parent Stateflow chart for the selected transition.
Filter variant blocks by their Use the View list in the Blocks tab of the model hierarchy.
Variant control mode
21-11
21 Variant Manager for Simulink
•
variable usage — Use the Show previous variable usage and
21-12
Variant Manager for Simulink
A variant configuration represents a combination of variant choices across the model hierarchy. From
Variant Manager, you can:
For steps to create a variant configuration, see “Create and Activate Variant Configurations”.
You can obtain and use model compilation information in Variant Manager to produce more accurate
results for user workflows such as importing control variables to a configuration, activation, and
identifying variant parameters used by the model hierarchy. To obtain model compilation information,
click Update Model in the Variant Manager toolstrip or use the
Simulink.VariantManager.updateModel function. Variant Manager uses the compilation
information subsequently in these scenarios:
• If a model defines variant control variables in the model or mask workspaces, Variant Manager
supports them in these operations:
• When you import variant control variables to a configuration, the operation adds any control
variables defined in the mask workspace and model workspace to the configuration. When you
activate such a configuration, activation results are based on the mask and model workspace
control variable definitions in the configuration.
• If the mask initialization code of a block defines variant control variables, Variant Manager
verifies that the definitions of these variables within a configuration are consistent with those
in the mask initialization code.
• The variant control variable usage option shows the variable usage in the model hierarchy
pane based on the model or mask workspace in which the variable is defined.
21-13
21 Variant Manager for Simulink
• If a model's InitFcn callback defines variant control variables in the base workspace or in a
linked data dictionary, importing control variables adds these variables to a configuration. Variant
Manager verifies that the definitions of these variables within a configuration are consistent with
the InitFcn callback specifications.
• Variant Manager identifies the variant parameters used by the model hierarchy. It then considers
only these parameters for subsequent activation and importing of variant control variable
operations.
• Once Variant Manager has the compilation information, it reuses the information until you update
the model again.
Creating all possible variant configurations for a model manually can be time consuming. You must
activate them individually to check if they are valid and if they satisfy necessary constraints. Instead,
you can automatically generate variant configurations for a model using Variant Manager, which
enables you to:
• Consider all possible combinations of variant control variables while creating configurations.
• Specify the value range that must be considered for each control variable, to generate only the
required subset of configurations.
• Specify preconditions to restrict the configurations to generate, and optionally export the
preconditions as constraints.
• Automatically validate generated configurations to identify invalid cases.
• Generate valid, valid and unique, or all configurations.
• Export the configurations to a variant configuration data object. You can export valid
configurations for which the model compiles successfully or all configurations including invalid
ones.
For detailed steps to generate variant configurations, see “Generate Variant Configurations
Automatically”.
• Specify a name for the variant configuration data object for the model.
• Apply the changes made to the variant configuration data object from Variant Manager to the base
workspace or data dictionary used by the model.
• Export the variant configuration data object to a MAT-file or MATLAB script file.
• Import a variant configuration data object from a MAT-file or MATLAB script file into Variant
Manager.
• Reload the object from the base workspace or data dictionary used by the model. This allows you
to revert the changes that are not yet exported to the data sources used by the model.
21-14
Variant Manager for Simulink
When you export the variant control variables in a variant configuration or when you activate a
variant configuration, the control variables are pushed to the data sources where the variables are
stored. Reloading the variant configuration object from Variant Manager does not revert these
changes.
• Disassociate the variant configuration data object from the model.
For an example that shows how to perform these actions from Variant Manager, see “Save and Reuse
Variant Configurations Using Variant Configuration Data Object”.
The Simulink.VariantConfigurationData class has methods that enable you to add or remove
variant configurations, constraints, and control variables.
When you run simulations for your variant model programmatically, you can specify the variant
configuration to apply to the model during simulation. For simulation functions such as sim, parsim,
and batchsim, you can set the VariantConfiguration property in the
Simulink.SimulationInput object. For an example, see “Run Simulations for Variant Models
Using Variant Configurations”.
You can specify the variant configuration to use when running a test case or a test iteration on a
model from Simulink Test Manager or by using the Simulink Test™ programmatic interface. For an
example, see “Run Tests for Variant Models Using Variant Configurations”.
You can define and edit variant configurations and constraints without a Simulink model. To use this
workflow, create a Simulink.VariantConfigurationData object in the base workspace or in the
Configurations section of a data dictionary. Open Variant Manager by double-clicking the object.
From this dialog box, you can modify variant configurations, control variables, and constraints in the
variant configuration object. The Import control variables from model data source button allows
you to import variant control variables of type Simulink.VariantControl defined in the base
workspace or a data dictionary linked to the model even if the variant control is not yet used by the
model. In top-down variant management workflows where you may need to define variant
configurations before setting up variation points in the model, this operation allows you to access the
variant controls that you have already defined in a data source from Variant Manager.
21-15
21 Variant Manager for Simulink
To open Variant Reducer, in the Variant Manager toolstrip, in the APPS section, click Variant
Reducer.
Variant Reducer performs these high-level operations during the reduction process:
• Removes inactive model components based on the variant configurations that you choose to retain
in the reduced model.
• Removes or modifies model components such as blocks, variant parameter objects, masks, model
references, subsystem references, libraries, dependent files, and variables in the input model to
create the reduced model.
• Packages the reduced model and related artifacts into a user-specified output folder.
21-16
Variant Manager for Simulink
• Generates a detailed summary of the reduction process that helps you to analyze these changes.
You can analyze the named variant configurations created for a model or perform an analysis after
setting values for the variant control variables. The variant analysis report generated by the app
helps you to:
• Compare different variant configurations for a model to understand the common and differing
model elements used between them.
• Check if all variant choices have been activated at least once and whether the model is covered
completely for simulation and code generation.
• Verify if the active, implemented model is different between different variant configurations.
• Find the dependent model artifacts such as referenced models and libraries used by a particular
variant configuration.
Button Description
Add a variant configuration.
Control Variables
This table lists the icons used to represent different types of control variables.
Simulink.Parameter or AUTOSAR.Parameter
21-17
21 Variant Manager for Simulink
Button Description
Import control variables from the entire model
hierarchy by default. To import variant control
variables of type Simulink.VariantControl
defined in the base workspace or a data
dictionary linked to the model even if the variant
control is not yet used by the model, click the
down arrow on the button and select Import
control variables from model data
source.
Edit Simulink.Parameter or
AUTOSAR.Parameter control variables. This
option gets activated when the selected control
variable is one of these types.
21-18
Variant Manager for Simulink
Icon Purpose
This icon next to a referenced model in the Component
Configurations view indicates that the referenced component has
its own predefined variant configurations.
Icon Element
Model block with Simulation mode set to Normal
Subsystem block
Variant Subsystem block with Allow zero active variant controls selected and
Variant activation time set to runtime.
Variant Subsystem block with Allow zero active variant controls selected and
Variant activation time set to update diagram.
Variant Subsystem block with Allow zero active variant controls selected and
Variant activation time set to update diagram analyze all choices.
21-19
21 Variant Manager for Simulink
Icon Element
Variant Subsystem block with Allow zero active variant controls selected and
Variant activation time set to code compile.
Variant Subsystem block with Variant control mode set to label and an
active variant choice selected from the Label mode active choice option.
Variant Subsystem block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram.
Variant Subsystem block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram analyze
all choices.
Variant Subsystem block with Propagate conditions outside of variant
subsystem and Variant activation time set to update diagram.
Variant Subsystem block with Propagate conditions outside of variant
subsystem and Variant activation time set to update diagram analyze
all choices.
Variant Subsystem block with Propagate conditions outside of variant
subsystem and Variant activation time set to code compile.
Variant Subsystem block with Propagate conditions outside of variant
subsystem and Variant activation time set to startup.
Variant Subsystem block with Propagate conditions outside of variant
subsystem option selected. Also, Variant control mode is set to label and an
active variant choice is selected from the Label mode active choice option.
Inline Variants Block (Variant Source and Variant Sink) with Allow zero active
variant control option selected.
Inline Variants Block (Variant Source and Variant Sink) with Variant control
mode set to label and an active variant choice selected from the Label mode
active choice option.
Inline Variants Block (Variant Source and Variant Sink) with Variant control
mode set to sim codegen switching and Variant activation time set to
update diagram.
Inline Variants Block (Variant Source and Variant Sink) with Variant control
mode set to sim codegen switching and Variant activation time set to
update diagram analyze all choices.
Inline Variants Block (Variant Source and Variant Sink) with Variant activation
time set to update diagram.
Inline Variants Block (Variant Source and Variant Sink) with Variant activation
time set to update diagram analyze all choices.
Inline Variants Block (Variant Source and Variant Sink) with Variant activation
time set to code compile.
Inline Variants Block (Variant Source and Variant Sink) with Variant activation
time set to startup.
Inline Variants Block (Variant Source and Variant Sink) with Allow zero active
variant control and Variant activation time set to update diagram.
21-20
Variant Manager for Simulink
Icon Element
Inline Variants Block (Variant Source and Variant Sink) with Allow zero
active variant control and Variant activation time set to update diagram
analyze all choices.
Inline Variants Block (Variant Source and Variant Sink) with Allow zero active
variant control and Variant activation time set to code compile.
Inline Variants Block (Variant Source and Variant Sink) with Allow zero active
variant control and Variant activation time set to startup.
Variant Assembly Subsystem block with Variant control mode set to label.
Variant Start block with Variant activation time set to update diagram
analyze all choices.
Variant Start block with Variant activation time set to code compile.
Variant Start block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram.
21-21
21 Variant Manager for Simulink
Icon Element
Variant Start block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram analyze
all choices.
Variant End block with Variant activation time set to update diagram.
Variant End block with Variant activation time set to update diagram
analyze all choices.
Variant End block with Variant activation time set to code compile.
Variant End block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram.
Variant End block with Variant control mode set to sim codegen
switching and Variant activation time set to update diagram analyze
all choices.
Initialize Function block
Note For variant blocks with Variant activation time set to Inherit from
Simulink.VariantControl, the variant manager activation process updates the variant badge for
the block in the model hierarchy to indicate the activation time that is computed from the
corresponding Simulink.VariantControl variables.
21-22
Variant Manager for Simulink
Limitations
• Variant Manager reports errors and warnings related to variant elements only.
• The model hierarchy table does not show protected referenced models.
• Variant Manager constraints are evaluated based on the values of variant control variables defined
in the base workspace or data dictionaries linked to the model.
• Variant Manager constraints are not validated post compilation, for example, at startup variant
activation time.
• For a variant block, you can define variant configurations only if the Variant control mode
parameter of the block is set to expression.
• Variant Manager does not support workflows such as activation, viewing, or importing of control
variables from variations inside a protected model. These variations are present when variant
control variables of variant blocks with startup activation time are specified as
TunableParameters while creating the protected model.
• Variant Manager does not support creating or deleting variant parameter objects from the
Variant Parameters tab.
See Also
Simulink.VariantConfigurationData | Simulink.VariantConfigurationAnalysis
More About
• “Compatibility Considerations When Using Variant Manager for Simulink Support Package”
• “Variant Configurations”
• “What Are Variants and When to Use Them”
• “Simulink Variant Examples”
• “Manage, Configure, Reduce, and Analyze System Variants with Variant Manager for Simulink”
• “V-Model for System Development with Simulink Variants”
21-23
22
The Model Parameter Configuration dialog box allows you to declare specific tunable parameters
when you set Default parameter behavior to Inlined. The parameters that you select appear in
the generated code as tunable parameters. For more information about Default parameter
behavior, see Default parameter behavior (Simulink Coder).
To declare tunable parameters, use Simulink.Parameter objects instead of the Model Parameter
Configuration dialog box. See “Create Tunable Calibration Parameter in the Generated Code”
(Simulink Coder).
Note Simulink Coder software ignores the settings of this dialog box if a model contains references
to other models. However, you can still generate code that uses tunable parameters with model
references, using Simulink.Parameter objects. See “Create Tunable Calibration Parameter in the
Generated Code” (Simulink Coder).
Source list
Displays a list of workspace variables. The options are:
• MATLAB workspace — Lists all variables in the MATLAB workspace that have numeric values.
• Referenced workspace variables — Lists only those variables referenced by the model.
22-2
Model Parameter Configuration Dialog Box
Refresh list
Updates the source list. Click this button if you have added a variable to the workspace since the last
time the list was displayed.
Add to table
Adds the variables selected in the source list to the adjacent table of tunable parameters.
New
Defines a new parameter and adds it to the list of tunable parameters. Use this button to create
tunable parameters that are not yet defined in the MATLAB workspace.
Note This option does not create the corresponding variable in the MATLAB workspace. You must
create the variable yourself.
Storage class
Used for code generation. For more information, see “Choose Storage Class for Controlling Data
Representation in Generated Code” (Simulink Coder).
See Also
Related Examples
• “Model Configuration Parameters: Code Generation Optimization” (Simulink Coder)
• “How Generated Code Stores Internal Signal, State, and Parameter Data” (Simulink Coder)
22-3
23
Parameter Description
Model Advisor configuration file Specifies a Model Advisor configuration file for
the model.
Show Model Advisor edit-time checks Enables Model Advisor edit-time checks for the
model.
23-2
Model Advisor configuration file
Description
Specify a Model Advisor configuration file for the model.
Settings
"" (default) | string
Model Advisor can use a configuration file to determine which Model Advisor and edit-time checks to
run. For information on how to create your own custom Model Advisor configuration files, see “Use
Model Advisor Configuration Editor to Customize Model Advisor” (Simulink Check).
You can specify the Model Advisor configuration file by using one of these approaches:
• Use the Model Advisor. In the Model Advisor, in the Configure section, click Load > Associate
Configuration to Model. When you click Associate Configuration to Model, the Model
Advisor opens the Configuration Parameters for your model and sets the configuration parameter
ModelAdvisorConfigurationFile to the full file path of the current configuration file. Click
OK to accept the current configuration file as the configuration file for your model.
• Enter the name of your Model Advisor configuration file in this field.
• Specify a configuration at the command line by using the function
ModelAdvisor.setModelConfiguration.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
Safety precaution No impact
Programmatic Use
Parameter: ModelAdvisorConfigurationFile
Type: string
23-3
23 Model Advisor Parameters
Value: full file path for Model Advisor configuration file (JSON) saved with the Model Advisor
Configuration Editor in R2022a release or later
Default: ""
Version History
Introduced in R2022a
See Also
ModelAdvisor.getModelConfiguration | ModelAdvisor.setDefaultConfiguration |
ModelAdvisor.setModelConfiguration
Topics
“Check Model Compliance by Using the Model Advisor” (Simulink Check)
“Use Model Advisor Configuration Editor to Customize Model Advisor” (Simulink Check)
“Load and Associate a Custom Configuration with a Model” (Simulink Check)
23-4
Show Model Advisor edit-time checks
Description
Enable Model Advisor edit-time checking for the model.
Settings
"Off" (default) | "On"
On
The Model Advisor shows edit-time checks on the Simulink canvas while you edit your model. If
you edit the model when edit-time checking is enabled, the Model Advisor checks out a Simulink
Check™ license.
Off
The Model Advisor does not show edit-time checks on the Simulink canvas while you edit your
model.
You can use edit-time checking to check that a model complies with modeling guidelines or standards.
For information, see “Check Model Compliance Using Edit-Time Checking” (Simulink Check).
You can enable edit-time checking for your model by using one of these approaches:
• Navigate to the Model Advisor Configuration Parameters from the Simulink toolstrip for your
model. In the Debug tab, click Diagnostics > Edit-Time Checks. Select the check box for Edit-
Time Checks.
• In the Modeling tab, click Model Advisor > Edit-Time Checks. Select the check box for Edit-
Time Checks.
• Enable edit-time checking at the command line by using the function
edittime.setAdvisorChecking.
Use the function edittime.setAdvisorChecking to enable or disable edit-time checking for the
model.
Recommended Settings
Application Setting
Debugging No impact
Traceability No impact
Efficiency No impact
23-5
23 Model Advisor Parameters
Application Setting
Safety precaution No impact
Programmatic Use
Parameter: ShowAdvisorChecksEditTime
Type: string
Value: "On" | "Off"
Default: "Off"
Version History
Introduced in R2022a
See Also
edittime.getAdvisorChecking | edittime.setAdvisorChecking
Topics
“Check Model Compliance Using Edit-Time Checking” (Simulink Check)
23-6