0% found this document useful (0 votes)
21 views780 pages

3 Simulink Gui

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views780 pages

3 Simulink Gui

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 780

Simulink®

Graphical User Interface

R2024b
How to Contact MathWorks

Latest news: www.mathworks.com

Sales and services: www.mathworks.com/sales_and_services

User community: www.mathworks.com/matlabcentral

Technical support: www.mathworks.com/support/contact_us

Phone: 508-647-7000

The MathWorks, Inc.


1 Apple Hill Drive
Natick, MA 01760-2098
Simulink® Graphical User Interface
© COPYRIGHT 1990–2024 by The MathWorks, Inc.
The software described in this document is furnished under a license agreement. The software may be used or copied
only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form
without prior written consent from The MathWorks, Inc.
FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through
the federal government of the United States. By accepting delivery of the Program or Documentation, the government
hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer
software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014.
Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain
to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and
Documentation by the federal government (or other entity acquiring for or through the federal government) and shall
supersede any conflicting contractual terms or conditions. If this License fails to meet the government's needs or is
inconsistent in any respect with federal procurement law, the government agrees to return the Program and
Documentation, unused, to The MathWorks, Inc.
Trademarks
MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See
www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be
trademarks or registered trademarks of their respective holders.
Patents
MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for
more information.
Revision History
September 2007 Online only New for Simulink 7.0 (Release 2007b)
March 2008 Online only Revised for Simulink 7.1 (Release 2008a)
October 2008 Online only Revised for Simulink 7.2 (Release 2008b)
March 2009 Online only Revised for Simulink 7.3 (Release 2009a)
September 2009 Online only Revised for Simulink 7.4 (Release 2009b)
March 2010 Online only Revised for Simulink 7.5 (Release 2010a)
September 2010 Online only Revised for Simulink 7.6 (Release 2010b)
April 2011 Online only Revised for Simulink 7.7 (Release 2011a)
September 2011 Online only Revised for Simulink 7.8 (Release 2011b)
March 2012 Online only Revised for Simulink 7.9 (Release 2012a)
September 2012 Online only Revised for Simulink 8.0 (Release 2012b)
March 2013 Online only Revised for Simulink 8.1 (Release 2013a)
September 2013 Online only Revised for Simulink 8.2 (Release 2013b)
March 2014 Online only Revised for Simulink 8.3 (Release 2014a)
October 2014 Online only Revised for Simulink 8.4 (Release 2014b)
March 2015 Online only Revised for Simulink 8.5 (Release 2015a)
September 2015 Online only Revised for Simulink 8.6 (Release 2015b)
October 2015 Online only Rereleased for Simulink 8.5.1 (Release 2015aSP1)
March 2016 Online only Revised for Simulink 8.7 (Release 2016a)
September 2016 Online only Revised for Simulink 8.8 (Release 2016b)
March 2017 Online only Revised for Simulink 8.9 (Release 2017a)
September 2017 Online only Revised for Simulink 9.0 (Release 2017b)
March 2018 Online only Revised for Simulink 9.1 (Release 2018a)
September 2018 Online only Revised for Simulink 9.2 (Release 2018b)
March 2019 Online only Revised for Simulink 9.3 (Release 2019a)
September 2019 Online only Revised for Simulink 10.0 (Release 2019b)
March 2020 Online only Revised for Simulink 10.1 (Release 2020a)
September 2020 Online only Revised for Simulink 10.2 (Release 2020b)
March 2021 Online only Revised for Simulink 10.3 (Release 2021a)
September 2021 Online only Revised for Simulink 10.4 (Release 2021b)
March 2022 Online only Revised for Version 10.5 (Release 2022a)
September 2022 Online only Revised for Version 10.6 (Release 2022b)
March 2023 Online only Revised for Version 10.7 (Release 2023a)
September 2023 Online only Revised for Version 23.2 (R2023b)
March 2024 Online only Revised for Version 24.1 (R2024a)
September 2024 Online only Revised for Version 24.2 (R2024b)
Contents

Configuration Parameters Dialog Box


1
Model Configuration Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Model Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2
Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Simulink Configuration Parameters: Advanced


2

Solver Parameters
3
Solver Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

Data Import/Export Parameters


4
Model Configuration Parameters: Data Import/Export . . . . . . . . . . . . . . . 4-2

Math and Data Types


5
Math and Data Types Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

Diagnostics Parameters
6
Model Configuration Parameters: Diagnostics . . . . . . . . . . . . . . . . . . . . . . 6-2

v
Diagnostics Parameters: Sample Time
7
Model Configuration Parameters: Sample Time Diagnostics . . . . . . . . . . 7-2

Source block specifies -1 sample time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Multitask data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-5

Single task data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Programmatic Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-7

Multitask conditionally executed subsystem . . . . . . . . . . . . . . . . . . . . . . . 7-9


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-9
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-10

Tasks with equal priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-11

Enforce sample times specified by Signal Specification blocks . . . . . . . . 7-13


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-13

Exported tasks rate transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-15

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

Diagnostics Parameters: Data Validity


8
Model Configuration Parameters: Data Validity . . . . . . . . . . . . . . . . . . . . . 8-2

Data Validity Diagnostics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5


Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5
To get help on an option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-5

Signal resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-7

Division by singular matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-8

Underspecified data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Identify and Resolve Underspecified Data Types . . . . . . . . . . . . . . . . . . . 8-10
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-10
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-11

Simulation range checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-12

String truncation checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-14

vii
Wrap on overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-15
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-16

Saturate on overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-17

Underspecified dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19

Inf or NaN block output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-20
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-21

"rt" prefix for identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-22

Detect downcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-24

Detect overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-26
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-27

Detect underflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-30

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

Detect loss of tunability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-41

Detect read before write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-42
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-43

Detect write after read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-44
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-45

Detect write after write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-46
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-47

Multitask data store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-48

Duplicate data store names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-50

Diagnostics Parameters: Type Conversion


9
Model Configuration Parameters: Type Conversion Diagnostics . . . . . . . . 9-2

ix
Diagnostics Parameters: Connectivity
10
Model Configuration Parameters: Connectivity Diagnostics . . . . . . . . . . 10-2

Diagnostics Parameters: Compatibility


11
Model Configuration Parameters: Compatibility Diagnostics . . . . . . . . . 11-2

Compatibility Diagnostics Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3


Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3
To get help on an option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

Diagnostics Parameters: Model Referencing


12
Model Configuration Parameters: Model Referencing Diagnostics . . . . 12-2

Diagnostics Parameters: Stateflow


13
Model Configuration Parameters: Stateflow Diagnostics . . . . . . . . . . . . . 13-2

Hardware Implementation Parameters


14
Hardware Implementation Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-2

Hardware board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5


Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-5
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-6

Code Generation system target file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-7

Device vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8


Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8

x Contents
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-8
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-9

Device type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10


Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-10
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-12
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-21
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-22

Number of bits: char . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-23
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-24

Number of bits: short . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-25
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-26

Number of bits: int . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-27
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-28

Number of bits: long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-29
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-30

Number of bits: long long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31

xi
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-31
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-32

Number of bits: float . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-33

Number of bits: double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-34

Number of bits: native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-35
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-36

Number of bits: pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-37

Number of bits: size_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-39
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-40

Number of bits: ptrdiff_t . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-41
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-42

Largest atomic size: integer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43

xii Contents
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-43
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-44
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-44

Largest atomic size: floating-point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-45
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-46

Byte ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-47
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-48

Signed integer division rounds to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-49
Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-50
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-50
Recommended settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-50
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-50

Shift right on a signed integer as arithmetic shift . . . . . . . . . . . . . . . . . 14-51


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Dependency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
Recommended settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-51
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-52

Support long long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-53
See Also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-54

xiii
Model Referencing Parameters
15
Model Configuration Parameters: Model Referencing . . . . . . . . . . . . . . . 15-2

Simulation Target Parameters


16
Model Configuration Parameters: Simulation Target . . . . . . . . . . . . . . . . 16-2

Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-6
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-7

GPU acceleration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8

Enable custom code analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

Additional code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10

Include headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-12

Initialize code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13

Terminate code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14

xiv Contents
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14

Include directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-15

Source files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Tip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17

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

Compiler flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20

Linker flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21

Deterministic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-22

Specify by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-24

xv
Default function array layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-26

Undefined function and variable handling . . . . . . . . . . . . . . . . . . . . . . . 16-28


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-28
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-28
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-28
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-29

Simulate custom code in a separate process . . . . . . . . . . . . . . . . . . . . . 16-30


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-30
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-30
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-30
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-30

Automatically infer global variables as function interfaces . . . . . . . . . 16-32


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-32
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-32
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-32
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-32

Exception by function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-33


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-33
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-33
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-33
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-33
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-34

Import custom code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-35


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-35
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-35
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-36
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-36

Reserved names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37


Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37
Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37
Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37
Command-Line Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37
Recommended Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-37

Signal Properties Dialog Box


17
Data Transfer Options for Concurrent Execution . . . . . . . . . . . . . . . . . . . 17-2
Specify data transfer settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Data transfer handling option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2
Extrapolation method (continuous-time signals) . . . . . . . . . . . . . . . . . . . 17-2
Initial condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-2

xvi Contents
Simulink Preferences Window
18
Font Styles for Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2
Font Styles Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2

Simulink Mask Editor


19
Mask Editor Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Parameters & Dialog Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-2
Code Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-17
Icon Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-20
Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-29
Additional Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-30

Dialog Control Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-32


Moving Dialog Controls in the Dialog box . . . . . . . . . . . . . . . . . . . . . . . 19-32
Cut, Copy, and Paste Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-32
Delete Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-33
Error Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-33

Specify Data Types for an Edit Parameter Using Data Type Parameter
........................................................ 19-35

Design a Mask Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-41

Types of Mask Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-48

Mask Callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-50

Design Mask Dialog Box Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19-52

Concurrent Execution Window


20
Concurrent Execution Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2
Concurrent Execution Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-2
Enable explicit model partitioning for concurrent behavior . . . . . . . . . . . 20-2

Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3


Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3
Periodic signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3
Continuous signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-3
Extrapolation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-4

Software Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5


Software Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5

xvii
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-5

Hardware Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6


Hardware Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Clock Frequency [MHz] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-6

Periodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7


Periodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Periodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-7
Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-8

Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-9

Aperiodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11


Aperiodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-11
Aperiodic trigger source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-12
Signal number [2,SIGRTMAX-SIGRTMIN-1] . . . . . . . . . . . . . . . . . . . . . 20-12
Event name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-13

System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-14


System Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-14

System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15


System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-15
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-16

System Aperiodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17


System Aperiodic Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17
Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17
Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-17

Profile Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18


Profile Report Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18
Number of time steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20-18

Variant Manager for Simulink


21
Variant Manager for Simulink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2
Variant Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21-2

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

Model Parameter Configuration Dialog Box


22
Model Parameter Configuration Dialog Box . . . . . . . . . . . . . . . . . . . . . . . 22-2
Source list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-2
Refresh list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Add to table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Storage class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3
Storage type qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22-3

Model Advisor Parameters


23
Model Configuration Parameters: Model Advisor . . . . . . . . . . . . . . . . . . . 23-2
Model Advisor Pane Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2
To get help on an option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23-2

xix
1

Configuration Parameters Dialog Box


1 Configuration Parameters Dialog Box

Model Configuration Pane


In this section...
“Model Configuration Overview” on page 1-2
“Name” on page 1-2
“Description” on page 1-2
“Configuration Parameters” on page 1-3

Model Configuration Overview

View or edit the name and description of your configuration set.

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

Specify the name of your configuration set.

Settings

Default: Configuration (for Active configuration set) or Configuration Preferences (for


default configuration set).

Edit the name of your configuration set.

In the Model Configuration Preferences, the name of the default configuration is always
Configuration Preferences, and cannot be changed.

Description

Specify a description of your configuration set.

Settings

No Default

Enter text to describe your configuration set.

1-2
Model Configuration Pane

Configuration Parameters

No further help documentation is available for this parameter.

1-3
2

Simulink Configuration Parameters:


Advanced
2 Simulink Configuration Parameters: Advanced

Test hardware is the same as production hardware


Option to indicate whether same hardware used in test and production

Model Configuration Pane: Hardware Implementation

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

Test device vendor and type


Option to specify test hardware manufacturer and type

Model Configuration Pane: Hardware Implementation

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:

• Number of bits: char


• Number of bits: short
• Number of bits: int
• Number of bits: long
• Number of bits: long long
• Number of bits: float
• Number of bits: double
• Number of bits: native
• Number of bits: pointer
• Number of bits: size_t
• Number of bits: ptrdiff_t
• Largest atomic size: integer
• Largest atomic size: floating-point
• Byte ordering
• Signed integer division rounds to
• Shift right on a signed integer as arithmetic shift
• Support long long

Whether you can modify the value of a device-specific parameter varies according to device type.

Settings
Intel, x86–64 (Windows64) | ...

Select one of these device vendors:

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

• SoC (ARM CortexA)

Analog Devices® options:

• ADSP–CM40x (ARM Cortex-M)


• Blackfin
• SHARC
• TigerSHARC

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

Texas Instruments® options:

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

• Hardware properties have default initial values.


• You cannot change parameters that have only one possible value.
• Parameters that have more than one possible value provide a list of valid values.

The table lists values for each 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 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).

set_param(mdl,"TargetHWDeviceType","Intel->x86->64 (Linux 64)")


• If you have a Simulink Coder™ license, you can add to the set of values available for the Device
vendor and Device type parameters. For more information, see “Register New Hardware
Devices” (Simulink Coder).

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

Number of bits: char


Character bit length for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: short


Bit length of C short data type for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: int


Bit length of C int data type for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: long


Bit length of C long data type for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: long long


Bit length of C long long data type for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: float


Bit length of C float data type for test hardware

Model Configuration Pane: Hardware Implementation

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

The bit length for float data is always 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

Number of bits: double


Bit length of C double data type for test hardware

Model Configuration Pane: Hardware Implementation

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

The bit length for double data is always 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

Number of bits: native


Native word length for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: pointer


Pointer bit length for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: size_t


size_t bit length for test hardware

Model Configuration Pane: Hardware Implementation

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

Number of bits: ptrdiff_t


ptrdiff_t bit length for test hardware

Model Configuration Pane: Hardware Implementation

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

Largest atomic size: integer


Largest integer data type supported for atomic loading and storage on test hardware

Model Configuration Pane: Hardware Implementation

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

Largest atomic size: floating-point


Largest floating-point data type supported for atomic loading and storage on test hardware

Model Configuration Pane: Hardware Implementation

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

Type: string | character vector


Values: 'Float' | 'Double' | 'None'
Default: 'Float'

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

Model Configuration Pane: Hardware Implementation

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

Signed integer division rounds to


How test hardware compiler rounds signed integer division results

Model Configuration Pane: Hardware Implementation

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.

Numerato Denomina Exact Result Result with Result with Undefined


r tor Quotient with Zero Floor Rounding
Rounding Rounding
33 4 8.25 8 8 8
-33 4 -8.25 -8 -9 -8 or -9
33 -4 -8.25 -8 -9 -8 or -9
-33 -4 8.25 8 8 8 or 9

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

Shift right on a signed integer as arithmetic shift


How the test hardware compiler handles sign bit for right shift on signed integer

Model Configuration Pane: Hardware Implementation

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.

The parameter affects only code generation.

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

Type: string | character vector


Values: 'on' | 'off'
Default: 'on'

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

Support long long


Test hardware C compiler support for C long long data type

Model Configuration Pane: Hardware Implementation

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.

This parameter enables Number of bits: long long.


off
The C compiler for the test hardware does not support the C long long data type and disables
use of the long long data type on the test hardware.

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

Hardware Implementation Options (Simulink Coder)


Number of bits: long long
“Hardware Implementation Pane” on page 14-2

2-49
2 Simulink Configuration Parameters: Advanced

Allowed unit systems


Option to specify supported unit systems for model

Model Configuration Pane: Diagnostics

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.

• To allow all unit systems, select Allow all unit systems.


• To specify which unit systems to allow, clear Allow all unit systems. Then, select the name of a
unit system and click Allow or Disallow to move that unit system between the allowed and
disallowed unit systems lists. When you specify a unit from a disallowed unit system, the software
returns a warning.

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:

• SI — International system of units


• SI (extended) — Extended international system of units
• English — English system of units
• CGS — Centimeter-gram-second system of units

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

Units inconsistency messages


Diagnostic behavior when model contains unit inconsistencies

Model Configuration Pane: Diagnostics

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

Allow automatic unit conversions


Option to automatically convert units that have known mathematical relationship

Model Configuration Pane: Diagnostics

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

Dataset signal format


Option to specify whether elements of Dataset object for logged data store values as timeseries
or timetable objects

Model Configuration Pane: Data Import/Export

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.

Characteristic or Operation timeseries timetable


Merge logged data Use the extractTimetable Merge each timetable that
function to extract data for contains a single column with
multiple signals into one or data for one signal into a
more timetable objects that timetable that contains
each contain data for one or multiple columns, each with
more signals. data for a different signal.
View object properties The timeseries object Query the properties of the
separates time and data timetable to view all
properties into two separate properties and their values at
properties on the object, once.
TimeInfo and DataInfo.
tt.Properties
ts
ans =
timeseries
struct with fileds:
Common Properties:
Name: '' Description: ''
Time: [1001x1 double] UserData: []
DimensionNames:
TimeInfo: [1x1 tsdata.timemetadata] {'Time' 'Variab
VariableDescriptions:
Data: [1001x1 double] {}
VariableNames:
DataInfo: [1x1 tsdata.datametadata] ['temperature'
VariableUnits: {}
VariableContinuity: ['continuous']
RowTimes: [64x1 duration]

2-55
2 Simulink Configuration Parameters: Advanced

Characteristic or Operation timeseries timetable


Access data values Data values are stored in the Data values are stored in the
Data property of the Data property of the
timeseries object. This timetable. This command
command accesses the logged accesses the logged output
output values for the first output values for the first output port
port in the model. in the model.

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.

Time aligns with the first


dimension of data logged for
scalar and wide states, signals,
data stores, and outputs.
Units Units for logged data are stored Units for data values are not
in the Units property of the supported.
timeseries object.
Time values must be a
Logging stores units in the duration vector. Time values
timeseries object as a in logged data have units of
Simulink.SimulationData. seconds to match the unit of
Unit object. simulation time.

Loading signal data that uses


units is supported for
timeseries objects with units
specified as a
Simulink.SimulationData.
Unit object.
Identify element as continuous The Interpolation property The VariableContinuity
or discrete is linear for continuous property is continuous for
signals, states, and outputs and continuous signals, states, and
zoh for discrete signals, states, outputs and step for discrete
and outputs. signals, states, and outputs.

2-56
Dataset signal format

Characteristic or Operation timeseries timetable


Check whether time data is The TimeInfo property Use the isregular function to
evenly spaced indicates whether the time data determine whether the time
is uniform. data is evenly spaced.

You can also use the isregular


function to determine whether
the time data is evenly spaced.
View signal name Signal name stored on object. Signal name not stored on
object.

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

Stream To Workspace blocks


Option to disable streaming data logged using To Workspace blocks to Simulation Data Inspector

Model Configuration Pane: Hardware Implementation

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.

When you disable this parameter, To Workspace blocks do not support:

• Logging arrays of buses.


• Logging signals with string or half data types.
• Logging signals with int64 or uint64 using the built-in data types.

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

Array bounds exceeded


Diagnostic behavior when S-function writes beyond array bounds assigned in allocated memory

Model Configuration Pane: Diagnostics / Data Validity

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

Model Verification block enabling


Option to enable or disable model verification blocks

Model Configuration Pane: Diagnostics / Data Validity

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

Use local settings


Enables or disables model verification blocks based on the value of the Enable assertion
parameter for each block.
Enable All
Globally enables model verification blocks regardless of the value of the Enable assertion
parameter.
Disable All
Globally disables model verification blocks regardless of the value of the Enable assertion
parameter.

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

DisableAll for production code generation

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

Parameter Writer block validation


Globally or locally enable parameter validation

Model Configuration Pane: Diagnostics / Data Validity

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

Use local settings


The software enables or disables parameter validation for each Parameter Writer block in the
model based on the setting of the Validate parameter parameter for each block.

• When Validate parameter is selected for a block, parameter validation is enabled.


• When Validate parameter is cleared for a block, parameter validation is disabled.

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

Check undefined subsystem initial output


Option to issue warning when models contain conditionally executed subsystems with undefined
initial output values

Model Configuration Pane: Diagnostics

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

Detect multiple driving blocks executing at the


same time step
Diagnostic behavior when execution order is not defined for blocks that drive same Merge block at
the same time step

Model Configuration Pane: Diagnostics / Data Validity

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

Underspecified initialization detection


How software determines initial conditions for subset of Simulink blocks that have underspecified
initial conditions

Model Configuration Pane: Diagnostics / Data Validity

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:

• Do not specify initial conditions for output ports of conditional subsystems


• Contain conditionally executed subsystems that provide inputs for S-functions

For more information, see “Simplified Initialization Mode”.

To update your model to use the simplified initialization mode, run these Model Advisor
checks:

• “Check usage of Merge blocks”


• “Check usage of Outport blocks”
• “Check usage of Discrete-Time Integrator blocks”
• “Check model settings for migration to simplified initialization mode”

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.

For more information, see “Classic Initialization Mode”.

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

Solver data inconsistency


Diagnostic action to take when S-function with continuous sample time produces inconsistent results

Model Configuration Pane: Diagnostics

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.

Use this diagnostic only for debugging to verify that:

• 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

Ignored zero crossings


Diagnostic behavior when zero crossings ignored in simulation

Model Configuration Pane: Diagnostics

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

Masked zero crossings


Diagnostic action to take when zero crossings are masked

Model Configuration Pane: Diagnostics

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

Block diagram contains disabled library links


Diagnostic behavior when saving a model that contains disabled library links

Model Configuration Pane: Diagnostics

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

Block diagram contains parameterized library links


Diagnostic behavior when saving a model that contains parameterized library links

Model Configuration Pane: Diagnostics

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

Initial state is array


Diagnostic action to take when initial state for model specified as array

Model Configuration Pane: Diagnostics

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 order of the state values in the array


• The execution order for the model

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

Insufficient maximum identifier length


Diagnostic action to take when maximum identifier length is too short to ensure unique global
identifiers

Model Configuration Pane: Diagnostics

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

Compiler optimization level


Degree of compiler optimization when generating code for simulation

Model Configuration Pane: Simulation Target

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:

• Accelerator mode simulation


• Rapid accelerator mode simulation

The software generates a simulation target for normal mode simulation for:

• Referenced models that simulate in accelerator mode


• Stateflow charts
• MATLAB Function blocks
• MATLAB System blocks

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)

Optimizations off (faster builds)


The compiler does not optimize the code, which results in faster simulation target builds but can
result in slower execution during simulation.

This setting is an appropriate choice for most models.


Optimizations on (faster runs)
The compiler optimizes the code, which results in slower builds but can result in faster execution
in simulation.

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

Verbose accelerator builds


Amount of information displayed while building simulation target

Model Configuration Pane: Simulation Target

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

Implement logic signals as Boolean data (vs.


double)
Logic signal data type

Model Configuration Pane: Math and Data Types

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.

This parameter affects these blocks:

• 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

Model Configuration Pane: Simulation Target

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:

• Blocks that simply copy their input to their output


• Blocks or signals in an unused code path

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.

Understand Unused Code Paths

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.

Identify Reduced Blocks

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

To identify reduced blocks programmatically, use the

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

No impact for production code generation


Traceability off
Efficiency on
Safety precaution No impact

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

Conditional input branch execution


Option to optimize input paths for Switch and Multiport Switch blocks

Model Configuration Pane: Simulation Target

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:

• Blocks that determine the input values must:

• Have inherited (-1) or constant (inf) sample time


• Not have output signals designated as test points
• Not be multirate
• Not have states
• Model blocks are not supported.
• S-Function blocks are supported only when you enable the
SS_OPTION_CAN_BE_CALLED_CONDITIONALLY option.

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

Model Configuration Pane: Simulation Target

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

Compile-time recursion limit for MATLAB functions


Instance specialization limit for MATLAB Function blocks, Stateflow charts, and MATLAB System
blocks in generated code

Model Configuration Pane: Simulation Target

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:

• Increase the limit.


• Change the MATLAB code so that code generation uses run-time recursion instead.

To disallow specialization in the MATLAB code, set this parameter to 0.

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

“Compile-Time Recursion Limit Reached”


“Model Configuration Parameters: Simulation Target” on page 16-2

2-98
Enable implicit expansion in MATLAB functions

Enable implicit expansion in MATLAB functions


Option to enable implicit expansion for MATLAB Function blocks, Stateflow charts, and MATLAB
System blocks

Model Configuration Pane: Simulation Target

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

Enable run-time recursion for MATLAB functions


Option to allow recursive functions in MATLAB Function blocks, Stateflow charts, and MATLAB
System blocks

Model Configuration Pane: Simulation Target

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

“Compile-Time Recursion Limit Reached”


“Model Configuration Parameters: Simulation Target” on page 16-2

2-102
Dynamic memory allocation in MATLAB functions

Dynamic memory allocation in MATLAB functions


Option to use dynamic memory allocation for MATLAB code

Model Configuration Pane: Simulation Target

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.

This parameter is selected by default for GRT-based code generation targets.


off
The software does not use dynamic memory allocation for MATLAB code.

This parameter is cleared by default for ERT-based code generation targets.

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

Dynamic memory allocation threshold in MATLAB


functions
Threshold above which memory is allocated dynamically for MATLAB code

Model Configuration Pane: Simulation Target

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

Echo expressions without semicolons


Option to display runtime output values without semicolons to MATLAB Command Window

Model Configuration Pane: Simulation Target

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.

Clearing this parameter can improve simulation performance.

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

Enable continuous-time MATLAB functions to write


to initialized persistent variables
Option to allow continuous-time MATLAB functions to write to initialized persistent variables

Model Configuration Pane: Simulation Target

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

Allow setting breakpoints during simulation


Option to allow setting breakpoints in MATLAB code and Stateflow charts during simulation

Model Configuration Pane: Simulation Target

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.

This parameter value is not saved as part of the model configuration.

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

Enable memory integrity checks


Option to check for memory integrity violations for MATLAB Function blocks

Model Configuration Pane: Simulation Target

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

Type: string | character vector


Values: 'on' | 'off' |'alwaysOn'
Default: 'on'

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

Generate typedefs for imported bus and


enumeration types
typedef handling for bus and enumeration data types in Stateflow charts and MATLAB Function
blocks

Model Configuration Pane: Simulation Target

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)

Use local custom code settings (do not inherit


from main model)
Option to allow or disallow custom code settings in library models

Model Configuration Pane: Simulation Target

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

Values: 'on' | 'off'


Default: 'on'

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

Allow symbolic dimension specification


Option to propagate symbolic dimensions throughout model

Model Configuration Pane: Diagnostics

Description
The Allow symbolic dimension specification parameter specifies whether Simulink software:

• Propagates symbols used to specify symbolic dimensions throughout the model


• Preserves the symbols in the generated code

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

Enable decoupled continuous integration


Option to improve simulation performance by decoupling continuous state integration from discrete
sample times

Model Configuration Pane: Solver

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:

• You simulate the model using a variable-step solver.


• The fastest discrete sample time in the model is smaller than the value of the Max step size
parameter. To check the maximum step size the solver determines when the value of the Max step
size parameter is auto, get the value of the CompiledStepSize parameter using the
get_param function.

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

Type: string | character vector


Values: "on" | "off"
Default: "off"

Version History
Introduced in R2017b

See Also
Topics
“Solver Pane” on page 3-2

2-122
Enable minimal zero-crossing impact integration

Enable minimal zero-crossing impact integration


Option to reduce the effect of zero crossings on continuous state integration

Model Configuration Pane: Solver

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

Detect ambiguous custom storage class final


values
Diagnostic behavior when Reusable storage class has multiple endpoints

Model Configuration Pane: Diagnostics / Data Validity

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

Detect non-reused custom storage classes


Diagnostic behavior when code generation cannot reuse Reusable storage class

Model Configuration Pane: Diagnostics / Data Validity

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

Combine output and update methods for code


generation and simulation
Option to require same execution order for simulation and generated code

Model Configuration Pane: Diagnostics

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

Include custom code for referenced models


Option to use custom code in model reference simulation target

Model Configuration Pane: Model Referencing

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.

Set Configuration Parameter for 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
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

Model Configuration Pane: Simulation Target

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

Leverage generic hardware (Faster, no rebuild)


The software leverages SIMD instructions for hardware generic to Simulink system requirements.
When you select this setting, you do not need to rebuild the model for simulation when the host
computer changes.
Leverage native hardware (Fastest, rebuild allowed)
The software leverages SIMD instructions for hardware native to the host computer. This setting
provides the best simulation performance but might require rebuilding the model for simulation
when the host computer changes.
Off
The software does not use hardware acceleration.

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

Behavior when pregenerated library subsystem


code is missing
Diagnostic behavior when model cannot use pregenerated library code or pregenerated library code
is missing

Model Configuration Pane: Diagnostics

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

Behavior when a matching unit test for subsystem


reference is missing
Diagnostic behavior when subsystem reference signature does not match any unit test signature

Model Configuration Pane: Diagnostics

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

Arithmetic operations in variant conditions


Diagnostic behavior when variant condition values include arithmetic operations

Model Configuration Pane: Diagnostics

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

Variant activation time inherited from


Simulink.VariantControl
Diagnostic behavior when variant blocks that inherit activation time from
Simulink.VariantControl have no value to inherit

Model Configuration Pane: Diagnostics

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

FMU Import blocks


Option to enable debug execution mode for FMU Import blocks

Model Configuration Pane: Diagnostics

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

Variant condition mismatch at signal source and


destination
Diagnostic behavior when variant modeling issues might cause creation of unused variables in
generated code

Model Configuration Pane: Diagnostics

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

Variant configuration not used by top model


Diagnostic behavior when variant configuration of a top model does not use an existing variant
configuration of a referenced model

Model Configuration Pane: Diagnostics

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

Use precompiled libraries for MATLAB functions


Instruct the code generator to favor usage of either precompiled libraries or alternative
implementations

Model Configuration Pane: Simulation Target

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

Prefer precompiled libraries when available


The code generator prefers to use the available platform-specific precompiled libraries.

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 Solver Information tooltip displays:

• The compiled solver name


• The step size, specified using the Max step size parameter or the Fixed-step size (fundamental
sample time) parameter.

Once the model compiles, the status bar displays the solver used for compiling and a carat (^) when:

• The software selects a different solver during compilation.


• You set the step size to auto. The Solver Information tooltip displays the step size that the
software calculated.

When configuring the solver, consider that:

• 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

These configuration parameters are in the Advanced parameters section.

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

Model Configuration Pane: Solver

Description
Specify the largest acceptable solver error as the value of the measured state approaches zero.

At each time step, the solver:

• Calculates the value of each state


• Estimates the error in each state calculation
• Determines the acceptable error for each state using the relative tolerance, absolute tolerance,
and state values

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:

• ei is the acceptable error based on relative tolerance at that time step.


• reltol is the value specified for the Relative tolerance parameter.
• x is the state value.

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.

For more information, see “Error Tolerances for Variable-Step Solvers”.

Dependencies
To enable this parameter:

• Set the solver Type to Variable-step.


• Set the Solver parameter to a value other than discrete (no continuous states).

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

abstol = reltol * 1e-3 when reltol ≤ 1e-3

abstol = 1e-6 when reltol > 1e-3,

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.

abstol = xmax * reltol

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

Allow multiple tasks to access inputs and outputs


Option to treat root-level input and output ports as part of each connected task in rate-based model

Model Configuration Pane: Solver

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.

This parameter does not apply for export-function models.

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

Automatically handle rate transition for data


transfer
Option to ensure integrity of data transfer between different sample times in deployed code

Model Configuration Pane: Solver

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

Off for production code generation


Efficiency No impact
Safety precaution No recommendation

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

Auto scale absolute tolerance


Option to scale absolute tolerance based on state values

Model Configuration Pane: Solver

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:

• Set the solver Type to Variable-step.


• From the Solver list, select an option other than discrete (no continuous states).
• Specify the Absolute tolerance parameter as a positive scalar number.

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.

abstol = xmax * reltol

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

Allow tasks to execute concurrently on target


Enable concurrent tasking behavior for model

Model Configuration Pane: Solver

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

Model Configuration Pane: Solver

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

Model Configuration Pane: Solver

Description
Select the mode of operation for the daessc solver.

Dependencies
To enable this parameter:

• Set the solver Type to Variable-step.


• Set the Solver parameter to daessc (DAE solver for Simscape™).

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

Enable zero-crossing detection for fixed-step


simulation
Option to use zero-crossing detection with fixed-step solver

Model Configuration Pane: Solver

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.

Enabling this parameter enables these 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.

Fixed-step zero-crossing detection improves the accuracy of simulation results by compensating


continuous state values when discontinuities occur during simulation. Enable fixed-step zero-crossing
detection for a model that does not have continuous states only when required for code generation.
Enabling fixed-step zero-crossing detection for simulation of a model that has no continuous states
might affect simulation performance.

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

Treat each discrete rate as a separate task


Option to enable multitasking execution

Model Configuration Pane: Solver

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:

• Your model contains one sample time.


• Your model contains a continuous and a discrete sample time, and the fixed step size is equal
to the discrete sample time.

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

Off for production code generation


Efficiency No impact
Safety precaution No recommendation

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

Model Configuration Pane: 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).

To enable this parameter when the solver Type is Variable-step:

• For the Solver parameter, select odeN (Nonadaptive).


• For the Integration method parameter, 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)

Fixed-step size (fundamental sample time)


Step size for fixed-step solver

Model Configuration Pane: Solver

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:

• Set the Type parameter to Fixed-step.


• Set the Periodic sample time constraint parameter to Unconstrained.

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;

positive scalar double


To use a value other than auto, specify the fixed step size in seconds as a double-precision value.

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.

When you specify the step size of a local solver:

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.

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.

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

Initial step size


Size of first time step for variable-step solver

Model Configuration Pane: Solver

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

Deterministic data transfer


Deterministic data transfer behavior for automatically inserted Rate Transition blocks

Model Configuration Pane: Solver

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.

To enable this parameter when the solver Type is Fixed-step:

• Set Periodic sample time constraint to Unconstrained or Specified.


• 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

Number of consecutive min steps


Number of steps less than or equal to minimum step size allowed before minimum step size violation
occurs

Model Configuration Pane: Solver

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:

• Set the solver Type to Variable-step.


• Set the Solver parameter to a value other than discrete (no continuous states).

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

Number of consecutive zero crossings


Threshold for issuing diagnostic due to consecutive zero crossings

Model Configuration Pane: Solver

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

Model Configuration Pane: Solver

Description
Specify the order of the numerical differentiation formulas (NDFs) used for the ode15s solver.

Dependencies
To enable this parameter:

• Set the solver Type to Variable-step.


• Set the Solver parameter to ode15s (stiff/NDF).

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

Max step size


Maximum step size for variable-step solver

Model Configuration Pane: Solver

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

Specify Solver Parameters Using Values Selected by Software

Open the model vdp.


mdl = "vdp";
open_system(mdl)

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

Maximum number of bracketing iterations


Maximum number of iterations performed when locating zero crossing

Model Configuration Pane: Solver

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:

• Set solver Type to Fixed-step.


• Select Enable zero-crossing detection for fixed-step simulation.

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

Maximum number of zero-crossings per step


Maximum number of zero crossings to locate in a single time step

Model Configuration Pane: Solver

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:

• Set the solver Type to Fixed-step.


• Select Enable zero-crossing detection for fixed-step simulation.

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

Min step size


Minimum step size for variable-step solver

Model Configuration Pane: Solver

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

Number of Newton's iterations


Number of Newton's method iterations used by ode14x and ode1be solvers

Model Configuration Pane: Solver

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

To enable this parameter when the solver Type is Variable-step:

• For the Solver parameter, select odeN (Nonadaptive).


• For the Integration method parameter, 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

Model Configuration Pane: 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:

• Set the solver Type to Variable-step.


• From the Solver list, select odeN (Nonadaptive).

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

Higher priority value indicates higher task priority


Priority ordering for real-time system targets

Model Configuration Pane: Solver

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

Model Configuration Pane: Solver

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.

At each time step, the solver:

• Calculates the value of each state


• Estimates the error in each state calculation
• Determines the acceptable error for each state using the relative tolerance, absolute tolerance,
and state values

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:

• ei is the acceptable error based on relative tolerance at that time step.


• reltol is the value specified for the Relative tolerance parameter.
• x is the state value.

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.

For more information, see “Error Tolerances for Variable-Step Solvers”.

Dependencies
To enable this parameter:

• Set the solver Type to Variable-step.


• Set the Solver parameter to a value other than discrete (no continuous states).

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

Periodic sample time constraint


Option to specify constraints on model sample times

Model Configuration Pane: Solver

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.

When you select Unconstrained, you can configure these parameters:

• Fixed-step size (fundamental sample time)


• Treat each discrete rate as a separate task
• Higher priority value indicates higher task priority
• Automatically handle rate transitions for data transfers

Ensure sample time independent


When you select this option, referenced models inherit sample time from the context in which
they are used. Select this option to detect sample time problems related to referencing models
with intrinsic sample time inside triggered or iterator subsystems.

• “Referenced Model Sample Times”


• “S-Functions That Specify Sample Time Inheritance Rules” (Simulink Coder)
• “Conditionally Execute Referenced Models”

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

When you select Specified, you can configure these parameters:

• Sample time properties


• Treat each discrete rate as a separate task
• Higher priority value indicates higher task priority
• Automatically handle rate transitions for data transfers

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

Sample time properties


Discrete sample time periods, offsets, and priorities

Model Configuration Pane: Solver

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:

[period, offset, priority]

• period — Sample time period


• offset — Sample time offset relative to other blocks with the same period
• priority — Execution priority of the real-time task associated with the sample time

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]]:

• Declares that the model should specify three sample times


• Sets the fundamental sample time period to 0.1 second
• Assigns priorities of 10, 11, and 12 to the sample times
• Assumes that higher priority values indicate lower priorities

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

Model Configuration Pane: Solver

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:

• Set the solver Type to Variable-step.


• Set the Solver parameter to a value other than discrete (no continuous states).

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

Model Configuration Pane: Solver

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

The software provides several types of fixed-step and variable-step solvers.

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:

• Max step size


• Min step size
• Relative tolerance
• Absolute tolerance
• Zero-crossing control

Fixed-Step Solvers

In general, fixed-step solvers except for ode14x and ode1be calculate the next step using this
formula:

X(n+1) = X(n) + h dX(n)

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:

• Fixed-step size (fundamental sample time)


• Enable zero-crossing detection for fixed-step simulation

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

auto (Automatic solver selection)


The software selects the variable-step solver to compute the model states based on the model
dynamics. For most models, the software selects an appropriate solver.
discrete (no continuous states)
Use this solver only for models that contain no states or only discrete states. The discrete
variable-step solver computes the next simulation time hit by adding a step size that depends on
the rate of change for states in the model.
ode45 (Dormand-Prince)
When you manually select a solver, ode45 is an appropriate first choice for most systems. The
ode45 solver computes model states using an explicit Runge-Kutta (4,5) formula, also known as
the Dormand-Prince pair, for numerical integration.
ode23 (Bogacki-Shampine)
The ode23 solver computes the model states using an explicit Runge-Kutta (2,3) formula, also
known as the Bogacki-Shampine pair, for numerical integration.

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.

The daessc solver is available only with Simscape products.

Fixed-Step Solvers

auto (Automatic solver selection)


The software selects a fixed-step solver to compute the model states based on the model
dynamics. For most models, the software selects an appropriate solver.
discrete (no continuous states)
Use this solver only for models that contain no states or only discrete states. The discrete fixed-
step solver relies on blocks in the model to update discrete states

The discrete fixed-step solver does not support zero-crossing detection.


ode8 (Dormand-Prince)
The ode8 solver uses the eighth-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.

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:

X(n+1) - X(n)- h dX(n+1) = 0

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

Specify Solver Parameters Using Values Selected by Software

Open the model vdp.

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

Solver Jacobian Method


Method implicit solvers use to compute Jacobian matrix

Model Configuration Pane: Solver

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

Solver reset method


Option to specify whether solver recomputes Jacobian matrix during solver reset

Model Configuration Pane: Solver

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:

• Set the solver Type to Variable-step.


• Set the Solver parameter to ode15s (stiff/NDF), ode23t (mod. stiff/Trapezoidal), or
ode23tb (stiff/TR-BDF2).

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

Type: string | character vector


Value: 'Fast' | 'Robust'
Default: 'Fast'

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

Model Configuration Pane: 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.

Code generation requires a fixed-step solver.

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

Model Configuration Pane: Solver

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

Specify Start and Stop Time for Model

Open the model vdp.

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.

1 On the Modeling tab, under Setup, click Model Settings.


2 Select the Solver pane.
3 In the Start time box, enter 10.
4 In the Stop time box, enter 40.
5 Click OK.

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

Specify Start and Stop Time for Simulation

To change the start and stop time for a simulation without modifying configuration parameter values
saved in a model, use a Simulink.SimulationInput object.

Open the model vdp.


mdl = "vdp";
open_system(mdl)

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'

Create a Simulink.SimulationInput object to configure a simulation of the model.


simIn = Simulink.SimulationInput(mdl);

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");

Simulate the model using the SimulationInput object.

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

The configuration parameter values in the model remain unchanged.

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

Model Configuration Pane: Solver

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

Specify Start and Stop Time for Model

Open the model vdp.

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.

1 On the Modeling tab, under Setup, click Model Settings.


2 Select the Solver pane.
3 In the Start time box, enter 10.
4 In the Stop time box, enter 40.
5 Click OK.

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

Specify Start and Stop Time for Simulation

To change the start and stop time for a simulation without modifying configuration parameter values
saved in a model, use a Simulink.SimulationInput object.

Open the model vdp.


mdl = "vdp";
open_system(mdl)

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'

Create a Simulink.SimulationInput object to configure a simulation of the model.


simIn = Simulink.SimulationInput(mdl);

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");

Simulate the model using the SimulationInput object.

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

The configuration parameter values in the model remain unchanged.

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

Model Configuration Pane: Solver

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:

• Set the solver Type to Variable-step.


• Set Zero-crossing control to either Use local settings or Enable all.
• Set Algorithm to Adaptive.

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

Model Configuration Pane: 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

Model Configuration Pane: Solver

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

Use local settings


When you select this option, you enable or disable zero-crossing detection for each block in your
model that registers zero crossings using the block parameters.

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

Data Import/Export Parameters


4 Data Import/Export Parameters

Model Configuration Parameters: Data Import/Export

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

These configuration parameters are in the Advanced parameters section.

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

Model Configuration Pane: Data Import/Export

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.

For more information, see “Load Data to Root-Level Input Ports”.

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

Format Description Tips and Considerations


Simulink.Simu Each element in the Dataset object • The Dataset object can contain
lationData.Da contains data for a top-level input data for top-level ports that
taset port. produce scalar, vector, and
multidimensional signals as well
as buses and arrays of buses.
• To create a Dataset object that
contains an element for each top-
level input port, use the
createInputDataset function.
• Dataset is the default format
for most types of logging,
including output, states, and
signal logging.
Simulink.Simu The DatasetRef object references The simulation incrementally loads
lationData.Da a Dataset object saved in a MAT the data referenced by a
tasetRef file. Each element of the Dataset DatasetRef object instead of
object that the DatasetRef object loading all of the data into memory
references contains data for a top- at the start of the simulation.
level input port. Consider using a DatasetRef
object when you need to load large
amounts of data. For more
information, see:

• “Load Big Data for Simulations”


• “Stream Data from a MAT-File as
Input for a Parallel Simulation”
Structure Structure that contains these fields: • This format does not support
input data for buses or arrays of
• signals — Array of structures buses.
where each structure contains
• When you load only data for
data for a top-level input port
discrete input signals, consider
• time — Optional array of time omitting the time field. For
values that correspond to the more information, see “Control
signal values for all top-level How Models Load Input Data”.
input ports
• To create an evenly spaced time
vector, create an integer vector
that contains the desired number
of time steps, then scale the
values in the vector by the
sample time.

time = sampleTime*(0:numSteps);

Using other options, such as


linspace, can introduce
discrepancies in the data due to
floating-precision rounding.

4-5
4 Data Import/Export Parameters

Format Description Tips and Considerations


Array The first column in the array • Array format supports loading
contains time values that must only real scalar signals and real
increase monotonically. Subsequent wide or vector signals.
columns contain data for each top- • Values in the array must have
level input port in sequential order double data type.
by port number.
• When your model has a top-level
Trigger block, specify the data
for the trigger signal in the last
column.

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

Type of Output Supported Input Supported Values Tips and


Data Formats for Input Parameter Considerations
Scalar or vector • timetable that • Simulink.Simul • For scalar and
signal contains a single ationData.Data vector signals, the
column set object number of rows in
• timeseries • Simulink.Simul the signal data
object ationData.Data must match the
setRef object number of rows in
• Simulink.Simul the time vector.
ationData.Sign • Structure
al object • To create a
• Array timetable, the
• matlab.io.data • Comma-separated time values must
store.Simulati list be a duration
onDatastore vector.
object
• Structure with Simulation time
fields and always uses units
hierarchy that of seconds. When
match the you create a
Structure or duration vector
Structure with that uses units
time logging other than
format seconds, the
software converts
• Two-dimensional
the value to
array in which the
seconds for use in
first column is time
the simulation.
and one or more
additional columns • Array format does
contain the signal not support signal
value for each values that are
timestamp complex or that
have a data type
other than
double.

4-7
4 Data Import/Export Parameters

Type of Output Supported Input Supported Values Tips and


Data Formats for Input Parameter Considerations
Multidimensional • timeseries • Simulink.Simul • For a
signal object ationData.Data multidimensional
• timetable that set object signal with values
contains a single • Simulink.Simul that have two or
column ationData.Data more dimensions,
setRef object the length of the
• Simulink.Simul last dimension
ationData.Sign • Structure must match the
al object • Comma-separated length of the time
• matlab.io.data list vector.
store.Simulati
onDatastore For example, input
object data for 10
samples of a 2-
• Structure with
by-2 matrix signal
fields and
has a time vector
hierarchy that
that contains 10
match the
rows and an array
Structure or
of signal values
Structure with
that has
time logging
dimensions 2-by-2-
format
by-10.
• To create a
timetable, the
time values must
be a duration
vector.

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

Type of Output Supported Input Supported Values Tips and


Data Formats for Input Parameter Considerations
Variable-size signal Structure with fields • Simulink.Simul To log a variable-size
and hierarchy that ationData.Data signal in a format you
match the Structure set object can load using the
or Structure with • Simulink.Simul From Workspace
time logging format ationData.Data block, connect the
setRef object signal to a top-level
Outport block and set
• Structure the Format
• Comma-separated configuration
list parameter for the
model to Structure
or Structure with
time.
Bus Structure of • Simulink.Simul To partially specify
timetable, ationData.Data input data for a bus,
timeseries, or set object set bus elements for
matlab.io.datasto • Simulink.Simul which you do not need
re.SimulationData ationData.Data to load data to [] in
store objects: setRef object the input data
structure.
• Specify the • Comma-separated
Output data type list
parameter as the
Simulink.Bus
object that defines
the bus.
• The hierarchy and
field names of the
structure must
match the
hierarchy and
element names of
the bus.
• Each timetable
or timeseries
object contains
data for a leaf
signal in the bus.
• Each timetable
must contain only
one column.

4-9
4 Data Import/Export Parameters

Type of Output Supported Input Supported Values Tips and


Data Formats for Input Parameter Considerations
Array of buses Array of structures • Simulink.Simul To partially specify
that each represent ationData.Data input data for an
data for a bus within set object array of buses, set bus
the array of buses • Simulink.Simul elements for which
ationData.Data you do not need to
load data to [] in the
setRef object
structure that
• Comma-separated represents the data
list for that bus.
Function-call signal n-by-1 column vector • Simulink.Simul To configure a top-
that specifies the time ationData.Data level Inport block to
for each function-call set object produce a function-
event • Simulink.Simul call signal, select the
ationData.Data Output function call
setRef object parameter for the
block.
• Structure
• Comma-separated
list
Ground [] • Simulink.Simul When you do not want
ationData.Data to load external input
set object data for an input port,
• Simulink.Simul specify the data for
ationData.Data that port as []. The
setRef object input port produces
ground values in the
• Structure model during
• Comma-separated simulation.
list

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

Model Configuration Pane: Data Import/Export

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:

• The order of the state values in the array

4-12
Initial state

• The execution order for the model

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

Resume Simulation Using Initial Operating Point

Open the model vdp.

mdl = "vdp";
open_system(mdl);

Configure the model to save the final operating point at the end of simulation.

1 On the Modeling tab, under Setup, click Model Settings.


2 In the Configuration Parameters dialog box, select the Data Import/Export pane.
3 On the Data Import/Export tab, select Final states and Save final operating point.
4 Click OK.

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");

Simulate the model.

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.

1 On the Modeling tab, under Setup, click Model Settings.


2 In the Configuration Parameters dialog box, on the Data Import/Export pane, select Initial
state.
3 In the text box, enter vdpOP.
4 Click OK.

Alternatively, create another Simulink.SimulationInput object to configure this simulation.


Then, use the setInitialState function to specify the initial state.

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

R2023b: Inf state values supported

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

Model Configuration Pane: Data Import/Export

Description
Specify whether to log simulation time data to the specified MATLAB variable during simulation.

By default, simulation results are returned as a single Simulink.SimulationOutput object. The


logging variable you specify for time becomes a property of the SimulationOutput object. To
access the logged time data, use dot notation. For example, when you use the default output variable
name out and the default time logging variable name tout, access the time data using this code.

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

Value: valid MATLAB variable name


Default: 'tout'

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

Model Configuration Pane: Data Import/Export

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.

By default, simulation results are returned as a single Simulink.SimulationOutput object. The


logging variable you specify for logged states data becomes a property of the SimulationOutput
object. To access the logged states data, use dot notation. For example, when you use the default
output variable name out and the default states logging variable name xout, access the states data
using this code.
xout = out.xout;

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:

• Logging states during rapid accelerator simulation


• Logging states inside a function-call subsystem
• Logging states in simulations deployed using Simulink Compiler™
• Code generation
• The states logging variable is empty when you enable states logging for a model that has no
states.

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

Model Configuration Pane: Data Import/Export

Description
Specify whether the software logs data for output ports in the top model.

By default, simulation results are returned as a single Simulink.SimulationOutput object. The


logging variable you specify for outputs becomes a property of the SimulationOutput object. To
access the logged output data, use dot notation. For example, when you use the default output
variable name out and the default output logging variable name yout, access the output data using
this code.

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

Model Configuration Pane: Data Import/Export

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

Model Configuration Pane: Data Import/Export

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.

Dataset format does not support:

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

• All scalars or all vectors (or all matrices for states)


• All real or all complex
• The same data type

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

Access Data Logged Using Dataset Format

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]

SimulationMetadata: [1x1 Simulink.SimulationMetadata]


ErrorMessage: [0x0 char]

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

- Use braces { } to access, modify, or add elements using index.

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

Limit data points to last


Option to log only last n data points for outputs, states, and time

Model Configuration Pane: Data Import/Export

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

Model Configuration Pane: Data Import/Export

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

Save final operating point


Option to save complete model operating point when simulation is paused or stopped

Model Configuration Pane: Data Import/Export

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

Resume Simulation Using Initial Operating Point

Open the model vdp.

mdl = "vdp";
open_system(mdl);

Configure the model to save the final operating point at the end of simulation.

1 On the Modeling tab, under Setup, click Model Settings.


2 In the Configuration Parameters dialog box, select the Data Import/Export pane.
3 On the Data Import/Export tab, select Final states and Save final operating point.
4 Click OK.

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");

Simulate the model.

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.

1 On the Modeling tab, under Setup, click Model Settings.


2 In the Configuration Parameters dialog box, on the Data Import/Export pane, select Initial
state.
3 In the text box, enter vdpOP.
4 Click OK.

4-36
Save final operating point

Alternatively, create another Simulink.SimulationInput object to configure this simulation.


Then, use the setInitialState function to specify the initial state.

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

Model Configuration Pane: Data Import/Export

Description
Specify whether to log data for signals marked for logging to the workspace and the Simulation Data
Inspector.

By default, simulation results are returned as a single Simulink.SimulationOutput object. The


logging variable you specify for logged signals becomes a property of the SimulationOutput object.
To access the logged signal data, use dot notation. For example, when you use the default output
variable name out and the default signal logging variable name logsout, access the signal data
using this code.

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.

Signal logging always saves data using the Dataset format.

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:

• Signals inside Stateflow charts for rapid accelerator simulations


• Input signals of function-call subsystems, if-action subsystems, or switch case action
subsystems
• Input signals for Merge blocks
• Outputs of Function-Call Generator blocks
• Outputs of Trigger and Enable blocks
• Buses inside for-each subsystems
• Signals in referenced models inside for-each subsystems when:

• 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

R2023b: Log unbounded variable-size signals

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.

R2023a: Log nonvirtual buses that contain variable-size signals

In normal and accelerator mode simulations, you can log:

• Nonvirtual buses that contain variable-size signals directly or in nested buses


• Buses with nested nonvirtual buses that contain variable-size signals

In normal mode simulations only, you can log:

• Arrays of buses with nonvirtual buses that contain variable-size signals

R2021a: Variable-size signal support

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.

R2017a: Unified streaming and logging

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

“Model Configuration Parameters: Data Import/Export” on page 4-2

4-42
Data stores

Data stores
Option to log data for Data Store Memory blocks

Model Configuration Pane: Data Import/Export

Description
Specify whether the software logs all Data Store Memory block variables for the model to the
specified MATLAB variable.

By default, simulation results are returned as a single Simulink.SimulationOutput object. The


logging variable you specify for logged data stores becomes a property of the SimulationOutput
object. To access the logged data store data, use dot notation. For example, when you use the default
output variable name out and the default states logging variable name dsmout, access the data store
data using this code.

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.

Data store logging always uses the Dataset format.


off
The software does not log Data Store Memory block variables.

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

Log Dataset data to file


Option to log data that uses Dataset format to MAT file

Model Configuration Pane: Data Import/Export

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

Model Configuration Pane: Data Import/Export

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

Model Configuration Pane: Data Import/Export

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

Value: positive integer greater than zero


Default: '1'

Version History
Introduced before R2006a

R2022a: Refine factor parameter ignored for purely discrete models


Behavior changed in R2022a

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

Model Configuration Pane: Data Import/Export

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

Specify output times for a variable-step simulation as a 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

Single simulation output


Option to return simulation results as single Simulink.SimulationOutput object

Model Configuration Pane: Data Import/Export

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.

Simulating a model creates one or more Simulink.SimulationOutput objects in any of these


situations, even when you disable Single simulation output:

• You run a set of simulations using the Multiple Simulations pane.


• You simulate the model programmatically using one or more Simulink.SimulationInput
objects.

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

For more information, see sim.

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

“Get Started with Fast Restart”

4-55
4 Data Import/Export Parameters

Logging intervals
Option to specify time intervals in which to log simulation data

Model Configuration Pane: Data Import/Export

Description
Specify time intervals during which to log data.

The logging intervals apply to:

• Time
• States
• Output
• Signal logging
• To Workspace blocks
• To File blocks
• Data logged to the workspace using a Record block

The logging intervals do not apply to:

• Final states data


• Data logged using scopes
• Data logged to a file using a Record block
• Data in the Simulation Data Inspector

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:

• Data logged using a To File block


• MAT file logging (enabled with the MAT-file logging configuration parameter)
• Processor-in-the-loop (PIL) simulations do not support logging intervals. Specified logging
intervals are ignored without a warning message.

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

Record logged workspace data in Simulation Data


Inspector
Option to send data logged in format other than Dataset to Data Inspector at end of simulation

Model Configuration Pane: Data Import/Export

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

Math and Data Types


5 Math and Data Types

Math and Data Types Pane

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.

These configuration parameters are in the Advanced parameters section.

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

Simulation behavior for denormal numbers


Emulate hardware handling of denormal numbers

Model Configuration Pane: Math and Data Types

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:

• The DenormalBehavior parameter is set to 'FlushToZero'.


• The model is simulated in accelerator, rapid accelerator, SIL, or PIL mode. SIL and PIL simulations
require an Embedded Coder license.

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

R2024b: Flush To Zero (FTZ) behavior standardized across hardware platforms


Behavior changed in R2024b

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.

In prior releases, the behavior was as follows:

• 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

“Simulation Mode Override Behavior in Model Reference Hierarchy” (Embedded Coder)

5-5
5 Math and Data Types

Default for underspecified data type


Data type to use when Simulink cannot infer the data type

Model Configuration Pane: 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

Use division for fixed-point net slope computation


How net slope computations are performed when a change of fixed-point slope is not a power of two

Model Configuration Pane: 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.

Operation Use division for fixed-point Use division for fixed-point


net slope computation On net slope computation Off
Multiplication Fixed-point multiplication Fixed-point multiplication
operations with non-power-of-2 operations follow legacy
slopes and/or non-zero bias have behavior.
improved representation.
Division Fixed-point division operations with non-power-of-2 slopes and/or
non-zero bias have improved representation.
Cast Fixed-point cast operations with Fixed-point cast operations
non-power-of-2 slopes and/or follow legacy behavior.
non-zero bias have improved
representation.

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

Gain parameters inherit a built-in integer type


that is lossless
Parameter data type for Gain blocks that inherit via internal rule

Model Configuration Pane: 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.

These conditions are:

• The input type is a built-in integer.


• The Parameter data type is set to Inherit:Inherit via internal rule.
• The value of the gain parameter can be represented without losing any precision by a built-in
integer.
• The Parameter minimum and Parameter maximum values in the Parameter Attributes tab of
the Gain block parameters can be represented without losing any precision by a built-in integer.

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

Use floating-point multiplication to handle net


slope corrections
Net slope correction computation for floating-point to fixed-point casts

Model Configuration Pane: 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

Inherit floating-point output type smaller than


single precision
Inherited output data type behavior when block inputs are floating-point data types smaller than
single precision

Model Configuration Pane: 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.

This parameter affects only these blocks:

• 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

Application lifespan (days)


Duration in days before timer overflow occurs

Model Configuration Pane: 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

The default setting depends on the model code generation configuration.

Default Parameter Settings


Code Generation Configuration Default
GRT-based system target file auto with an underlying value of inf
ERT-based system target file and data code auto with an underlying value of 1
interface
ERT-based system target file and service code inf
interface

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

Clock resolution (seconds, -1 for inherited)


Simulate target platform clock resolution

Model Configuration Pane: 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

Use algorithms optimized for row-major array


layout
Enable algorithm for row-major format code generation and simulation

Model Configuration Pane: 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.

This parameter affects only these blocks:

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

ArrayLayout UseRowMajorAlgorithm Algorithm Applied


Column-major 'off' Efficient column-major
algorithm

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

Model Configuration Parameters: Diagnostics

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.

These configuration parameters are in the Advanced parameters section.

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

Model Configuration Pane: Diagnostics

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.

For more information, see “Algebraic Loop Concepts”.


• When a model contains an algebraic loop, the software calls a loop-solving routine to solve the
loop at each time step. The loop solver performs iterations to determine the solution. As a result,
algebraic loops can negatively affect simulation performance.
• To identify and analyze algebraic loops in your model, use the
Simulink.BlockDiagram.getAlgebraicLoops function.

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

Minimize algebraic loop


Diagnostic behavior when the software is unable to resolve artificial algebraic loops

Model Configuration Pane: Diagnostics

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

Block priority violation


Diagnostic behavior when the software detects block priority specification error

Model Configuration Pane: Diagnostics

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

“Model Configuration Parameters: Diagnostics” on page 6-2

6-10
Min step size violation

Min step size violation


Diagnostic behavior when minimum step size violation occurs

Model Configuration Pane: Diagnostics

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

Diagnosing Simulation Errors


“Model Configuration Parameters: Diagnostics” on page 6-2

6-12
Consecutive zero-crossings violation

Consecutive zero-crossings violation


Diagnostic behavior when zero-crossing violation occurs

Model Configuration Pane: Diagnostics

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.

The diagnostic message includes this information:

• Current simulation time


• Number of consecutive zero crossings counted
• Type and name of the block where the software detected the zero crossings

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

Automatic solver parameter selection


Diagnostic behavior when the software changes a solver parameter value

Model Configuration Pane: Diagnostics

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

Extraneous discrete derivative signals


(Removed) Diagnostic behavior when discrete model reference inputs drive continuous blocks

Model Configuration Pane: Diagnostics

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.

This diagnostic applies only to models that contain Model blocks.

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

State name clash


Diagnostic behavior when more than one state has same name

Model Configuration Pane: Diagnostics

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

“Model Configuration Parameters: Data Import/Export” on page 4-2


“Model Configuration Parameters: Diagnostics” on page 6-2

6-20
Operating point restore interface checksum mismatch

Operating point restore interface checksum


mismatch
Diagnostic behavior when interface checksum does not match between initial operating point and
model

Model Configuration Pane: Diagnostics

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.

Model Changes Between Saving and Restoring Model Operating Points

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:

• Adding or removing blocks other than logging and visualization blocks


• Changing the type of solver from variable-step to fixed-step or from fixed-step to variable-step
• Changing connections between blocks
• Changing nontunable block parameter values such as data types, sample times, and dimensions

In general, you can make these kinds of nonstructural changes to a model between saving and
restoring the model operating point:

• Renaming the model.


• Changing the solver without changing the solver type.

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

• Changing which signals are marked for logging.


• Adding or removing of visualization and logging blocks such as the Scope block, Floating Scope
block, To Workspace block, and To File block.
• Adding or removing a Level-2 MATLAB S-function that has the SetSimViewingDevice flag set to
true and operating point compliance set to a value other than custom or disallowed. For more
information, see “Level-2 MATLAB S-Function Compliance with Model Operating Point”.
• Adding or removing a C S-function that has the SS_OPTION_SIM_VIEWING_DEVICE option set
and has the operating point compliance set to a value other than custom or disallowed. For more
information, see ssSetOperatingPointCompliance.

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

R2019a: SimState interface checksum mismatch parameter renamed to Operating point


restore interface checksum mismatch

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.

The SimStateInterfaceChecksumMismatchMsg parameter continues to work and results in the


same behavior as 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

Diagnostics Parameters: Sample Time


7 Diagnostics Parameters: Sample Time

Model Configuration Parameters: Sample Time Diagnostics

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

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

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

• “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-6
Single task data transfer

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

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

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

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

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

Unspecified inheritability of 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

Diagnostics Parameters: Data Validity


8 Diagnostics Parameters: Data Validity

Model Configuration Parameters: Data Validity

The Diagnostics > Data Validity category includes parameters for detecting issues related to data
(signals, parameters, and states). These issues include:

• Loss of information due to data type quantization and overflow.


• Loss of parameter tunability in the generated code.
• Loss of information due to Data Store Write and Data Store Read block ordering.

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.

These configuration parameters are in the Advanced parameters section.

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

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.

To get help on an option


1 Right-click the option text label.
2 From the context menu, select What's This.

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

• Simulink software provides the disableimplicitsignalresolution function, which you can


use to change settings throughout a model so that it does not use implicit signal resolution.

Command-Line Information
Parameter: SignalResolutionControl
Value: 'None' | 'UseLocalSettings' | 'TryResolveAll' | 'TryResolveAllWithWarning'
Default: 'UseLocalSettings'

SignalResolutionControl Value Equivalent Signal Resolution Value


'None' None
'UseLocalSettings' Explicit only
'TryResolveAll' Explicit and implicit
'TryResolveAllWithWarning' Explicit and warn implicit

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

Division by singular matrix

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

Underspecified data types

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

Identify and Resolve Underspecified Data Types

This example shows how to use the configuration parameter Underspecified data types to identify
and resolve an underspecified data type.

1 Open the example model UnderspecifiedDataTypes.


2 Set the Underspecified data types configuration parameter to warning.
3 Update the diagram. The signals in the model use the data type uint8, and the model generates
a warning.
4 Open the Diagnostic Viewer. The warning indicates that the output signal of the Constant block
has an underspecified data type.
5 Open the Constant block dialog box. On the Signal Attributes tab, Output data type is set to
Inherit: Inherit via back propagation. The Constant block output inherits a data type
from the destination block. In this case, the destination is the Sum block.
6 Open the Sum block dialog box. On the Signal Attributes tab, Accumulator data type is set to
Inherit: Inherit via internal rule. Sum blocks cast all of their input signals to the
selected accumulator data type. In this case, the accumulator data type is specified as an
inherited type.
7 Open the Inport block dialog box. On the Signal Attributes tab, Data type is set to uint8.

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

Simulation range checking

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

String truncation checking

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

Inf or NaN block output

Description
Select the diagnostic action to take if the value of a block output is Inf or NaN at the current time
step.

Note Accelerator mode does not support any runtime diagnostics.

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

"rt" prefix for identifiers

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

Max + Slope ≥ V ideal > Min − Slope

where

• Max is the maximum value representable by the parameter data type


• Min is the minimum value representable by the parameter data type
• Slope is the slope of the parameter data type (slope = 1 for integers)
• Videal is the ideal value of the parameter

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

Bits of error threshold


Set a threshold of one bit, half bit, or zero bits for parameter overflow detection

Model Configuration Pane: Diagnostics / 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

Detect precision loss

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

Max + Slope ≥ V ideal > Min − Slope

where

• Max is the maximum value representable by the parameter data type.


• Min is the minimum value representable by the parameter data type.
• Slope is the slope of the parameter data type (slope = 1 for integers).
• Videal is the full-precision, ideal value of the parameter.

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

Suppress double to single detection


Suppress the double to single parameter precision loss detection

Model Configuration Pane: Diagnostics / 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

Absolute difference threshold


Report parameter precision loss when the quantization error exceeds both absolute and relative
difference thresholds

Model Configuration Pane: Diagnostics / 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

Relative difference threshold


Report parameter precision loss when the quantization error exceeds both absolute and relative
difference thresholds

Model Configuration Pane: Diagnostics / 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

Detect loss of tunability

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:

• Simulink.Parameter objects that have a non-Auto storage class


• Simulink.Parameter objects that have the Auto storage class and are mapped to a non-
Auto storage class
• MATLAB variables that you map to a non-Auto storage class
• When the model configuration parameter Default parameter behavior (Simulink Coder) is set to
Tunable this diagnostic does not apply to variables with Auto storage class.
• The default value for Detect loss of tunability for ERT-based targets is error. When you switch
from a system target file that is not ERT-based to one that is ERT-based, Detect loss of tunability
is set to error. However, you can change the setting of Detect loss of tunability later.
• If a tunable workspace variable is modified by Mask Initialization code, or is used in an arithmetic
expression with unsupported operators or functions, the expression is reduced to its numeric
value and therefore cannot be tuned.

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

Detect read before write

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

Use local settings


For each local data store (defined by a Data Store Memory block or Simulink.Signal object in
a model workspace) use the setting specified by the block. For each global data store (defined by
a Simulink.Signal object in the base workspace) disable the diagnostic.
Disable all
Disables this diagnostic for all data stores accessed by the model.
Enable all as warnings
Displays diagnostic as a warning at the MATLAB command line.
Enable all as errors
Halts the simulation and displays the diagnostic in an error dialog box.

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

Detect write after read

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

Use local settings


For each local data store (defined by a Data Store Memory block or Simulink.Signal object in
a model workspace) use the setting specified by the block. For each global data store (defined by
a Simulink.Signal object in the base workspace) disable the diagnostic.
Disable all
Disables this diagnostic for all data stores accessed by the model.
Enable all as warnings
Displays diagnostic as a warning at the MATLAB command line.
Enable all as errors
Halts the simulation and displays the diagnostic in an error dialog box.

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

Detect write after write

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

Use local settings


For each local data store (defined by a Data Store Memory block or Simulink.Signal object in
a model workspace) use the setting specified by the block. For each global data store (defined by
a Simulink.Signal object in the base workspace) disable the diagnostic.
Disable all
Disables this diagnostic for all data stores accessed by the model.
Enable all as warnings
Displays diagnostic as a warning at the MATLAB command line.
Enable all as errors
Halts the simulation and displays the diagnostic in an error dialog box.

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

Multitask data store

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

Duplicate data store names

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

• “Local and Global Data Stores”


• Data Store Memory
• “Model Configuration Parameters: Data Validity” on page 8-2

8-51
9

Diagnostics Parameters: Type


Conversion
9 Diagnostics Parameters: Type Conversion

Model Configuration Parameters: Type Conversion Diagnostics

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

Unnecessary type conversions


Diagnostic action to take when unnecessary Data Type Conversion block is detected

Model Configuration Pane: Diagnostics / Type Conversion

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

Vector/matrix block input conversion


Diagnostic action to take when vector-to-matrix or matrix-to-vector conversion occurs at block input

Model Configuration Pane: Diagnostics / 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

Value: 'none' | 'warning' | 'error'


Default: 'none'

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

32-bit integer to single precision float conversion


Diagnostic action to take when 32-bit integer value converted to floating-point value

Model Configuration Pane: Diagnostics / 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

Model Configuration Pane: Diagnostics / Type Conversion

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

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-9
9 Diagnostics Parameters: Type Conversion

Detect precision loss


Diagnostic action to take when fixed-point constant precision loss occurs

Model Configuration Pane: Diagnostics / 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

Model Configuration Pane: Diagnostics / Type Conversion

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

Diagnostics Parameters: Connectivity


10 Diagnostics Parameters: Connectivity

Model Configuration Parameters: Connectivity Diagnostics

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

Signal label mismatch


Diagnostic action to take when signal has multiple names through propagation

Model Configuration Pane: Diagnostics / Connectivity

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

“Model Configuration Parameters: Connectivity Diagnostics” on page 10-2

10-4
Unconnected block input ports

Unconnected block input ports


Diagnostic action to take when block has unconnected input

Model Configuration Pane: Diagnostics / Connectivity

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

R2022a: The software takes no action by default


Behavior changed in R2022a

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

Unconnected block output ports


Diagnostic action to take when block has unconnected output

Model Configuration Pane: Diagnostics / Connectivity

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

R2022a: The software takes no action by default


Behavior changed in R2022a

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

Model Configuration Pane: Diagnostics / Connectivity

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

R2022a: The software takes no action by default


Behavior changed in R2022a

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

Unspecified bus object at root Outport block


Diagnostic action to take when root Outport block of referenced model does not specify bus object for
bus output

Model Configuration Pane: Diagnostics / Connectivity

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

Element name mismatch


Diagnostic action to take when bus element name does not match corresponding bus element object
name

Model Configuration Pane: Diagnostics / Connectivity

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

Bus signal treated as vector


Diagnostic action to take when virtual bus is treated as vector

Model Configuration Pane: Diagnostics / Connectivity

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.

StrictBusMsg Value Equivalent Bus signal treated as vector value


'ErrorLevel1' none
'WarnOnBusTreatedAsVector' warning
'ErrorOnBusTreatedAsVector' error

10-16
Non-bus signals treated as bus signals

Non-bus signals treated as bus signals


Diagnostic action to take when nonbus signals are treated as buses

Model Configuration Pane: Diagnostics / Connectivity

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

Repair bus selections


Diagnostic action to take when upstream bus hierarchy changes break selections

Model Configuration Pane: Diagnostics / Connectivity

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

Warn and repair


The software displays a warning and updates the Bus Selector and Bus Assignment block
parameter values to reflect upstream bus hierarchy changes.
Error without repair
The software displays an error and terminates the simulation. The error message indicates the
block parameter values that you must update for the Bus Selector and Bus Assignment blocks to
reflect upstream bus hierarchy changes.

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

Model Configuration Pane: Diagnostics / Connectivity

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

Diagnostics Parameters: Compatibility


11 Diagnostics Parameters: Compatibility

Model Configuration Parameters: Compatibility Diagnostics

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

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.

To get help on an option


1 Right-click the option text label.
2 From the context menu, select What's This.

See Also

Related Examples
• “Model Configuration Parameters: Compatibility Diagnostics” on page 11-2

11-3
11 Diagnostics Parameters: Compatibility

S-function upgrades needed


Diagnostic behavior when model contains S-function that requires updates

Model Configuration Pane: Diagnostics / 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

“Model Configuration Parameters: Compatibility Diagnostics” on page 11-2

11-5
11 Diagnostics Parameters: Compatibility

Block behavior depends on frame status of signal


Diagnostic behavior when block behavior depends on frame status of signal

Model Configuration Pane: Diagnostics / 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”.

Note Frame-based processing requires a DSP System Toolbox™ license.

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

Operating point object from a different release


Diagnostic behavior when loading initial operating point generated in different release

Model Configuration Pane: Diagnostics / 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.

Use this option to ensure the complete operating point is restored.

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

Diagnostics Parameters: Model


Referencing
12 Diagnostics Parameters: Model Referencing

Model Configuration Parameters: Model Referencing


Diagnostics

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.

Configuration Parameter Description


Model block version mismatch Diagnostic action to take when Model block does
not represent current version of referenced
model
Port and parameter mismatch Diagnostic action to take when port or parameter
does not match between Model block and
referenced model
Unsupported data logging Diagnostic action to take when data logging is
unsupported
No explicit final value for model arguments Diagnostic action to take for model argument
with default value at top-level model reference

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

Model block version mismatch


Diagnostic action to take when Model block does not represent current version of referenced model

Model Configuration Pane: Diagnostics / Model Referencing

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

Set Configuration Parameter for 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 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

Port and parameter mismatch


Diagnostic action to take when port or parameter does not match between Model block and
referenced model

Model Configuration Pane: Diagnostics / Model Referencing

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.

Set Configuration Parameter for 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

Invalid root Inport/Outport block connection


(Removed) Diagnostic action to take for invalid internal connections to root-level port blocks

Model Configuration Pane: Diagnostics / Model Referencing

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.

Set Configuration Parameter for 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 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

Identify Invalid Internal Connections

The types of invalid internal connections are:

• A root output port block connects directly or indirectly to more than one nonvirtual block port.

• A root output port block connects to a Ground block:

• Two root Outport blocks connect to the same block port.

• An Outport block connects to some elements of a block output and not others.

• An Outport block connects more than once to the same element.

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

Unsupported data logging


Diagnostic action to take when data logging is unsupported

Model Configuration Pane: Diagnostics / Model Referencing

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

Set Configuration Parameter for 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
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

No explicit final value for model arguments


Diagnostic action to take for model argument with default value at top-level model reference

Model Configuration Pane: Diagnostics / Model Referencing

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.

Set Configuration Parameter for 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

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

Diagnostics Parameters: Stateflow


13 Diagnostics Parameters: Stateflow

Model Configuration Parameters: Stateflow Diagnostics

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:

• Does not have an unconditional transition path


to a state or a terminal junction
• Has multiple transition paths leading to it
Invalid input data access in chart Select the diagnostic action to take when a chart:
initialization
• Has the ExecuteAtInitialization
property set to true
• Accesses input data on a default transition or
associated state entry actions, which execute
at chart initialization
No unconditional default transitions Select the diagnostic action to take when a chart
does not have an unconditional default transition
to a state.
Transition outside natural parent Select the diagnostic action to take when a chart
contains a transition that loops outside of the
parent state or junction.
Undirected event broadcasts Select the diagnostic action to take when a chart
contains undirected local event broadcasts.
Transition action specified before condition Select the diagnostic action to take when a
action transition action executes before a condition
action in a transition path with multiple transition
segments.
Read-before-write to output in Moore chart Select the diagnostic action to take when a
Moore chart uses a previous output value to
determine the current state.
Absolute time temporal value shorter than Select the diagnostic action to take when a state
sampling period or transition absolute time operator uses a time
value that is shorter than the sample time for the
Stateflow block.
Self transition on leaf state Select the diagnostic action to take when you can
remove a self-transition on a leaf state.

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

Unused data, events, messages, and functions


Diagnostic action to take when unused data, events, messages, and functions in a chart are detected

Model Configuration Pane: Diagnostics

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

Model Configuration Pane: Diagnostics

Description
The Unexpected backtracking parameter specifies the diagnostic action to take when a chart
junction has both of the following conditions. The junction:

• Does not have an unconditional transition path to a state or a terminal junction


• Has multiple transition paths leading to it

This chart configuration can lead to unwanted backtracking during simulation.

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

Invalid input data access in chart initialization


Diagnostic action to take when invalid input data access in chart initialization is detected

Model Configuration Pane: Diagnostics

Description
The Invalid input data access in chart initialization parameter specifies the diagnostic action to
take when a chart:

• Has the ExecuteAtInitialization property set to true


• Accesses input data on a default transition or associated state entry actions, which execute at
chart initialization

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

No unconditional default transitions


Diagnostic action to take when no uncoditional default transitions are detected

Model Configuration Pane: Diagnostics

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

Transition outside natural parent


Diagnostic action to take when a transition outside of a natural parent is detected

Model Configuration Pane: Diagnostics

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

“Transition loops outside natural parent” (Stateflow)


“Unconditional path out of state with during actions or child states” (Stateflow)

13-13
13 Diagnostics Parameters: Stateflow

Undirected event broadcasts


Diagnostic action to take when undirected event broadcasts are detected

Model Configuration Pane: Diagnostics

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

“Broadcast Local Events to Synchronize Parallel States” (Stateflow)


“Model Configuration Parameters: Stateflow Diagnostics” on page 13-2

13-15
13 Diagnostics Parameters: Stateflow

Transition action specified before condition action


Diagnostic action to take when a transition action is specified before a condition action

Model Configuration Pane: Diagnostics

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

Read-before-write to output in Moore chart


Diagnostic action to take when a Moore chart uses a previous output value to determine the state

Model Configuration Pane: Diagnostics

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

Absolute time temporal value shorter than


sampling period
Diagnostic action to take when a time value shorter than the sample time is detected

Model Configuration Pane: Diagnostics

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

Self transition on leaf state


Diagnostic action to take when a self transition on a leaf state is detected

Model Configuration Pane: Diagnostics

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

Execute-at-Initialization disabled in presence of


input events
Diagnostic action to take when triggered charts are not set to run at initialization

Model Configuration Pane: Diagnostics

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

Use of machine-parented data instead of Data


Store Memory
Diagnostic action to take when machine parented data is detected

Model Configuration Pane: Diagnostics

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

Unreachable execution path


Diagnostic action to take when an unreachable execution path is detected

Model Configuration Pane: Diagnostics

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:

• Dangling transitions not connected to a destination state, junction, or port

• 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

Hardware Implementation Parameters


14 Hardware Implementation Parameters

Hardware Implementation Pane

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.

These configuration parameters are in the Device details section.

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.

These configuration parameters are in the Advanced parameters section.

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

The following model configuration parameters have no other documentation.

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

Select the hardware board upon which to run your model.

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

Default: 'Determine by Code Generation system target file'

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

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:

• SoC (ARM CortexA)

Analog Devices options:

• ADSP–CM40x (ARM Cortex-M)


• Blackfin
• SHARC
• TigerSHARC

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

Texas Instruments options:

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

• Default hardware properties appear as the initial values.


• You cannot change parameters with only one possible value.

14-12
Device type

• Parameters with more than one possible value provide a list of valid values.

The following table lists values for each 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
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:

• Number of bits: char


• Number of bits: short
• Number of bits: int
• Number of bits: long
• Number of bits: long long
• Number of bits: float
• Number of bits: double

14-21
14 Hardware Implementation Parameters

• Number of bits: native


• Number of bits: pointer
• Largest atomic size: integer
• Largest atomic size: floating-point
• Byte ordering
• Signed integer division rounds to
• Shift right on a signed integer as arithmetic shift
• Support long long

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

Number of bits: char

Description
Describe the character bit length for the selected hardware.

Category: Hardware Implementation

Settings
Default: 8

Minimum: 8

Maximum: 32

Enter a value from 8 through 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

Number of bits: short

Description
Describe the data bit length for the selected hardware.

Category: Hardware Implementation

Settings
Default: 16

Minimum: 8

Maximum: 32

Enter a value from 8 through 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

Number of bits: int

Description
Describe the data integer bit length of the selected hardware.

Category: Hardware Implementation

Settings
Default: 32

Minimum: 8

Maximum: 32

Enter a number from 8 through 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

Number of bits: long

Description
Describe the data bit lengths for the selected hardware.

Category: Hardware Implementation

Settings
Default: 32

Minimum: 32

Maximum: 128

Enter a value from 32 through 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

Number of bits: long long

Description
Describe the length in bits of the C long long data type for the selected hardware.

Category: Hardware Implementation

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

Number of bits: float

Description
Describe the bit length of floating-point data for the selected hardware (read only).

Category: Hardware Implementation

Settings
Default: 32

Always equals 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

Number of bits: double

Description
Describe the bit-length of double data for the selected hardware (read only).

Category: Hardware Implementation

Settings
Default: 64

Always equals 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

Number of bits: native

Description
Describe the microprocessor native word size for the selected hardware.

Category: Hardware Implementation

Settings
Default: 64

Minimum: 8

Maximum: 64

Enter a value from 8 through 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

Number of bits: pointer

Description
Describe the bit-length of pointer data for the selected hardware.

Category: Hardware Implementation

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

• Specifying Production Hardware Characteristics (Simulink Coder)

14-38
Number of bits: size_t

Number of bits: size_t

Description
Describe the bit-length of size_t data for the selected hardware.

If ProdEqTarget is off, an Embedded Coder processor-in-the-loop (PIL) simulation checks this


setting with reference to the target hardware. If ProdEqTarget is on, the PIL simulation checks the
ProdBitPerSizeT setting.

Category: Hardware Implementation

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

Number of bits: ptrdiff_t

Description
Describe the bit-length of ptrdiff_t data for the selected hardware.

If ProdEqTarget is off, an Embedded Coder processor-in-the-loop (PIL) simulation checks this


setting with reference to the target hardware. If ProdEqTarget is on, the PIL simulation checks the
ProdBitPerPtrDiffT setting.

Category: Hardware Implementation

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

Largest atomic size: integer

Description
Specify the largest integer data type that can be atomically loaded and stored on the selected
hardware.

Category: Hardware Implementation

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

Value: 'Char' | 'Short' | 'Int' | 'Long' | 'LongLong'


Default: 'Char'

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

Largest atomic size: floating-point

Description
Specify the largest floating-point data type that can be atomically loaded and stored on the selected
hardware.

Category: Hardware Implementation

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.

Category: Hardware Implementation

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

Signed integer division rounds to

Description
Describe how your compiler for the hardware rounds the result of dividing two signed integers.

Category: Hardware Implementation

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.

N D Ideal N/D Zero Floor Undefined


33 4 8.25 8 8 8
-33 4 -8.25 -8 -9 -8 or -9
33 -4 -8.25 -8 -9 -8 or -9
-33 -4 8.25 8 8 8 or 9

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

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.

Category: Hardware Implementation

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

Support long long

Description
Specify that your C compiler supports the C long long data type. Most C99 compilers support long
long.

Category: Hardware Implementation

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

Model Referencing Parameters


15 Model Referencing Parameters

Model Configuration Parameters: Model Referencing

The Model Referencing pane of the Configuration Parameters dialog box allows you to specify
options for:

• Including other models in this model


• Including the current model in other models

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.

Configuration Parameter Description


Rebuild Option to conditionally, always, or never rebuild
model reference targets
Never rebuild diagnostic Diagnostic action to take when model reference
target must be rebuilt
Enable parallel model reference builds Option to build a model reference hierarchy in
parallel whenever possible
MATLAB worker initialization for builds Options for how to initialize MATLAB workers for
parallel builds
Enable strict scheduling checks for Option to check consistency of scheduling and
referenced models sample time in referenced models
Total number of instances allowed per top Number of references to this model that can
model occur in another model
Propagate sizes of variable-size signals Option to specify how variable-size signals
propagate through referenced models
Minimize algebraic loop occurrences Option to try to eliminate artificial algebraic loops
related to referenced model
Propagate all signal labels out of the model Option to pass propagated signal names out of
referenced model
Use local solver when referencing model Option to use local solver for referenced model
Model dependencies User-created files and data that potentially
impact simulation results
Perform consistency check on parallel pool Option to perform checks on parallel pool before
starting parallel build
Include custom code for referenced models Option to use custom code in model reference
simulation target

15-2
Model Configuration Parameters: Model Referencing

Configuration Parameter Description


Pass fixed-size scalar root inputs by value for Option to pass scalar input to model by reference
code generation or value

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

Model Configuration Pane: Model Referencing

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.

Set Configuration Parameter for 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
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 changes in known dependencies detected


Conditionally rebuild targets for referenced models when the software detects a change that
could affect simulation results. To reduce the time required for change detection, use this setting.

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

Conditionally Rebuild Model Reference Targets

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

For the If changes detected or If changes in known dependencies detected settings,


model reference targets rebuild when:

• A known target dependency has changed.


• A model file or library has changed and the structural checksum has changed.
• A potential target dependency trigger is detected and the structural checksum has changed.
• None of the above apply, the Rebuild setting is If changes detected, and the structural
checksum has changed.

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:

• The block simulates in software-in-the-loop (SIL) or processor-in-the-loop (PIL) mode.


• The Code interface block parameter is set to Top model.

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.

UpdateModelReferenceTargets Value Equivalent Rebuild Value


'Force' Always
'IfOutOfDateOrStructuralChange' If changes detected
'IfOutOfDate' If changes in known dependencies detected
'AssumeUpToDate' Never

15-7
15 Model Referencing Parameters

• User-written S-functions and their TLC files.


• Files specified in the Model dependencies configuration parameter.
• External files used by Stateflow, a MATLAB Function block, or a MATLAB System block.
• Dataflow subsystems – Analysis of dataflow subsystems requires that the simulation target
rebuilds to profile and rebuilds again to partition the subsystem. In addition, the simulation target
must rebuild if the machine running the simulation has fewer cores than the subsystem is
partitioned to use, for example, if the simulation target was last built on a machine with a greater
number of cores. For more information, see “Simulation of Dataflow Domains” (DSP System
Toolbox).

Potential Target Dependencies

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:

• Changes to global variables


• Changes to targets of models referenced by this model
• The Signal resolution configuration parameter when set to either Explicit and implicit or
Explicit and warn implicit

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:

• MATLAB files that contain code executed by callbacks


• MAT files that contain definitions for variables used by the model that are loaded as part of a
customized initialization script

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

R2019b: If changes detected ignores cosmetic changes


Behavior changed in R2019b

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

Never rebuild diagnostic


Diagnostic action to take when model reference target must be rebuilt

Model Configuration Pane: Model Referencing

Description
The Never rebuild diagnostic configuration parameter determines the diagnostic action to take
when a model reference target must be rebuilt.

Set Configuration Parameter for 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 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

Enable parallel model reference builds


Option to build a model reference hierarchy in parallel whenever possible

Model Configuration Pane: Model Referencing

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.

Set Configuration Parameter for 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 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

MATLAB worker initialization for builds


Options for how to initialize MATLAB workers for parallel builds

Model Configuration Pane: Model Referencing

Description
The MATLAB worker initialization for builds configuration parameter determines how to initialize
MATLAB workers for parallel builds. Parallel building requires Parallel Computing Toolbox.

Set Configuration Parameter for 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, 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

Enable strict scheduling checks for referenced


models
Option to check consistency of scheduling and sample time in referenced models

Model Configuration Pane: Model Referencing

Description
The Enable strict scheduling checks for referenced models parameter enables these checks for
referenced models:

• Scheduling order consistency of function-call subsystems in referenced export-function models


• Sample time consistency across the boundary of referenced export-function models
• Sample time consistency across the boundary of referenced rate-based models that are function-
call adapted

Set Configuration Parameter for 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
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

R2022b: Software does not enforce strict checks by default


Behavior changed in R2022b

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

Total number of instances allowed per top model


Number of references to this model that can occur in another model

Model Configuration Pane: Model Referencing

Description
The Total number of instances allowed per top model configuration parameter determines how
many references to this model can occur in another model.

Set Configuration Parameter for 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
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

• In the same hierarchy


• Multiple times in a different hierarchy

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

Propagate sizes of variable-size signals


Option to specify how variable-size signals propagate through referenced models

Model Configuration Pane: Model Referencing

Description
The Propagate sizes of variable-size signals configuration parameter determines how variable-
size signals propagate through referenced models.

Set Configuration Parameter for 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
Infer from blocks in model (default) | Only when enabling | During execution

Infer from blocks in model


Searches a referenced model and groups blocks into the following categories.

Category Description Example Blocks in This Category


1 Output signal size depends on • Switch block
input signal values. • Enabled Subsystem block with an Enable
block that sets Propagate sizes of
variable-size signals to During
execution
2 States require resetting when • Unit Delay block
the input signal size changes. • Enabled Subsystem block with an Enable
block that sets Propagate sizes of
variable-size signals to Only when
enabling

15-20
Propagate sizes of variable-size signals

Category Description Example Blocks in This Category


3 Output signal size depends on Gain block
only the input signal size.

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.

Referenced Model Contents Referenced Model Propagation of


Variable-Size Signals
One or more blocks in category 1, and all Supports During execution.
other blocks in category 3
One or more blocks in category 2, and all Supports Only when enabling.
other blocks in category 3
Blocks in category 1 and category 2 Results in error.
All blocks in category 3 with at least one Results in error. In this case, the software
conditionally executed subsystem that is not cannot determine when to propagate sizes of
an enable, function-call, or action subsystem variable-size signals.
All blocks in category 3 with only Supports both Only with enabling and
conditionally executed subsystems that are During execution.
enable, function-call, or action subsystems

Only when enabling


Propagates sizes of variable-size signals for the referenced model only when enabling (at Enable
method).
During execution
Propagates sizes of variable-size signals for the referenced model during execution (at Outputs
method).

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

Minimize algebraic loop occurrences


Option to try to eliminate artificial algebraic loops related to referenced model

Model Configuration Pane: Model Referencing

Description
The Minimize algebraic loop occurrences configuration parameter tries to eliminate artificial
algebraic loops from a model that involve the current referenced model.

Set Configuration Parameter for 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

Propagate all signal labels out of the model


Option to pass propagated signal names out of referenced model

Model Configuration Pane: Model Referencing

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.

Set Configuration Parameter for 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
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

Propagate Signal Labels out of Model

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.

Do Not Propagate Signal Labels out of Model

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.

In the referenced model, signal label propagation occurs as in any model.

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

Use local solver when referencing model


Option to use local solver to solve referenced model as separate system of equations

Model Configuration Pane: Model Referencing

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 an example, see “Improve Simulation Performance by Using Local Solvers”.

For more information about local solvers, see “Use Local Solvers in Referenced Models”.

Set Configuration Parameter for 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
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

Configure Local Solver for Component with Fast Dynamics

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.

Alternatively, use the set_param function to configure the parameters.


set_param(refmdl,UseModelRefSolver="on",...
SolverType="Fixed-Step",Solver="ode3",FixedStep="0.01")

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.

Alternatively, use the set_param function to set the CommunicationStepSize parameter.


set_param(topmdl + "/Model",CommunicationStepSize="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.

Configure Local Solver for Component with Slow Dynamics

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)

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.

Alternatively, use the set_param function to configure the parameters.

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.

This change to sample time propagation:

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

Zero-order hold Model block output ports have a


discrete sample time defined by
the Communication step size
parameter of the block.

The change in sample time can


result in different or fewer data
points in logged data for Model
block output signals in the top
model.

In rare cases, the change in


sample time can affect
numerical results as a result of:

• Applying the zero-order hold


to output signals that do not
depend on continuous states
in the referenced model
• Performing fewer parent
solver resets

R2024a: Use local solver for components with faster dynamics

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

Model Configuration Pane: Model Referencing

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.

Simulink does not automatically identify user-created dependencies. Examples of user-created


dependencies are:

• MATLAB files that contain code executed by callbacks


• MAT files that contain definitions for variables used by the model that are loaded as part of a
customized initialization script

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.

Set Configuration Parameter for 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.

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.

Cell array entries can include:

• 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

This example shows valid cell array entries.

{'D:\Work\parameters.mat', '$MDL\mdlvars.mat', ...


'D:\Work\masks\*.m'}

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

Perform consistency check on parallel pool


Option to perform checks on parallel pool before starting parallel build

Model Configuration Pane: Model Referencing

Description
The Perform consistency check on parallel pool configuration parameter determines whether to
perform checks on the parallel pool before starting a parallel build.

The software performs these criteria checks:

• The pool is spmd compatible.


• The platform is consistent between workers and client.
• The workers have a Simulink Coder license.
• The workers have write access to the current working folder.

Set Configuration Parameter for 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
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

Pass fixed-size scalar root inputs by value for code


generation
Option to pass scalar input to model by reference or value

Model Configuration Pane: Model Referencing

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.

Set Configuration Parameter for 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
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

For the diagnostic action to take when the software has to


compute the input to a function-call subsystem, see
Context-dependent inputs.

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:

• The C function prototype control is not the default.


• The C++ encapsulation interface is not the default.
• If you have a Simulink Coder license, selecting Pass fixed-size scalar root inputs by value for
code generation can affect reuse of code generated for subsystems. For more information, see
“Generate Reentrant Code from Subsystems” (Simulink Coder).
• For simulation targets, a model that references this model passes inputs by reference, regardless
of how you set the Pass fixed-size scalar root inputs by value for code generation
configuration parameter.

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

“Generate Reentrant Code from Subsystems” (Simulink Coder)


“Model Configuration Parameters: Model Referencing” on page 15-2

15-47
16

Simulation Target Parameters


16 Simulation Target Parameters

Model Configuration Parameters: Simulation Target

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.

Parameter Description Location


“GPU acceleration” on page 16- Specify whether or not to
8 accelerate MATLAB Function
blocks on NVIDIA® GPUs. This
option requires a GPU Coder
license.
“Language” on page 16-6 Specify C or C++ code
generation for simulation
targets.
“Include headers” on page 16- Specify interface header code Code information tab
11 containing types and function
declarations to import into
Simulink.
“Include directories” on page Specify directories containing Code information tab
16-15 header and source files.
“Source files” on page 16-17 Specify custom code source Code information tab
files.
“Libraries” on page 16-18 Specify a list of static and/or Code information tab
shared libraries that contain
custom object code to link into
the target.
“Defines” on page 16-19 Specify preprocessor macro Code information tab
definitions to be added to the
compiler command line.
“Compiler flags” on page 16-20 Specify additional flags to be Code information tab
added to the compiler command
line.
“Linker flags” on page 16-21 Specify additional flags to be Code information tab
added to the linker command
line.
“Initialize code” on page 16-13 Specify C/C++ code to execute Additional source code tab
at the start of simulation.
“Terminate code” on page 16- Specify C/C++ code to execute Additional source code tab
14 at the end of simulation.
“Additional code” on page 16- Specify additional custom code Additional source code tab
10 to import into Simulink.
“Simulate custom code in a Run custom code in a separate Import settings tab
separate process” on page 16- process outside of MATLAB
30 during model simulation.

16-2
Model Configuration Parameters: Simulation Target

Parameter Description Location


“Enable custom code analysis” Specify whether or not to enable Import settings tab
on page 16-9 Simulink Coverage™ and
Simulink Design Verifier support
for custom code.
“Automatically infer global Specify the behavior of global Import settings tab
variables as function interfaces” variables in custom code called
on page 16-32 by the C Caller block.
“Undefined function and Specify undefined function Import settings tab
variable handling” on page 16- behavior for all external C
28 functions called by C Caller,
MATLAB Function, MATLAB
System blocks or Stateflow
charts.
“Deterministic functions” on Specify whether custom code Import settings tab
page 16-22 functions are deterministic.
“Specify by function” on page Specify which custom code Import settings tab
16-24 functions are deterministic.
“Default function array layout” Specify the default array layout Import settings tab
on page 16-26 for all external C functions used
by the C Caller block.
“Exception by function” on page Specify the array layout for each Import settings tab
16-33 external C function used by the
C Caller block.
Target library (Simulink Coder) Specify the target deep learning
library to use for simulation.

MKL-DNN requires a Simulink


Coder license.

cuDNN or TensorRT requires a


GPU Coder license.
Auto tuning (Simulink Coder) Use auto tuning for cuDNN
library. Enabling auto tuning
allows the cuDNN library to find
the fastest convolution
algorithms.

This parameter requires


Simulink Coder and GPU Coder
licenses.

These configuration parameters are in the Advanced parameters section.

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:

• Model reference simulation targets.


• Rapid accelerator simulation targets.
• Custom code you implement with C Function blocks, C Caller blocks, MATLAB Function blocks,
MATLAB System blocks, and Stateflow charts. If Import custom code is selected, available
custom code variables and functions are parsed.

The Simulation cache folder configuration parameter determines where to save the generated C or
C++ files.

Category: Simulation Target

Settings
Default: C

C
Generates C code for simulation targets.
C++
Generates C++ code for simulation targets.

Select the C++ option to:

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

Category: Simulation Target

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

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.

Category: Simulation Target

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.

Category: Simulation Target

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.

Category: Simulation Target

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.

• Declaring header files with and without the #include directive.


• Include valid C/C++ code and declare header files without the #include directive.

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.

Category: Simulation Target

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.

Category: Simulation Target

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.

Category: Simulation Target

Settings
Default:''

Enter a space-separated list of folder paths.

• Specify absolute or relative paths to the directories.


• Relative paths must be relative to the folder containing your model files, not relative to the build
folder.
• The order in which you specify the directories is the order in which they are searched for header,
source, and library files.

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:

C:\Project "C:\Custom Files" "C:\Library Files"

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,

>> set_param('mymodel', 'SimUserIncludeDirs', ...


'C:\Project "C:\Custom Files" "C:\Library Files"')

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.

Category: Simulation Target

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.

Category: Simulation Target

Settings
Default:''

Enter a space-separated list of library files.

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.

Category: Simulation Target

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.

Category: Simulation Target

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.

Examples: -Zi -Wall, -O3, -w

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.

Category: Simulation Target

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.

Examples: -T, -MD -Gy

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.

Category: Simulation Target

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.

Category: Simulation Target

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

Default function array layout

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.

Category: Simulation Target

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

Undefined function and variable handling

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.

Category: Simulation Target

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

Simulate custom code in a separate process

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.

Category: Simulation Target

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

Automatically infer global variables as function interfaces

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.

Category: Simulation Target

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.

Category: Simulation Target

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

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.

Category: Simulation Target

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.

Category: Simulation Target

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

Signal Properties Dialog Box


17 Signal Properties Dialog Box

Data Transfer Options for Concurrent Execution

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.

To enable this tab:

1 On the Modeling tab, click Model Settings.


2 Select Solver. Under Solver details, select Allow tasks to execute concurrently on target.
3 To open the Concurrent Execution dialog box, click Configure Tasks.
4 Select Data Transfer. Use the Data Transfer Options on the right to edit options to define data
transfer between tasks.

Specify data transfer settings


Enable custom data transfer settings. For more information, see “Configure Data Transfer Settings
Between Concurrent Tasks”.

Data transfer handling option


Select a data transfer handling option. For more information, see “Configure Data Transfer Settings
Between Concurrent Tasks”.

Extrapolation method (continuous-time signals)


Select a data transfer extrapolation method. For more information, see “Configure Data Transfer
Settings Between Concurrent Tasks”.

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

Simulink Preferences Window


18 Simulink Preferences Window

Font Styles for Models

Font Styles Overview

Configure font options for blocks, lines, and annotations.

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

Simulink Mask Editor

• “Mask Editor Overview” on page 19-2


• “Dialog Control Operations” on page 19-32
• “Specify Data Types for an Edit Parameter Using Data Type Parameter” on page 19-35
• “Design a Mask Dialog Box” on page 19-41
• “Types of Mask Parameters” on page 19-48
• “Mask Callback” on page 19-50
• “Design Mask Dialog Box Layout” on page 19-52
19 Simulink Mask Editor

Mask Editor Overview


In this section...
“Parameters & Dialog Pane” on page 19-2
“Code Pane” on page 19-17
“Icon Pane” on page 19-20
“Constraints” on page 19-29
“Additional Options” on page 19-30

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,

• In the Modeling tab, under Component, click Create System Mask.


• Select the block and on the Block tab, in the Mask group, click Create Mask. The Mask Editor
opens.

To edit mask,

• On the Block tab, in the Mask group, click Edit Mask.


• Right-click the block and select Mask > 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”.

Parameters & Dialog Pane

• “Controls” on page 19-4

19-2
Mask Editor Overview

• “Dialog box” on page 19-10


• “Property editor” on page 19-10
• “Documentation Pane” on page 19-15
• “Type” on page 19-16
• “Description” on page 19-16
• “Help” on page 19-16
• “Provide a URL” on page 19-17
• “Provide a web Command” on page 19-17
• “Provide an eval Command” on page 19-17
• “Provide Literal or HTML Text” on page 19-17

The Parameters & Dialog pane enables you to design mask dialog boxes using the dialog controls in
the Parameters, Display, and Action palettes.

The Parameters & Dialog pane divided into these sections:

19-3
19 Simulink Mask Editor

Parameter & Dialog Pane

Section Section Description Sub-Section Sub-Section Description


“Controls” on page 19- Parameters are Parameter Parameters are user inputs that
4 elements in a mask take part in simulation. The
dialog box that users Parameters palette has a set of
can interact with to add parameter dialog controls that
or manipulate data. you can add to a mask dialog
box.
Container Controls on the Container
palette allows you to group
controls in the mask dialog box.
Display Controls on the Display palette
allow you to group dialog
controls in the mask dialog box
and display text and images.
Action Action controls allow you to
perform some actions in the
mask dialog box. For example,
you can click a hyperlink or a
button in the mask dialog box.
“Dialog box” on page You can click or drag NA NA
19-10 and drop dialog controls
from the palettes to the
Dialog box to create a
mask dialog box.
“Property editor” on The Property editor Properties Defines basic information on all
page 19-10 allows you to view and dialog controls, such as Name,
set the properties for Value, Prompt, and Type.
the Parameters, Attributes Defines how a mask dialog
Display, Container, control is interpreted. Attributes
and Action controls. are related only to parameters.
Dialog Defines how dialog controls are
displayed in the mask dialog
box.
Layout Defines how dialog controls are
laid out on the mask dialog box.

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.

You can associate constraints to


an Edit parameter.
Check box Accepts a Boolean value.

Popup Allows you to select a parameter


value from a list of possible
values. You can specify the
possible values for the popup
parameter using the below
options

• Options — Allows you to just


specify the list of options.
• Options with custom values
— Allows you to specify
Description and Value for
popup options. Use this option
to achieve tunability during
simulation.
• Use enumeration — Allows
you to refer an enumeration
file or build an enumeration
class for pop up options. Use
this option to achieve
simulation and code
generation tunability.
Combo box Allows you to select a parameter
value from a list of possible
values. You can also type a value
either from the list or from
outside of the list. When you
select the Evaluate check box,
the associated variable holds the
actual value of the selected item.

You can associate constraints to a


Combo box parameter.
Listbox Allows you to create a list of
parameter values. All options of
possible values are displayed on
the mask dialog box. You can
select multiple values from it.

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.

• Options — Allows you to just


specify the list of options.
• Options with custom values
— Allows you to specify
Description and Value for
radio button options. Use this
option to achieve tunability
during simulation.
• Use enumeration — Allows
you to refer an enumeration
file or build an enumeration
class for radio button options.
Use this option to achieve
simulation and code
generation tunability.
Slider Allows you to slide to values
within a range defined by
minimum and maximum values. A
Slider 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
Slider.

You can tune the values in the


linear scale or logarithmic scale
using the Scale drop-down menu

You can also control the slider


range dynamically.

Note Values specified for Slider


are auto applied.

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.

You can tune the values in the


linear scale or logarithmic scale
using the Scale drop-down
menu.

You can also control the dial


range dynamically.

Note Values specified for Dial


are auto applied.
Spinbox Allows you to spin through values
within a range defined by
minimum and maximum values.
You can specify a step size for the
values.

Note Values specified for


Spinbox are auto applied.
DataType Enables you to specify a data
type for a mask parameter. You
can associate the Min, Max, and
Edit parameters with a data type
parameter. For more details, see
“Specify Data Types for an Edit
Parameter Using Data Type
Parameter” on page 19-35.
Min Specifies a minimum value for
the edit parameter associated
with the DataTypeStr
parameter.
Max Specifies a maximum value for
the edit parameter associated
with the DataTypeStr
parameter.

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.

For more information, see


“Handling Large Number of
Mask Parameters”.
Collapsible Panel Container to group dialog
controls similar to Panel. You
can choose to expand or collapse
the CollapsiblePanel dialog
controls.
Panel Container to group of dialog
controls. You use a Panel for
logical grouping of dialog
controls. See “Design Mask
Dialog Box Layout” on page 19-
52
Mask Part Reference Container to create and save
mask parameters and dialog
controls in an XML file. You can
refer to the XML file in multiple
masked blocks to reuse the mask
parameters and dialog controls.
For more information, see “Reuse
Mask Parameters and Dialog
Controls Across Multiple Masked
Blocks”
Display
Text Text displayed in the mask dialog
box.
Image Image displayed in the mask
dialog box. The file path of the
image must be an absolute path.
Text Area Add a custom text or MATLAB
code in the mask dialog box.
Listbox Control Display the text as list on the
mask dialog box. You can select
multiple values (Ctrl + click).

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:

1 If the Evaluate option is selected, Simulink evaluates the


expression and uses the final result of the calculation. To
complete a successful evaluation, the variables of the
expression must be initialized in the model or base
workspace. For example, 'a + b' evaluates to 11 if the
variables a and b hold the values 2 and 9, respectively.
2 If the Evaluate option is not selected, Simulink takes a literal
reading of the input entry as you type it in the mask
parameter dialog box. For example, 'a + b' is read as a + b.

The Evaluate option is selected by default for the Edit, Check


Box and Popup mask parameters.

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.

If the masked parameter does not support parameter tuning,


Simulink ignores the Tunable property of the mask parameter.
Such parameters are disabled on the mask dialog box when
simulating.

The tunable options of a mask parameter are:

• off - you cannot change mask parameter values during


simulation in this mode.
• on - you can change the mask parameter value during
simulation. Each time you make a change the model is
compiled.
• run-to-run - If the mask parameter is set to run-to-run in
Fast Restart mode, the value can be changed between runs.
The model is not recompiled to reflect the value in simulation
results.

Depending on the value specified for the Tunable attribute and


the simulation mode, the mask parameter can either be read-only
or read-write.

off on run-to-run
Normal read-only read-write
Fast Restart read-only read-write read-write

For information about parameter tuning and the blocks that


support it, see “Tune and Experiment with Block Parameter
Values”.

Note During code generation, the parameter is displayed in the


generated code as a variable only when the Default parameter
behavior is set as Tunable in Code generation settings.
Read only Indicates that the parameter cannot be modified. The read-only
attribute can be used if you want to create a persistent parameter
which can hold on to certain value or data but cannot be directly
modified.
Hidden Indicates that the parameter must not be displayed in the mask
dialog box.
Never save Indicates that the parameter value never gets saved in the model
file.
Constraint Allows you to add constraints to the selected parameter.
Dialog box

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.

Provide a web Command

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:

web([docroot '/MyBlockDoc/' get_param(gcb,'MaskType') '.html'])

See the MATLAB web command documentation for details. A web command used for mask help
cannot return values.

Provide an eval Command

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.

Provide Literal or HTML Text

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

• “Initialization and Parameter Callbacks” on page 19-19


• “Rules for Initialization Commands” on page 19-19
• “Allow mask initialization code to modify subsystem's Content” on page 19-20

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:

• The masked block has icon drawing commands.

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:

• Update the diagram


• Start simulation
• Start code generation
• Click Apply on the dialog box
• Editing and saving the callback.

19-18
Mask Editor Overview

Initialization commands for an individual masked block run when you:

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

The Code pane contains the controls described in this section.

Initialization and Parameter Callbacks

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.

Rules for Initialization Commands

Following rules apply for mask initialization commands:

• 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

• Avoid prefacing variable names in initialization commands with MaskParam_L_ and


MaskParam_M_. These specific prefixes are reserved for use with internal variable names.
• Avoid using set_param commands to set parameters of blocks residing in masked subsystems
that reside in the masked subsystem being initialized. See “Dynamic Masked Subsystem” for
details.

Allow mask initialization code to modify subsystem's Content

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

• “Graphical Icon Editor” on page 19-20


• “Mask Icon Drawing Commands” on page 19-21

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 Icon Editor

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.

• Hide or unhide an element in the icon.


• Lock or unlock an element so that you do not accidentally change the shape or position of an
element while working on other elements of the icon.
• Name each element in the icon for easy identification.
• Port binding/unbinding: The number of ports on each block is pre-defined if you are creating or
modifying the block using block context. For example, the number of ports for Simscape blocks or
Aerospace blocks are pre-defined and they appear on the block icon. You can also define the
number of ports on the block icon if you are creating or modifying a block without a block context.
• Conditional visibility: Hide or unhide an element of the block based on the block parameters or
mask parameters.
• Preview options: Preview the icon in Simulink using preview options such as horizontal stretch,
flip, or scale. You can also preview the icons with modified block parameters.
• Display elements that fit the size of the icon: The first-fit feature helps you to display only the
elements that fit in the size of the icon when you resize the block.
• Position elements relatively: The auto layout constraint feature helps you to position each
element relative to other elements on the canvas.
• Text Parameterization: You can view the evaluated value of a block parameter or mask
parameter on the block icon. Enter the block parameter name or a placeholder in Parameter/Value
that will return the text or value during runtime. To see the evaluated value of a block parameter
on the block icon, preview the icon on Simulink canvas.

To know more about Graphical Icon Editor, see “Graphical Icon Editor Overview”.

Mask Icon Drawing Commands

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,

• “Block Frame” on page 19-23


• “Icon Transparency” on page 19-23
• “Icon Units” on page 19-23
• “Icon Rotation” on page 19-24
• “Port Rotation” on page 19-24

19-22
Mask Editor Overview

• “Run Initialization” on page 19-26


Block Frame

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

Mask icon drawing commands

Drawing Command Description Syntax Example Preview


color Change drawing color color('red');
of subsequent mask port_label('output
icon drawing commands ',1,'Text')
disp Display text on the disp('Gain')
masked icon.

dpoly Display transfer dpoly([0 0 1], [1


function on masked icon 2 1], 'z')

droots Display transfer droots([-1], [-2


function on masked icon -3], 4)

fprintf Display variable text fprintf('Sum =


centered on masked %d', 7)
icon
image Display RGB image on image('sine.svg')
masked icon

To add an image, select


a masked block and on
the Block tab, click
Add Image.

You can also add


multiple images to the
mask icon through
multiple image
commands.

Note The image should


be on MATLAB path.
patch Draw color patch of patch([0 10 20 30
specified shape on 30 0], [10 30 20
masked icon 25 10 10],[1 0 0])
plot Draw graph connecting plot([10 20 30
series of points on 40], [10 20 10
masked icon 15])
port_label Draw port label on port_label('output
masked icon ', 1, 'xy')

19-28
Mask Editor Overview

Drawing Command Description Syntax Example Preview


text Display text at specific text(5,10, 'Gain')
location on masked
icon.

You must select Pixels


in the Icon units box.
block_icon Promote icon of a block block_icon(BlockNa
contained in a me)
Subsystem to the
Subsystem mask Here, the icon of block
is promoted to its
Subsystem block.

For more information,


see “Draw Mask Icon
Using Mask Drawing
Commands”.

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:

• Changes are made and applied in the mask dialog box.


• Changes are made in the Mask Editor.
• Changes are done to the block diagram that affects the block appearance, such as rotating the
block.

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

Dialog Control Operations

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

Moving Dialog Controls in the Dialog box


You can move dialog controls up and down in the hierarchy using drag and drop. When you drag a
control, a cue line indicates the level in the hierarchy. Based on the type of dialog control, you can
drag and drop controls as indicated:

• 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 on it: Adds to the container as a child at the end.

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

• Drag and drop into Dialog box blank area

• The element is added to the root level node.

Cut, Copy, and Paste Controls


You can cut, copy, and paste dialog controls on the Dialog box using the context menu.

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

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.

Explore the Model

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

Associate Data Types to an Edit Parameter

The block DataTypeStr is masked and the required parameters are created. Follow these steps if
you want to create a similar model.

1. Open the masked block DataTypeStr.

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

4. Click OK in the Type Options editor to save the rules selection.

5. Click Save Mask to save the mask.

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.

Associate Data Type to an Edit Parameter Programmatically

1. Create a mask on the current model.

maskObj = Simulink.Mask.get(gcb);

2. Create edit, min, and max parameters.

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:

• The associations are defined by a.

• 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

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.

Explore the Model

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

You can add MATLAB® code as a callback for the hyperlink.

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

Types of Mask Parameters

This example shows the various mask parameters and their functionalities.

Explore the Model

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.

Explore the Model

open_system("slexMaskCallbacksExample")

19-50
Mask Callback

19-51
19 Simulink Mask Editor

Design Mask Dialog Box Layout

This example shows the various options available for designing the mask dialog box using the layout
options.

open_system("slexMaskLayoutOptionsExample.slx")

19-52
20

Concurrent Execution Window

• “Concurrent Execution Tool” on page 20-2


• “Data Transfer” on page 20-3
• “Software Node” on page 20-5
• “Hardware Node” on page 20-6
• “Periodic Trigger” on page 20-7
• “Task” on page 20-9
• “Aperiodic Trigger” on page 20-11
• “System Tasks” on page 20-14
• “System Task” on page 20-15
• “System Aperiodic Trigger” on page 20-17
• “Profile Report” on page 20-18
20 Concurrent Execution Window

Concurrent Execution Tool


In this section...
“Concurrent Execution Tool” on page 20-2
“Enable explicit model partitioning for concurrent behavior” on page 20-2

Concurrent Execution Tool

For more information, see Concurrent Execution.

Enable explicit model partitioning for concurrent behavior

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

Selecting this check box:

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

Clearing this check box

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

For more information, see Concurrent Execution.

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

For more information, see “Data Transfer”.

Periodic signals

Select the data transfer mode of synchronous signals.

Settings

Default: Ensure deterministic transfer (maximum delay)

Ensure deterministic transfer (maximum delay)


Ensure maximum capacity during data transfer.
Ensure data integrity only
Ensure maximum data integrity during data transfer.

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.

For more information, see Concurrent Execution.

Continuous signals

Select the data transfer mode of continuous signals.

Settings

Default: Ensure deterministic transfer (maximum delay)

Ensure deterministic transfer (maximum delay)


Ensure maximum capacity during data transfer.
Ensure data integrity only
Ensure maximum data integrity during data transfer.

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.

For more information, see Concurrent Execution.

Extrapolation method

Select the extrapolation method of data transfer to configure continuous-to-continuous task


transitions.

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.

For more information, see Concurrent Execution.

20-4
Software Node

Software Node

Software Node

Configure software nodes.

For more information, see “Tasks and Mapping”.

Name

Specify a unique name for software node.

Settings

Default: CPU

• Alternatively, enter a unique character vector to identify the software node. This value must be a
valid MATLAB variable.

For more information, see “Tasks and Mapping”.

20-5
20 Concurrent Execution Window

Hardware Node

Hardware Node

Configure hardware nodes.

For more information, see “Tasks and Mapping”.

Name

Specify name of hardware node.

Settings

Default: FPGAN

• Alternatively, enter a unique character vector to identify the hardware node. This value must be a
valid MATLAB variable.

For more information, see “Tasks and Mapping”.

Clock Frequency [MHz]

Specify clock frequency of hardware node.

Settings

Default: 33

For more information, see “Tasks and Mapping”.

Color

Specify the color for the hardware node icon.

Settings

Default: Next color in basic color sequence

For more information, see “Tasks and Mapping”.

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

Configure periodic (synchronous) tasks.

For more information, see “Tasks and Mapping”.

Name

Specify a unique name for the periodic task trigger configuration.

Settings

Default: Periodic

• Alternatively, enter a unique character vector to identify the periodic task trigger configuration.
This value must be a valid MATLAB variable.

For more information, see “Tasks and Mapping”.

Periodic Trigger

Specify the period of a periodic trigger

Settings

Default:

• Change ERTDefaultEvent to the actual trigger source event.

For more information, see “Tasks and Mapping”.

Color

Specify a color for the periodic trigger icon.

20-7
20 Concurrent Execution Window

Settings

Default: Blue

• Click the color picker icon to select a color for the periodic trigger icon.

For more information, see “Tasks and Mapping”.

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

The XML-format custom architecture template file defines these settings.

For more information, see “Tasks and Mapping”.

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.

For more information, see “Tasks and Mapping”.

Name

Specify a unique name for the task configuration.

Settings

Default: Task

• Alternatively, enter a unique character vector to identify the periodic task trigger configuration.
This value must be a valid MATLAB variable.

For more information, see “Tasks and Mapping”.

Period

Specify the period for the task.

Settings

Default: 1

Minimum: 0

• Enter a positive real or ratio value.

Tip

You can parameterize this value by using MATLAB expression character vectors as values.

For more information, see “Tasks and Mapping”.

Color

20-9
20 Concurrent Execution Window

Specify a color for the task icon.

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.

For more information, see “Tasks and Mapping”.

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

Configure aperiodic trigger (interrupt-driven tasks).

For more information, see “Tasks and Mapping”.

Name

Specify a unique name for the interrupt-driven task configuration.

Settings

Default: Interrupt

• Enter a unique character vector to identify the interrupt-driven task configuration. This value
must be a valid MATLAB variable.

For more information, see “Tasks and Mapping”.

Color

Specify a color for the interrupt icon.

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.

For more information, see “Tasks and Mapping”.

Aperiodic trigger source

Specify the trigger source for the interrupt-driven task.

Settings

Default: Posix Signal (Linux/VxWorks 6.x)

Posix Signal (Linux/VxWorks 6.x)


For Linux® or VxWorks® systems, select Posix Signal (Linux/VxWorks 6.x).
Event (Windows)
For Windows systems, select Event (Windows).

Dependencies

This parameter enables either Signal number [2,SIGRTMAX-SIGRTMIN-1] or Event name.

• Selecting Posix Signal (Linux/VxWorks 6.x) enables the following parameter:

Signal number [2,SIGRTMAX-SIGRTMIN-1]


• Selecting Event (Windows) enables the following parameter:

Event name

For more information, see “Tasks and Mapping”.

Signal number [2,SIGRTMAX-SIGRTMIN-1]

Enter the POSIX® signal number as the trigger source.

Settings

Default: 2

Minimum: 2

Maximum: SIGRTMAX-SIGRTMIN-1

• Enter the POSIX signal number as the trigger source.

Dependencies

Aperiodic trigger source > Posix signal (Linux/VxWorks 6.x) enables this parameter.

For more information, see “Tasks and Mapping”.

20-12
Aperiodic Trigger

Event name

Enter the name of the event as the trigger source.

Settings

Default: ERTDefaultEvent

• Change ERTDefaultEvent to the actual trigger source event.

Dependencies

Aperiodic trigger source > Event (Windows) enables this parameter.

For more information, see “Tasks and Mapping”.

20-13
20 Concurrent Execution Window

System Tasks

System Tasks

Display system tasks.

For more information, see “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

Display periodic system tasks.

For more information, see “System tasks”.

Name

Specify a default name for the periodic system task configuration.

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.

For more information, see “System tasks”.

Period

Specify the period for the task.

Settings

Default: 1

Minimum: 0

• Enter a positive real or ratio value.

Tip

• To change the name, period, or color of this task, right-click the task node and select Convert to
editable periodic task.

For more information, see “System tasks”.

20-15
20 Concurrent Execution Window

Color

Specify the outline color for the task icon.

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.

For more information, see “System tasks”.

20-16
System Aperiodic Trigger

System Aperiodic Trigger

In this section...
“System Aperiodic Trigger” on page 20-17
“Name” on page 20-17
“Color” on page 20-17

System Aperiodic Trigger

Display aperiodic system tasks.

For more information, see “System tasks”.

Name

Specify a default name for the interrupt system task.

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.

For more information, see “System tasks”.

Color

Specify the outline color for the task icon.

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.

For more information, see “System tasks”.

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

Profile Report Pane

Generate and examine profile report for model.

For more information, see “Profile report”.

Number of time steps

Specify number of time steps to generate profile report.

Settings

Default: 100

• Enter the number of time steps to collect data.

For more information, see “Profile report”.

20-18
21

Variant Manager for Simulink


21 Variant Manager for Simulink

Variant Manager for Simulink

Note This functionality requires Variant Manager for Simulink.

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

Manage Reduce Analyze

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

Install Variant Manager for Simulink


To install the support package, use one of these methods:

• Open Variant Manager:

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

Open Variant Manager


Use any of these methods to open Variant Manager:

• 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

Explore Variant Manager Window


This image shows the default view of the Variant Manager window for the slexVariantManagement
model. To open the model, run the below command from the MATLAB Command-Line.

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.

This image shows a custom layout of the window.

Manage Variant Elements


Visualize Model Hierarchy

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.

To get different views of the model hierarchy, use these tabs:

• System — Displays all blocks


• Blocks — Displays variant blocks
• Stateflow — Displays variant transitions used in Stateflow charts
• Variant Parameters — Displays variant parameters defined in the base workspace or data
dictionaries associated with the model

21-6
Variant Manager for Simulink

• Component Configurations — Displays available variant configurations for referenced


components

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.

Interact with Model Hierarchy

You can perform these actions from the model hierarchy.

Action Model Hierarchy Interaction


Edit the variant condition The Variant control expression column in the table is similar to the
expression for variant Variant control field in the block parameter dialog box of variant
blocks and transitions blocks. You can edit this field for variant elements in the hierarchy.

For variant elements, the field shows a list of context-specific keywords


that are allowed as the variant control for a variant block. For example,
for a Variant Subsystem with Variant control mode set to
expression, the list shows default in addition to the variant control
expression. For sim-codegen switching mode, the list shows sim
or codegen values. For a variant Simulink Function block, the list
shows inherit.
Edit variant parameter In the Variant Parameters tab, you can edit the
objects Simulink.VariantVariable objects available in the base
workspace or data dictionaries associated with the model.

21-7
21 Variant Manager for Simulink

Action Model Hierarchy Interaction


View variant parameters The Variant Parameters tab shows all Simulink.VariantVariable
used by model hierarchy for objects defined in the base workspace or data dictionaries associated
a configuration with the model, even if the object is not used in the model hierarchy.

To view only the variant parameters used by the model hierarchy:

• Click Update Model in the Variant Manager toolstrip to obtain


model compilation information. Parameters that are unused by the
model hierarchy for a configuration appear in italics.
• From the Show list in the Variant Parameters tab, select Used
by configuration to exclude the unused parameters in the
configuration.

21-8
Variant Manager for Simulink

Action Model Hierarchy Interaction


View variant parameters In the Variant Parameters tab, select Bank to switch to a view in
individually or grouped by which the parameters are grouped based on the variant parameter
variant parameter bank bank they belong to. The view shows parameters that are not part of
any variant bank in a separate section and groups them by variant
conditions. The Choice view shows variant parameter choices per row.

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

Action Model Hierarchy Interaction


See block parameter values Point to any variant block to see a tooltip with the block parameter
values.

21-10
Variant Manager for Simulink

Action Model Hierarchy Interaction


See context menu Right-click an element in the table to find these context-specific
options:

• 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

Action Model Hierarchy Interaction


Show or hide the usage of • To find the usage of a particular variant control variable in a variant
control variables in a configuration, select the variable in the control variables table and
configuration in the model
hierarchy click the Show usage of selected control variables button . The
rows that contain the variable appear highlighted in the model
hierarchy table.
• To hide the usage of a variant control variable, click the Hide usage

of selected control variables button .

Alternatively, right-click the variable in the control variables table and


select Show usage or Hide usage.
Navigate the model Use the Navigate list along with the buttons to step through the model
hierarchy based on filters hierarchy based on these filters:


variable usage — Use the Show previous variable usage and

Show next variable usage buttons to select the previous/next


rows in the hierarchy that uses the selected variant control
variable.

To enable the buttons, select the required variant configuration


from the Configurations tab. In the Control Variables section for
that configuration, select the control variable from the table. Click

the Show usage of selected control variables button .



active — Use the Select previous active and Select next active

buttons to select the previous/next rows in the hierarchy that


has active variant choices.

invalid — Use the Select previous invalid and Select next

invalid buttons to select the previous/next rows in the


hierarchy that has invalid variant choices.

Note: This functionality is not supported for variant parameters.


Identify active variant The inactive choice appears greyed out.
choices

Identify rows with errors They are highlighted in red.

21-12
Variant Manager for Simulink

Action Model Hierarchy Interaction


Identify type of block by the For the list of block icons, see “Model Hierarchy Table” on page 21-
block icon 19.

Manage Variant Configurations


Create and Activate Variant Configurations

A variant configuration represents a combination of variant choices across the model hierarchy. From
Variant Manager, you can:

• Create a named variant configuration.


• Create a temporary configuration in the base workspace or data dictionary used by the model.
• Add, import, export, and edit control variables in a configuration.
• Select referenced component configurations. If referenced components such as referenced models
in the model hierarchy have existing variant configurations of their own, you can use them to set
up the top-level configuration.
• Add constraints applicable for all configurations.
• Validate and activate a configuration on a model.
• Set a preferred variant configuration for a model.
• Apply a valid configuration on the model for simulation.

For an overview of variant configurations, see “Variant Configurations”.

For steps to create a variant configuration, see “Create and Activate Variant Configurations”.

For information on composing top-level configurations using referenced component configurations,


see “Compose Variant Configurations for Top Model Using Referenced Model Configurations”.

Obtain and Use Model Compilation Information in Variant Manager

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.

Auto-generate Variant Configurations

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

Save Variant Configurations

You can use a variant configuration data object of type Simulink.VariantConfigurationData to


manage and reuse variant configurations for a model. The object stores all the variant configurations
and constraints created for a model. You can define the object in the base workspace or in the
Configurations section of a data dictionary. If the model is not associated with a variant
configuration data object, Variant Manager helps you to setup a new variant configuration data
object.

From the Manage tab in Variant Manager, you can:

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

Use Variant Configurations in Simulation and Testing Workflows

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

Use Variant Manager Without Simulink Model

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

Reduce a Variant Model


You can use Variant Reducer to generate simplified, stand alone models that contains only the
specified set of variant configurations from the parent model. For example, to generate a model that
maps to a specific product from a product line (single configuration reduction), or that which
corresponds to a product line from a product line family (multi-configuration reduction).

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.

See, “Reduce Variant Models Using Variant Reducer”.

Analyze Variant Configurations


You can use Variant Analyzer to analyze and compare the variant configurations for a model. To open
Variant Analyzer, in the Variant Manager toolstrip, in the APPS section, click Variant Analyzer.

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.

See, “Analyze Variant Configurations in Models Containing Variant Blocks”.

Icons in Variant Manager


Configurations

Button Description
Add a variant configuration.

Delete a variant configuration.

Copy a variant configuration.

Control Variables

This table lists the icons used to represent different types of control variables.

Control Variable Icon Type of Control Variable


Normal MATLAB variable

Simulink.Parameter or AUTOSAR.Parameter

Simulink.VariantControl with value as normal MATLAB


variable
Simulink.VariantControl with value as Simulink.Parameter
or Simulink.VariantControl with value as a user-defined type
that inherits from Simulink.Parameter.

21-17
21 Variant Manager for Simulink

Control Variables Section

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.

Note Control variables from blocks in Label


mode are not imported because they are not
variant control variables.
Add a control variable.

Create a copy of a control variable.

Delete a control variable.

Change the data type of a control variable.

Edit Simulink.Parameter or
AUTOSAR.Parameter control variables. This
option gets activated when the selected control
variable is one of these types.

Note To specify Simulink.Parameter control


variable as an expression, set the Value property
of the parameter object by using an equal sign
(=) followed by a mathematical expression. For
example, = A + B.
Show usage of selected control variables.

Hide usage of selected control variables.

Show or hide the VAT and Source columns in the


table.
Export control variables to data sources where
the variables are stored.
Filter the table based on type of control variables.

21-18
Variant Manager for Simulink

Component Configurations Tab

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.

Model Hierarchy Table

Icon Element
Model block with Simulation mode set to Normal

Model block with Simulation mode set to Accelerator

Inline Variant Blocks (Variant Source and Variant Sink)

Variant Subsystem block

Subsystem block

Variant Model block

Subsystem Reference block

Simulink Function block

Trigger port block

Stateflow chart block

Variant Sink output port

Variant Source input port

Variant Subsystem block with Propagate conditions outside of variant


subsystem option selected.
Variant Subsystem block with Variant activation time set to update
diagram.
Variant Subsystem block with Variant activation time set to update diagram
analyze all choices.
Variant Subsystem block with Variant activation time set to code compile.

Variant Subsystem block with Variant activation time set to startup.

Variant Subsystem block with Variant activation time set to runtime.

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 Assembly Subsystem block with Variant control mode set to


expression and Variant activation time set to update diagram.
Variant Assembly Subsystem block with Variant control mode set to
expression and Variant activation time set to update diagram analyze
all choices.
Variant Assembly Subsystem block with Variant control mode set to
expression and Variant activation time set to code compile.
Variant Assembly Subsystem block with Variant control mode set to
expression and Variant activation time set to startup.
Variant Assembly Subsystem block with Propagate conditions outside of
variant subsystem option selected, Variant control mode set to
expression, and Variant activation time set to update diagram.
Variant Assembly Subsystem block with Propagate conditions outside of
variant subsystem option selected, Variant control mode set to
expression, and Variant activation time set to update diagram analyze
all choices.
Variant Assembly Subsystem block with Propagate conditions outside of
variant subsystem option selected, Variant control mode set to
expression, and Variant activation time set to code compile.
Variant Assembly Subsystem block with Propagate conditions outside of
variant subsystem option selected, Variant control mode set to
expression, and Variant activation time set to startup.
Variant Start block with Variant activation time set to update diagram.

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 activation time set to startup.

Variant Start block with Variant control mode set to label.

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 activation time set to startup.

Variant End block with Variant control mode set to label.

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

Event Listener block of Initialize Function block

Reset Function block

Event Listener block of Reset Function block

Terminate Function block

Event Listener block of Terminate Function block

Stateflow chart with Variant activation time set to code compile.

Stateflow chart with Variant activation time set to update diagram


analyze all choices.
Stateflow chart with Variant activation time set to startup.

Stateflow transition with Treat as Variant Transition option selected.

◯ Connective junction in a Stateflow chart


• Default transition in a Stateflow chart
⬤ Entry port in a Stateflow chart
⬤ Exit port in a Stateflow chart

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

Access the Variant Manager Functionality Programmatically


The Simulink.VariantManager namespace provides a set of functions to access Variant Manager
functionality from the MATLAB Command Line.

The Simulink.VariantConfigurationData class has methods to add or remove variant


configurations, constraints, and control variables programmatically.

The Simulink.VariantConfigurationAnalysis class has methods to analyze or compare


variant configurations programmatically.

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

Model Parameter Configuration Dialog


Box
22 Model Parameter Configuration Dialog Box

Model Parameter Configuration Dialog Box

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

The dialog box has the following controls.

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

Storage type qualifier


Used for code generation. For variables with a storage class other than Auto, you can add a qualifier
(such as const or volatile) to the generated storage declaration. To do so, you can select a
predefined qualifier from the list, or add qualifiers not in the list by typing them in.

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

Model Advisor Parameters


23 Model Advisor Parameters

Model Configuration Parameters: Model Advisor

Model Advisor Pane Overview


The Model Advisor pane includes parameters for selecting a model-specific Model Advisor
configuration file and enabling or disabling edit-time checking.

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.

To get help on an option


1 Right-click the option text label.
2 From the context menu, select What's This.

23-2
Model Advisor configuration file

Model Advisor configuration file


Specify Model Advisor configuration file for model

Model Configuration Pane: Model Advisor

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.

Note The parameter ModelAdvisorConfigurationFile does not exist by default.

• Use the function ModelAdvisor.setModelConfiguration to set the model configuration.


• Use the function ModelAdvisor.getModelConfiguration to get the model configuration.

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

Show Model Advisor edit-time checks


Enable Model Advisor edit-time checking for model

Model Configuration Pane: Model Advisor

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.

Note The parameter ShowAdvisorChecksEditTime does not exist by default.

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

You might also like