PowerForwardUG PDF

Low-Power Simulation Guide (CPF)
Product Version 13.10

June 2013
20062013 Cadence Design Systems, Inc. All rights reserved.

Portions Free Software Foundation, Regents of the University of California, Sun Microsystems, Inc.,
Scriptics Corporation. Used by permission.
Printed in the United States of America.
Cadence Design Systems, Inc. (Cadence), 2655 Seely Ave., San Jose, CA 95134, USA.
Product NC-SIM contains technology licensed from, and copyrighted by: Free Software Foundation, Inc., 59
Temple Place, Suite 330, Boston, MA 02111-1307 USA, and is 1989, 1991. All rights reserved. Regents
of the University of California, Sun Microsystems, Inc., Scriptics Corporation, and other parties and is
1989-1994 Regents of the University of California, 1984, the Australian National University, 1990-1999
Scriptics Corporation, and other parties. All rights reserved.
Open SystemC, Open SystemC Initiative, OSCI, SystemC, and SystemC Initiative are trademarks or
registered trademarks of Open SystemC Initiative, Inc. in the United States and other countries and are
used with permission.
Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. contained in this document
are attributed to Cadence with the appropriate symbol. For queries regarding Cadences trademarks,
contact the corporate legal department at the address shown above or call 800.862.4522. All other
trademarks are the property of their respective holders.
Restricted Permission: This publication is protected by copyright law and international treaties and
contains trade secrets and proprietary information owned by Cadence. Unauthorized reproduction or
distribution of this publication, or any portion of it, may result in civil and criminal penalties. Except as
specified in this permission statement, this publication may not be copied, reproduced, modified, published,
uploaded, posted, transmitted, or distributed in any way, without prior written permission from Cadence.
Unless otherwise agreed to by Cadence in writing, this statement grants Cadence customers permission to
print one (1) hard copy of this publication subject to the following conditions:
1. The publication may be used only in accordance with a written agreement between Cadence and its
customer.
2. The publication may not be modified in any way.
3. Any authorized copy of the publication or portion thereof must include all original copyright,
trademark, and other proprietary notices and this permission statement.
4. The information contained in this document cannot be used in the development of like products or
software, whether for internal or external use, and shall not be used for the benefit of any other party,
whether or not for consideration.
Disclaimer: Information in this publication is subject to change without notice and does not represent a
commitment on the part of Cadence. Except as may be explicitly set forth in such agreement, Cadence does
not make, and expressly disclaims, any representations or warranties as to the completeness, accuracy or
usefulness of the information contained in this document. Cadence does not warrant that use of such
information will not infringe any third party rights, nor does Cadence assume any liability for damages or
costs of any kind that may result from use of such information.
Restricted Rights: Use, duplication, or disclosure by the Government is subject to restrictions as set forth
in FAR52.227-14 and DFAR252.227-7013 et seq. or its successor.
Contents
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
For More Information
2
CPF Support
11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
CPF Support in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

General CPF Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Library Cell-Related CPF Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_hierarchy_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_design / end_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
set_sim_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
create_assertion_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
find_design_objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
identify_always_on_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Expressions in CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loop Variables Excluded from Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Feedthrough Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SystemVerilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VHDL Coding Style Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
14
24
26
27
29
29
36
38
41
42
45
47
48
54
57
3
Using CPF for Designs Using Power Shutoff. . . . . . . . . . . . . . . . . .
63
Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Base and Derived Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Declaring Boundary Ports with the -boundary_ports Option . . . . . . . . . . . . . . . . . . . 71
June 2013
4
State Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
Specifying a Constant for a Shutoff Control Expression . . . . . . . . . . . . . . . . . . . . . . . . .

Corruption of Top-Level Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Corruption of VHDL User-Defined Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . . .
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Effects of Adding an Implicit Enumeration Literal . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Corruption of VHDL Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling the Corruption of All integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling the Corruption of VHDL Integers Used as an Array Index . . . . . . . . . . . . .
Disabling the Corruption of Specific Integers With set_sim_control . . . . . . . . . . . . . .
State Loss and Forced Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disabling Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
82
83
85
87
90
90
90
94
94
95
5
State Retention
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Selecting the Targeted Registers or Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Identification of Sequential Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Specifying the Control Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Incomplete State Retention Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6
Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
117
Selecting Nets for Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ignoring Isolation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Isolation Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling Isolation Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Isolation Rule Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Isolation Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling Isolation Enable and Disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Isolation Cells With Additional Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying a Secondary Domain for an Isolation Rule . . . . . . . . . . . . . . . . . . . . . . . . . .
Isolation of Glue Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Isolation of Top-Level Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
117
120
120
127
131
131
133
134
136
136
139
June 2013
Back-to-Back Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Isolation Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logging Isolation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Isolation in SimVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Using CPF for Designs with DVFS
142
149
150
152
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Controlling a Power Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Power Mode Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Controlling Power Domain Transitions with Power Mode and Mode Transition Controls 159
Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Specifying the Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Describing the Power Mode Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Specifying the Time It Takes for Power Domain Transitions . . . . . . . . . . . . . . . . . . . 165
Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Controlling Power Domain Transitions with Domain-Level Controls . . . . . . . . . . . . . . . 172
Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Specifying the Conditions for the Power Domains to Transition to Specific Nominal
Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Specifying the Delay for a Power Domain to Reach its Destination Nominal Condition .
173
Inheritance of Active State Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Power Mode Control Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Default Power Mode Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
User-Created Power Mode Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
8
Hierarchical Flow
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Power Domain Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Instantiating the IP in the Top-Level CPF and Loading the Corresponding CPF . . . . . .
Merging the Block-Level Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling Domain Attributes after Domain Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resolving the Precedence of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
State Retention Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
June 2013
187
189
189
189
192
192
Isolation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

create_assertion_control Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
9
Modeling a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
205
Writing a CPF Model for a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Macro Model CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining the Macro Model Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modeling a Register Inside a Macro Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining State Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Explicit Code to Handle X Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPF File for the Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrating the Macro Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPF File for the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
205
207
208
213
213
215
219
219
221
224
10
Running a Low-Power Simulation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Running in Multi-Step Invocation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Simulating with irun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulating with ncverilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Command-Line Options for Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_alt_srr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_assign_ft_buf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_blackboxmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_cellrtn_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_cpf cpf_filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_dtrn_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_enum_rand_corrupt [seed] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_enum_right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_ft_graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_implicit_pso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_implicitpso_char value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_implicitpso_nonchar value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_int_index_nocorrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
June 2013
228
229
229
229
230
230
231
231
232
232
233
234
234
235
236
237
237
-lps_int_nocorrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_iso_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_iso_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_isofilter_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_isoruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_log_verbose filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_logfile filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_loopvar_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_modules_wildcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_mtrn_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_mvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_no_xzshutoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_notlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_pmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_pmcheck_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_real_nocorrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_rtn_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_rtn_full_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_rtn_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_simctrl_on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_sim_verbose report_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_srfilter_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_srruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_stdby_nowarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_stime start_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_stl_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_upcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_verbose {1 | 2 | 3} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-lps_vplan vplan_filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
238
239
239
240
241
241
242
242
243
243
244
244
245
245
246
246
247
247
248
249
250
250
251
251
252
253
254
254
255
259
259
11
Simulating an RTL-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
261
Simulating an Example Design
June 2013
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Specifying Power Information in the CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Examining Simulation Results in the Waveform Window . . . . . . . . . . . . . . . . . . . . . 267
12
Simulating a Gate-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
271
Simulating a Gate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Defining Low-Power Cells Instantiated in the Netlist . . . . . . . . . . . . . . . . . . . . . . . .
Disabling the Implicit CPF Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulating a Mixed RTL/Gate Design with Instantiated Primitive Cells . . . . . . . . . . . . .
271
272
274
275
277
13
Debugging a Low-Power Simulation (CPF). . . . . . . . . . . . . . . . . . .
279
Tcl Command Enhancements for Low Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Describing Low-Power Information for the Design . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying and Listing Low-Power Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying the Saved Value of a State Retention Variable . . . . . . . . . . . . . . . . . . . .
Probing Control Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Probing Power Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Displaying the Drivers of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Debugging Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
279
279
280
286
294
296
297
298
300
14
Advanced Low-Power Verification Features . . . . . . . . . . . . . . . . . .
303
Generating Assertions to Verify Power Control Signals . . . . . . . . . . . . . . . . . . . . . . . . .

Automatically-Generated Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Coverage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating a Verification Plan for Power Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . .
303
306
312
314
June 2013
15
Power-Aware Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Verilog System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_get_power_domain(<power_domain_register>[, <instance>]); . . . . . . . . . . . .
$lps_link_power_domain_powerdown(<link_register>
[,<power_domain>); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_standby(<link_register>[, <power_domain>]); . . . . . . . . .
$lps_link_power_domain_state(<link_register> [,<power_domain>]); . . . . . . . . . . .
$lps_link_power_domain_voltage(<link_variable>[, <power_domain>]); . . . . . . . . .
$lps_link_power_domain_gnd_voltage(<link_variable>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_nmos_voltage(<link_variable>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_pmos_voltage(<link_variable>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_nominal_condition(<link_register>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_power_mode(<link_register>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_trans_latency(<link_variable>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_link_power_domain_trans_voltage(<link_variable>
[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_enabled(); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
$lps_get_stime(); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VHDL Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lps_get_power_domain (power_domain_signal[, instance_path]); . . . . . . . . . . .
lps_link_power_domain_powerdown(link_signal[, power_domain]); . . . . . . . . . . .
lps_link_power_domain_standby(link_signal[, power_domain]); . . . . . . . . . . . . . .
lps_link_power_domain_state(link_signal[, power_domain]); . . . . . . . . . . . . . . . .
lps_link_power_domain_voltage(link_signal[, power_domain]); . . . . . . . . . . . . . .
lps_link_power_domain_gnd_voltage(link_signal[, power_domain]); . . . . . . . . . .
lps_link_power_domain_nmos_voltage(link_signal[, power_domain]); . . . . . . . . .
lps_link_power_domain_pmos_voltage(link_signal[, power_domain]); . . . . . . . . .
lps_link_power_domain_nominal_condition(link_signal
[, power_domain]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lps_link_power_domain_power_mode(link_signal[, power_domain]); . . . . . . . . . .
June 2013
319
320
322
327
332
334
339
341
342
343
346
353
355
356
357
358
359
361
368
373
375
378
380
381
382
385
388
lps_link_power_domain_trans_latency(link_signal[, power_domain]); . . . . . . . . .
lps_link_power_domain_trans_voltage(link_signal[, power_domain]); . . . . . . . . .
lps_enabled(signal_name); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
lps_get_stime(signal_name); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
391
392
393
396
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
397
June 2013
10
1
Introduction
Note: The low-power simulation functionality described in this document is available with the
Incisive Enterprise Simulator XL (IES-XL) product.
The Power Forward Initiative is an industry-wide effort to establish a single standard format
for specifying all power-specific design, constraint, and functionality requirements for a
design. This new standard, called the Common Power Format (CPF), captures all design and
technology-related power constraints in a single file. The CPF file acts as the sole repository
for all power-related information from design through verification and implementation. This
enables an entire multi-specialist project team to work from a common view of the low-power
intent of the design and ensures consistency throughout the flow.
In time, the entire Cadence verification, validation, synthesis, test, physical synthesis, routine,
analysis, and signoff tool flow will support the CPF-based methodology. Currently, CPF is
supported by the following Cadence products:
Encounter Conformal Low Power
Encounter Digital Implementation System
Encounter Power System
Encounter RTL Compiler
Encounter Test Architect
Encounter Timing System
Incisive Enterprise Manager
Incisive Enterprise Simulator
Incisive Palladium
Note: For information on the product option, feature, or package that supports CPF, contact
your local sales representative or AE.
Refer to the product documentation for information on:
June 2013
11

Introduction
How CPF is used in the tool
The tool command(s) related to CPF
When to read the CPF file in the tool flow
The CPF commands supported by the tool
For More Information

For information about the syntax and use of the Common Power Format, see the following
documents:
Common Power Format Language Reference
Common Power Format User Guide
June 2013
12
2
CPF Support
The CPF file contains commands that specify the low-power design intent at all stages of the
design and implementation process. Not all CPF commands are relevant for simulation, and
some simulation-related CPF commands are not supported in the current release.
This chapter contains information on which simulation-related CPF commands are supported
in the current release. See CPF Support in Simulation on page 14.
In many CPF commands, you specify a control condition. For example, in a
create_power_domain command, you use the -shutoff_condition option to specify
the condition when the power domain is shut off. These control conditions are indicated in the
CPF specification by using the word expression as the argument to a command option.
For example:
create_power_domain ... -shutoff_condition expression
See Expressions in CPF Commands on page 42 for information on expressions in CPF

commands.
The wildcard characters * and ? can be used in CPF commands that reference design
objects. You can use wildcard characters anywhere in a hierarchical path name. For example:
create_power_domain -name PD1 \
-instances {u_memory_block/u_*}
-instances {mcore0/ahb0 \
mcore?/*/dsu0 \
mcore*/?/dcom0 \
mcore0/as*/asm \
mcore0/uart?} \
-shutoff_condition {...}
June 2013
13

CPF Support
create_assertion_control -name ac1 \
-assertions {Adder*.A?} \
-shutoff_condition {...} \
-type ...
create_state_retention_rule -name RET_1 \
-instances {dut/*/reg*} \
-save_edge {...}
create_isolation_rule -name iso1 \
-from PDEx -to PDmain -pins {Adder1.Add1.o*} \
-isolation_condition {...} \
-isolation_output ...
Note: Using wildcard characters at the non-leaf level in a hierarchical path specified with
create_isolation_rule -pins is not recommended as this can easily result in
inadvertently selecting pins that should not be selected.
This chapter also lists some limitations in the current release. See Limitations on page 47.
CPF Support in Simulation

This section contains two tables that list all CPF commands. The table indicates which
commands and command options are applicable to simulation, and whether these
commands and options are supported in the current release.
General CPF Command Support on page 14
Library Cell-Related CPF Command Support on page 24
See the Common Power Format Language Reference for a full description of these
commands and for details on their syntax and semantics.
General CPF Command Support

In the following table, the Status column has one of the following values:
S: supported
U: unsupported
NA: not applicable to simulation
June 2013
14

CPF Support
If a command is not applicable to simulation, or if the command is not yet supported, options
to that command are not shown in the table.
Command Options
Valid in
CPF
Version
assert_illegal_domain_configurations
1.1
2.0
create_analysis_view
1.1
2.0
NA
create_assertion_control
1.1
2.0
-assertions
1.1
2.0
-domains
1.1
2.0
-exclude
1.1
2.0
-name
1.1
2.0
-shutoff_condition
1.1
2.0
-type
1.1
2.0
create_bias_net
1.1
2.0
NA
create_global_connection
1.1
2.0
create_ground_nets
1.1
2.0
NA
create_isolation_rule
1.1
2.0
-exclude
1.1
2.0
-force
--
2.0
-from
1.1
2.0
-isolation_condition
1.1
2.0
-isolation_control
--
2.0
-isolation_output
1.1
2.0
-isolation_target
1.1
2.0
-name
1.1
2.0
-no_condition
1.1
2.0
-pins
1.1
2.0
-secondary_domain
1.1
2.0
-to
1.1
2.0
June 2013
15
Support
Status
Comment
See create_assertion_control
See Isolation.
See Back-to-Back Isolation

CPF Support
Command Options
Valid in
CPF
Version
create_level_shifter_rule
1.1
2.0
create_mode
--
2.0
create_mode_transition
1.1
2.0
-assertions
--
2.0
-clock_pin
1.1
2.0
-cycles
1.1
2.0
-end_condition
1.1
2.0
-from
1.1
2.0
-illegal
--
2.0
-latency
1.1
2.0
-name
1.1
2.0
-start_condition
1.1
2.0
-to
1.1
2.0
1.1
2.0
-deep_nwell_voltage
--
2.0
-deep_pwell_voltage
--
2.0
-ground_voltage
1.1
2.0
-nmos_bias_voltage
1.1
2.0
-name
1.1
2.0
-pmos_bias_voltage
1.1
2.0
-state
1.1
2.0
-voltage
1.1
2.0
create_operating_corner
1.1
2.0
NA
create_pad_rule
--
2.0
create_nominal_condition
June 2013
16
Comment
See Describing the Power

Mode Transitions
See Defining the Nominal

Conditions
Support
Status

CPF Support
Command Options
Valid in
CPF
Version
Comment
Support
Status
create_power_domain
1.1
2.0
See Power Domains
-active_state_conditions
1.1
2.0
-base_domains
1.1
2.0
-boundary_ports
1.1
2.0
-default
1.1
2.0
-default_isolation_condition
1.1
2.0
-default_restore_edge
1.1
2.0
-default_restore_level
1.1
2.0
-default_save_edge
1.1
2.0
-default_save_level
1.1
2.0
-exclude_instances
--
2.0
-exclude_ports
--
2.0
-external_controlled_shutoff
1.1
2.0
-instances
1.1
2.0
-name
1.1
2.0
-power_down_states
--
2.0
-power_source
--
2.0
-power_up_states
1.1
2.0
-shutoff_condition
1.1
2.0
1.1
2.0
-condition
--
2.0
-default
1.1
2.0
-domain_conditions
1.1
2.0
-group_modes
1.1
2.0
-name
1.1
2.0
create_power_mode
June 2013
17
See Specifying the Power Modes

CPF Support
Command Options
Valid in
CPF
Version
create_power_nets
1.1
2.0
NA
create_power_switch_rule
1.1
2.0
create_state_retention_rule
1.1
2.0
-domain
1.1
2.0
-exclude
1.1
2.0
-instances
1.1
2.0
-name
1.1
2.0
-required
--
2.0
-restore_edge
1.1
2.0
-restore_level
1.1
2.0
-restore_precondition
1.1
2.0
-retention_precondition
--
2.0
-save_edge
1.1
2.0
-save_level
1.1
2.0
-save_precondition
1.1
2.0
-secondary_domain
1.1
2.0
-target_type
1.1
2.0
-use_secondary_for_output
--
2.0
define_library_set
1.1
2.0
NA
end_design
1.1
2.0
module
1.1
--
power_design
--
2.0
1.1
2.0
1.1
2.0
end_power_mode_control_group
1.1
2.0
find_design_objects
--
2.0
end_macro_model
macro_cell
June 2013
18
Support
Status
Comment
See State Retention for details on

this command.
Replaced with
power_design in CPF 2.0
See find_design_objects for more

information on this command.

CPF Support
Command Options
Valid in
CPF
Version
Support
Status
Comment
-direction
--
2.0
-exact
--
2.0
-hierarchical
--
2.0
-ignore_case
--
2.0
-leaf_only
--
2.0
-non_leaf_only
--
2.0
-object
--
2.0
-pattern_type
--
2.0
-regexp
--
2.0
-scope
--
2.0
get_parameter
1.1
2.0
identify_always_on_driver
1.1
2.0
-pins
1.1
2.0
-no_propagation
--
2.0
identify_power_logic
1.1
2.0
identify_secondary_domain
1.1
2.0
include
1.1
2.0
1.1
2.0
set_analog_ports
--
2.0
set_array_naming_style
1.1
2.0
set_cpf_version
1.1
2.0
1.1
2.0
file
value
June 2013
19
See identify_always_on_driver

CPF Support
Command Options
Valid in
CPF
Version
set_design
1.1
2.0
-honor_boundary_port_domain 1.1
2.0
-inout_ports
--
2.0
-input_ports
--
2.0
module
1.1
--
-modules
--
2.0
-output_ports
--
2.0
-parameters
1.1
2.0
-ports
1.1
2.0
power_design
--
2.0
-testbench
--
2.0
set_diode_ports
--
2.0
set_equivalent_control_pins
1.1
2.0
set_floating_ports
1.1
2.0
NA
set_hierarchy_separator
1.1
2.0
character
1.1
2.0
set_input_voltage_tolerance
1.1
2.0
set_instance
1.1
2.0
-design
1.1
2.0
-domain_mapping
1.1
2.0
instance
1.1
2.0
-model
1.1
2.0
-parameter_mapping
1.1
2.0
-port_mapping
1.1
2.0
1.1
2.0
See Chapter 9, Modeling a Macro S

Cell,.
-cells
--
2.0
macro_cell
1.1
2.0
--
2.0
set_macro_model
set_pad_ports
June 2013
20
Comment
Replaced with
power_design in CPF 2.0
See set_hierarchy_separator
See set_instance.
Support
Status

CPF Support
Command Options
Valid in
CPF
Version
set_power_mode_control_group
1.1
2.0
-domains
1.1
2.0
-groups
1.1
2.0
-name
1.1
2.0
set_power_source_reference_pin
--
2.0
set_power_target
1.1
2.0
NA
set_power_unit
1.1
2.0
NA
set_register_naming_style
1.1
2.0
set_sim_control
--
2.0
This command is new for CPF

2.0, but has been supported in
IES for several releases. See
set_sim_control.
-action
--
2.0
-action power_up_replay
and -action
disable_corruption are
supported.
-controlling_domain
--
2.0
-domains
--
2.0
-exclude
--
2.0
-instances
--
2.0
-lib_cells
--
2.0
-modules
--
2.0
-targets
--
2.0
In CPF 1.1, the option is -target. S

In CPF 2.0, the option is
-targets.
-type
--
2.0
-type reg, -type integer,

and -type real are supported.
set_switching_activity
1.1
2.0
NA
set_time_unit
1.1
2.0
{ms | ns | us}
1.1
2.0
set_wire_feedthrough_ports
1.1
2.0
update_design
--
2.0
June 2013
21
Support
Status
Comment

CPF Support
Command Options
Valid in
CPF
Version
update_isolation_rules
1.1
2.0
-cells
1.1
2.0
-domain_mapping
--
2.0
-location
1.1
2.0
See Isolation Placement for details. S
-names
1.1
2.0
-open_source_pins_only
1.1
2.0
-pin_mapping
--
2.0
-prefix
1.1
2.0
-suffix
--
2.0
-use_model
--
2.0
-within_hierarchy
1.1
2.0
June 2013
22
Comment
Support
Status

CPF Support
Command Options
Valid in
CPF
Version
update_level_shifter_rules
1.1
2.0
update_nominal_condition
1.1
2.0
update_power_domain
1.1
2.0
-boundary_ports
--
2.0
-deep_nwell_net
--
2.0
-deep_pwell_net
--
2.0
-equivalent_ground_nets
1.1
2.0
-equivalent_power_nets
1.1
2.0
-instances
--
2.0
-name
1.1
2.0
-nmos_bias_net
1.1
2.0
-pmos_bias_net
1.1
2.0
-primary_ground_net
1.1
2.0
-primary_power_net
1.1
2.0
-transition_cycles
1.1
2.0
-transition_latency
1.1
2.0
-transition_slope
1.1
2.0
-user_attributes
1.1
2.0
update_power_mode
1.1
2.0
NA
update_power_switch_rule
1.1
2.0
update_state_retention_rules
1.1
2.0
June 2013
23
Support
Status
Comment
See Specifying the Delay for a

Power Domain to Reach its
Destination Nominal Condition

CPF Support
Library Cell-Related CPF Command Support

In the following table, the Status column has one of the following values:
S: supported
U: unsupported
NA: not applicable to simulation
If a command is not applicable to simulation, or if the command is not yet supported, options
to that command are not shown in the table.
Command Options
define_always_on_cell
Comment
Support
Status
See Defining Always-On Cells
1.1
2.0
-cells
1.1
2.0
-ground
1.1
2.0
NA
-ground_switchable
1.1
2.0
NA
-library_set
1.1
2.0
NA
-power
1.1
2.0
NA
-power_switchable
1.1
2.0
NA
--
2.0
define_global_cell
June 2013
Valid in
CPF
Version
24

CPF Support
Command Options
define_isolation_cell
June 2013
Valid in
CPF
Version
Comment
Support
Status
See Defining Isolation Cells
1.1
2.0
-always_on_pins
1.1
2.0
-aux_enables
--
2.0
-cells
1.1
2.0
-clamp
--
2.0
-enable
1.1
2.0
-ground
1.1
2.0
NA
-ground_switchable
1.1
2.0
NA
-library_set
1.1
2.0
NA
-no_enable
1.1
2.0
NA
-non_dedicated
1.1
2.0
NA
-pin_groups
--
2.0
-power
1.1
2.0
NA
-power_switchable
1.1
2.0
NA
-valid_location
1.1
2.0
NA
25

CPF Support
Command Options
Valid in
CPF
Version
Comment
Support
Status
define_level_shifter_cell
1.1
2.0
define_open_source_input_pin
1.1
2.0
NA
define_pad_cell
--
2.0
define_power_clamp_cell
1.1
2.0
NA
define_power_clamp_pins
--
2.0
define_power_switch_cell
1.1
2.0
define_related_power_pins
1.1
2.0
NA
define_state_retention_cell
1.1
2.0
-always_on_components
1.1
2.0
-always_on_pins
1.1
2.0
-cells
1.1
2.0
-cell_type
1.1
2.0
-clock_pin
1.1
2.0
-ground
1.1
2.0
NA
-ground_switchable
1.1
2.0
NA
-library_set
1.1
2.0
NA
-power
1.1
2.0
NA
-power_switchable
1.1
2.0
NA
-restore_check
1.1
2.0
-restore_function
1.1
2.0
-retention_check
--
2.0
-save_check
1.1
2.0
-save_function
1.1
2.0
See Defining State Retention

Cells
set_hierarchy_separator
The set_hierarchy_separator command specifies the hierarchy delimiter character used in
the CPF file.
June 2013
26

CPF Support
The default hierarchy separator is the period ( . ). Other supported characters are:
slash ( / )
colon ( : )
Example
set_hierarchy_separator /
Note: The simulator interprets names that begin with the colon ( : ) as a full path rooted
within the VHDL top-level architecture. For example, if you have a VHDL architecture called
vhdl_top that contains an object called x, the full path to this object can be (assuming that
the CPF hierarchy separator is the period) either .vhdl_top.x or :x.
This command returns the current setting if no argument is specified.
set_design / end_design
These commands group a number of CPF commands that apply to the current design or top
design. The set_design command specifies the name of the module to which the power
information in the CPF file applies. In CPF 1.1, the end_design command can include the
name of the module used with set_design.
Syntax:
set_design module [-options]
[CPF commands]
end_design [module]
The -testbench option is a new option in CPF 2.0. This option applies to only the testbench
module. Using the -testbench option removes the requirement that every
set_design/end_design must include the definition of a default power domain (and, if the
design includes power modes, the definition of a default power mode). With this option
present on the command line, if a default power domain (or power mode) is not defined, an
error will not be generated.
For example, consider the following two CPF files. The example on the left includes all
commands for both the testbench and the DUT in one file. In the example on the right, the
CPF file for the testbench sources a file that contains CPF commands for the DUT. In both
cases, the -testbench option eliminates the requirement that a default power domain be
defined for the testbench scope.
June 2013
27

CPF Support
# File top.cpf
# File top.cpf
set_cpf_version 1.0e
set_design tb_top -testbench
set_design tb_top -testbench
[CPF commands for testbench.
[CPF commands for testbench.
Does not include the definition
Does not include the definition
of a default power domain.]
of a default power domain.]
set_instance dut_inst
set_instance dut_inst
set_design dut
source dut.cpf
[CPF commands for DUT.
end_design
end_design
end_design
# File dut.cpf
set_design dut
[CPF commands for DUT]
end_design
See Example 2: Carving out Different Power Domains from a Single Behavioral Model on
page 73 for another example of using the -testbench option.
The top-level module name specified with set_design varies for different tools in the flow.
For example, for simulation, the top level is the testbench, but for synthesis, it is the top of the
design. You can vary the top-level set_design parameter without changing the CPF file. To
do this:
1. Set an environment variable in the shell. For example:
(For simulation) setenv TOP testbench.dma_mac
(For implementation) setenv TOP dma_mac
2. Use the environment variable in the set_design command. The syntax is as follows:
set_design $env(environment_variable)
For example:
set_design $env(TOP)
June 2013
28

CPF Support
set_instance
Changes the scope to the specified hierarchical instance.
If no argument is specified, this command returns the current scope. If the current scope is
the top design, the hierarchy separator is returned.
The -port_mapping option is supported. This option specifies the mapping of the virtual
ports specified in the set_design -ports command to the parent-level drivers. Use the
following format to specify a port mapping:
{virtual_port parent_level_driver}
In a hierarchical design flow, a block can be implemented with a complex power structure
described in its own CPF file. The set_instance -domain_mapping option is used to
merge a block-level or macro cell power domain with another power domain at a higher level
when the block is instantiated in the higher-level design. Use the following format to specify a
domain mapping:
-domain_mapping {domain_in_child_scope domain_in_parent_level_scope}
-domain_mapping { {domain_in_child_scope domain_in_parent_level_scope} \
{domain_in_child_scope domain_in_parent_level_scope} }
See Instantiating the IP in the Top-Level CPF and Loading the Corresponding CPF on
page 189 for an example of mapping power domains in a (non-macro cell) IP block to
domains in the parent-level scope. See Integrating the Macro Model on page 221 for an
example of mapping power domains in a macro model to domains in the parent-level scope.
set_sim_control
Note: This command was officially added to the CPF 2.0 specification, but has been
supported in the simulator for several releases. It is possible to specify the CPF version as
1.1, and use this command. With 1.1, the option was -target. In CPF 2.0, the option is
-targets.
The set_sim_control command specifies an action to be taken on selected targets during
simulation when the power is switched off or restored.
In the current release, you can use this command to:
Specify a list of Verilog initial blocks in a switchable power domain that should be
re-executed when power is restored to the domain after shutoff. The option to enable this
feature is -action power_up_replay. See Replaying Initial Blocks on page 30.
Note: The set_sim_control -action power_up_replay feature is available with
June 2013
29

CPF Support
CPF 1.1 or later.
Disable the default simulation corruption semantics for specified integers, reals, or
Verilog reg type variables. The option to enable this feature is -action
disable_corruption. See Disabling Corruption of Integers, Reals, or Verilog reg
Variables on page 33.
Note: The set_sim_control -action disable_corruption feature is available
with CPF 2.0.
Replaying Initial Blocks

Initial statements are non-synthesizable code used in simulation to create proper startup
conditions at time zero of the simulation. In a low-power simulation, initial blocks in a
switchable power domain are ignored by default when the domain is powered up after shutoff.
You can use the set_sim_control command to specify a list of Verilog initial blocks in a
switchable power domain that should be re-executed when power is restored to the domain.
Syntax:
set_sim_control
[-targets initial_block_list [-exclude initial_block_list]]
-action power_up_replay
[-controlling_domain domain]
[-instances instance_list]
[-modules module_list]
The -action power_up_replay option specifies that the selected initial blocks will be
replayed immediately after power is restored to the domains where the initial blocks are
located.
Use the -targets and -exclude options to specify the list of initial blocks to be replayed
when power is restored. The argument to both options is a list of hierarchical names, each of
which refers to the label of the statement within the initial block.
The following forms of initial blocks can be referenced by label:
initial
begin: L1
<statements>
end
June 2013
30

CPF Support
initial
#5
begin: L1
<statements>
end
Note: Initial blocks with embedded labeled blocks where the outside block is not labeled are
not supported.
You can use the wildcard character in the hierarchical name. For example, the following option
specifies all initial blocks with a label that starts with L:
-targets {L*}
If the argument to -targets is the full wildcard character (-targets {*}), all initial blocks,
including blocks without labels, in the specified scope are selected.
Note: In addition to replaying all labeled and unlabeled initial blocks, the -targets {*}
option also replays variables that are initialized in their declaration statement. For example,
the following variables will be reinitialized when power is restored:
reg aaa = 1`b1;
integer delay = 10;
The -exclude option excludes the specified initial blocks from the list of blocks selected with
-targets. If a block specified with -exclude is not in the list of blocks selected with
-targets, the block is ignored. The following command selects all initial blocks whose label
starts with L, but excludes those blocks whose label starts with L1.
set_sim_control -action power_up_replay -targets {L*} -exclude {L1*}
By default, the -targets and -exclude options select initial blocks in the CPF scope where
the command is used. The -instances and -modules options let you select initial blocks
from other scopes.
-instances specifies a list of hierarchical instances from which the initial blocks will be
selected. Initial blocks are not selected from instances below the specified instances. For
example, the following options select all initial blocks with the label L in instance A.B.C
only.
-targets {L} -instances {A.B.C}
-modules specifies a list of module names. This option performs a tree search and
selects initial blocks in all instances of the specified modules under the current scope (or
the scopes selected with the -instances option). For example, the following options
select all initial blocks with the label L in all instances of modules M1 and M2.
-targets {L} -modules {M1 M2}
June 2013
31

CPF Support
You can use the * and ? wildcard characters in the module(s) specified with the
-modules option. You must use the elaborator -lps_modules_wildcard option
(ncelab -lps_modules_wildcard or irun -lps_modules_wildcard) to enable
the use of wildcard characters in the argument to the -modules option.
Caution
Be careful when using wildcards in the module_list argument to the
-modules option. The -modules option performs a tree search starting at
the current scope, or the scope specified with -instances. Every initial
block in the current scope down to the leaf scopes will be replayed. Using
a wildcard to specify the modules can result in accidentally replaying
initial blocks in unintended modules. Using a wildcard at a high-level
scope will also adversely affect elaborator performance. Use the
following guidelines when using wildcards:
Limit the scope to somewhere near the leaf of the hierarchy. This will lessen
the chance of accidentally replaying unintended modules.
Use one of the following forms: abc*, *abc, abc*def.
Using a wildcard with no qualifiers (-modules *) is strongly discouraged. This

will match every module at that scope and below.
You can use the -controlling_domain domain option to specify the power domain that
controls the initial block replay. The specified initial blocks are replayed when the domain
specified with -controlling_domain is powered up. The default controlling domain is the
power domain of the logic hierarchy containing the selected initial block.
Note: An initial block cannot be replayed unless it has completed executing. For example, the
following initial block will not be replayed because it will never stop executing.
reg xxx;
...
initial begin
xxx = 0;
forever #10 xxx = !xxx;
end
This initial block can be rewritten as follows:
June 2013
32

CPF Support
initial begin
xxx = 0;
end
always
#10 xxx = !xxx;
Examples
Replay all initial blocks with a label that starts with L in instance iSTAR only.
set_sim_control -action power_up_replay -targets {L*} -instances {iSTAR}
Replay all initial blocks, including blocks with statements that do not have a label, in instance
iSTAR only. Variables that are initialized in their declaration statement are also replayed.
set_sim_control -action power_up_replay -targets {*} -instances {iSTAR}
Replay all initial blocks, and all variables that are initialized in their declaration statement, in
all instances of module M, beginning with the current scope. The -modules option performs
a tree search.
set_sim_control -action power_up_replay -targets {*} -modules {M}
all instances of module M, beginning with the current scope, except for block L1.
set_sim_control -action power_up_replay -targets {*} -modules {M} -exclude {L1}
all instances of module M starting at instance iSTAR. This is a tree search starting at iSTAR.
set_sim_control -action power_up_replay -targets {*} -instances {iSTAR} -modules
{M}
Replay all initial blocks with a label that starts with L in modules whose names begin with RAM,
starting at scope inst_A.
set_sim_control -action power_up_replay -targets {L*} \
-instances inst_A -modules {RAM*}
Replay all initial blocks L in the current scope. This command is the same as: -targets {L}
-instances <current_scope>.
set_sim_control -action power_up_replay -targets {L}
Disabling Corruption of Integers, Reals, or Verilog reg Variables

You can use the set_sim_control command to disable the default simulation corruption
semantics for integers, reals, and Verilog reg type variables. By default, integers, reals, and
June 2013
33

CPF Support
reg type variables in a switchable power domain are corrupted when the domain is powered
down. Use the set_sim_control -action disable_corruption command to specify
a list of variables that the simulator must not corrupt when the domain is shut down.
Syntax:
set_sim_control
[-targets target_list [-exclude target_list]]
-action disable_corruption -type {real | wreal | integer | reg | module |
instance}
[-instances instance_list]
[-modules module_list]
The -action disable_corruption option specifies that the simulator must ignore the
default simulation corruption semantics for the selected targets. You must include the -type
option to specify the type of the target objects. In the current release, the only supported
arguments are:
real, which selects only real variables from the RTL
integer, which selects only integer variables from the RTL
reg, which selects only reg type variables from the RTL
For example:
set_sim_control -action disable_corruption -type reg
Use the -targets and -exclude options to specify the list of objects that should not be
corrupted when power is shut off. You can specify hierarchical names, and wildcards are
supported. For example:
# Disable corruption of integers q1, q2, and q3 in the CPF scope where the command
is used
set_sim_control -action disable_corruption -type integer \
-targets {q1 q2 q3}
# Disable corruption of all regs in scope dut3
set_sim_control -action disable_corruption -type reg \
-targets {dut3.*}
# Disable corruption of all regs in scope dut3, except q3
-targets {dut3.*} -exclude {q3}
By default, the -targets and -exclude options select objects in the CPF scope where the
command is used. The -instances and -modules options let you select objects from other
scopes.
June 2013
34

CPF Support
-instances specifies a list of hierarchical instances from which the objects will be
selected. Objects in instances below the specified instances are not selected. Instance
names can contain wildcards.
When -instances is specified, -targets is optional.
If -targets is not specified, all objects of the specified type in the specified
instances are selected.
If -targets is specified, the target objects in the specified instances are selected.
For example:
# Disable the corruption of all regs in instances tb_top.dut and dut2 only
-instances {tb_top.dut dut2}
# Disable the corruption of regs q1 and q2 in instances tb_top.dut and dut2 only
-targets {q1 q2} -instances {tb_top.dut dut2}
-modules specifies a list of module names. If this option is specified, all instances of the
specified module(s) in the current CPF scope (or the scope(s) specified with
-instances) are searched hierarchically, and objects are selected only from the
instances of the specified modules. Module names can contain wildcards.
When -modules is specified, -targets is optional.
If -targets is not specified, all objects of the specified type in all instances of the
specified modules are selected.
If -targets is specified, the target objects in all instances of the specified modules
are selected.
For example:
# Disable corruption of all regs in all instances of modules mod1 and mod2
-modules {mod1 mod2}
# Disable corruption of regs q1 and q2 in all instances of modules mod1 and mod2
-targets {q1 q2} -modules {mod1 mod2}
# Disable corruption of all regs in all instances of modules mod1 and mod2.
# Exclude reg q1 from this list
June 2013
35

CPF Support
-targets {*} -modules {mod1 mod2} -exclude {q1}
If you specify both the -instances and -modules options, all specified instances are
searched, but targets are selected only from instances of the specified modules.
# Disable corruption of all regs in all instances of module M starting at
# instance iSTAR. This is a tree search starting at iSTAR.
-targets {*} -instances {iSTAR} -modules {M}
# Disable corruption of all regs with a name that starts with reg in modules
# whose names begin with RAM, starting at scope inst_A.
-targets {reg*} -instances {inst_A} -modules {RAM*}
create_assertion_control
Turns off the evaluation of selected assertion instances related to a power domain when that
power domain is shut down. By default, assertions remain active when the power domain is
powered down.
You can control the evaluation of both SystemVerilog and PSL assertions.
The set of assertion instances to be controlled can be specified by:
Providing a list of assertion instances using the -assertions option. Assertion names
can be simple names or hierarchical names. Assertion names can contain wildcards.
Specifying a list of power domains using the -domains option. All assertions that appear
in any hierarchical instance associated with a specified power domain will be turned off.
You cannot use wildcards in the power_domain_list.
In a create_assertion_control command, the default shutoff condition for the selected

assertions is the shutoff condition specified with the -shutoff_condition option in the
create_power_domain command. However, using the power domain shutoff condition as
the assertion shutoff condition can lead to a race condition between corruption caused by
shutting off the logic in the power domain (which could cause an assertion to trigger) and the
disabling of assertions using the create_assertion_control command.
It is recommended that you use the create_assertion_control
-shutoff_condition option to specify the condition when the assertions should be
disabled. This shutoff condition should be active before the domain shuts off, and stay active
until after it powers up (the isolation enable signal, for example).
Use the -type option to specify if the selected assertions are reset or suspended when they
are turned off. The default is reset.
June 2013
36

CPF Support
Examples
In the following example, the create_assertion_control command suppresses the
evaluation of two assertion instances associated with hierarchical instance add_ef. Instance
add_ef belongs to power domain PD_add_ef. The assertions are turned off when iso_en
is enabled. The -type reset option is included to specify that the assertions should be
reset. Because reset is the default behavior, the -type option could be omitted.
create_power_domain -name PD_add_ef \
-instances {add_ef} \
-shutoff_condition {u_pmc/pso_en[2] & u_pmc/cond_3[2]}
...
...
-assertions {add_ef/SVA_A1 add_ef/SVA_A2} \
-shutoff_condition {iso_en} \
-type reset
In the following example, the create_assertion_control command suppresses the

evaluation of all assertion instances associated with all instances included in the power
domains PD_add_ab and PD_mux.
create_power_domain -name PD_add_ab \
-instances {add_ab} \
-shutoff_condition {u_pmc/pso_en[0] & u_pmc/cond_3[0] }
create_power_domain -name PD_mux \
-instances {mux} \
-shutoff_condition {u_pmc/pso_en[3] & u_pmc/cond_3[3]}
-domains {PD_add_ab PD_mux}
-shutoff_condition {iso_en} \
-type suspend
Note: Some assertions are given automatically-generated names. These include PSL
assertions derived from synthesis pragmas (for example, // synopsys full_case) and
properties that can accept parameters. You can control these assertions by specifying an
instance and using the wildcard character, or by using the -domains option, which will turn
off all assertions in the specified power domains. For example:
June 2013
37

CPF Support
-assertions {mux/*}
-domains {PD1 PD2}
Note: Immediate assertions (procedural assertions that check only a single combinational
condition) are not supported. For example, the assertion in the following code cannot be
turned off with a create_assertion_control command.
always @(posedge clk)
if (reset)
begin
temp
<= b00000000;
resetchk: assert (reset) $display("Reset is now active"); //Immediate assertion

end
else
temp
<= a + b;
find_design_objects
The find_design_objects command was introduced in CPF 2.0. This command
searches for and returns design objects that match the specified search criteria in the
specified scope. This provides a general way to select design objects which can then be used
as arguments to other CPF commands.
find_design_objects pattern_type {name | cell | module}
The -pattern_type option specifies the search string. By default, it is a Tcl glob
expression. You can use the -exact option to indicate that only objects whose names exactly
match the pattern value will be returned, or the -regexp option to indicate that the specified
pattern is a regular expression.
In the current release the supported arguments are:
name, is allowed for any type of object specified with -object. Returns objects whose
names match the pattern. name is the default.
cell, is allowed only if -object specifies inst or is omitted. Returns objects that are
instantiations of library cells whose names match the pattern.
module, is allowed only if -object specifies inst or is omitted. Returns objects that
are instantiations of modules whose names match the pattern.
See the Si2 Common Power Format Specification , Version 2.0, for a complete
description of the command and its options.
The simulator generates a warning if no objects are found.
June 2013
38

CPF Support
The -scope option specifies one or more scopes from which the search will start. When you
do not specify a scope, the search begins in the current scope. You reference only the current
scope and its children. If you specify the -scope as . (dot), the active scope is used as the
root of the search. You can specify a hierarchical list of instances, but wildcards and regular
expressions are not allowed.
The -object option specifies the type of design object to return. The supported arguments
are:
inst returns instance objects.
port returns only port objects of the modules in the current scope. When you specify
port, the -scope and -hierarchical options are ignored.
pin returns pin objects.
net returns net objects.
The -direction option specifies that only pins or ports with the specified direction are
returned. The supported arguments are in, out and inout.
The -ignore_case option performs case-insensitive searches. By default, all matches are
case sensitive.
Specify that only instances without children (-leaf_only) or with children (-non_leaf)
should be returned. This applies only if -object specifies inst or is omitted. -leaf_only
and -non_leaf are ignored when used with any object type other than inst. By default,
returns all matching inst objects.
The -hierarchical option specifies that the find_design_objects command
recursively search the specified scopes and all children of those scopes. By default, the
search applies to the specified scope only and does not include its children.
The find_design_objects command can be used inside a macro model definition (that
is, between set_macro_model and end_macro_model).
When used outside of a macro model, with the scope set to inside the macro, the command
will return only objects inside the macro. If it is used outside of a macro model and with the
-hierarchical option, the command will return objects inside the descendant macro
models.
Escape identifiers are supported.
June 2013
39

CPF Support
Examples
The following example CPF commands use the find_design_objects command to
return design objects.
In the following command, find_design_objects returns all objects of type instance
whose names match the search string add_ab in the scope in which the command is used.
create_power_domain -name PD_add_ab \
-instances [find_design_objects add_ab -pattern_type name \
-object inst] \
-shutoff_condition {...}
In the following command, find_design_objects returns all objects that are instantiations
of modules whose names match the search string Level3. The search starts at scope top
and includes all of its children.
create_power_domain -name {PD_1} \
-instances [find_design_objects Level3 -pattern_type module \
-object inst -scope top -hierarchical] \
-shutoff_condition {...} \
-base_domains {...}
In the following command, find_design_objects returns all objects of type instance

whose names start with the search string reg in the scope add_ab.
create_state_retention_rule -name SR_add_ab \
-instances [find_design_objects reg* \
-pattern_type name -object inst \
-scope add_ab] \
-restore_edge {...} \
-save_edge {...}
In the following command, find_design_objects returns all input pins in the current
scope whose names start with the search string d3.in* .
create_isolation_rule -name ISO1 \
-force -pins [find_design_objects d3.in* -object pin \
-direction in] \
-isolation_condition {...} \
-isolation_output {...}
June 2013
40

CPF Support
identify_always_on_driver
The identify_always_on_driver command was introduced in CPF 2.0. It is
implemented for Verilog, VHDL and mixed HDL designs.
identify_always_on_driver -pins {pin_list} [-no_propagation]
The identify_always_on_driver command specifies a list of input pins in the design

that must be driven by always-on buffer or inverter instances. By default, all inverter or buffer
drivers of the transitive fan-in cone for the specified pins are considered to be always-on
drivers as well.
The -no_propagation option limits the effect to a single buffer or inverter instance.
The -pins option specifies the names of top-level ports or instance pins. In the case of a pin,
it specifies the full hierarchical path of the pin.
The list of pins should translate to one or more input HDL ports. An error is issued if any item
in the list is not an HDL input port. Any input port not included in the list of pin names, but
sharing the same fan-in cone of an input port that is included in the list, is implicitely included
in the list.
Note: In this release, limitations to the identify_always_on_driver command include:
Bidirectional pins are not supported.
Port must be an input pin.
Only buffer or inverter instances can drive the specified pins.
Timing delays on inverter and buffer instances might be ignored.
Identifying Always-On Buffer or Inverter Instances

Signals connected to a buffer or inverter instance through a port map belong to the domain
of the instances parent, not to the domain of the instance itself. Many times the driver signal
is always-on but it passes through a switchable domain where the instance exists. This means
that any buffer or inverter instances added to this wire become the domain of the parent, and
therefore are corrupted when the parent powers down. The
identify_always_on_driver command allows you to designate input ports that connect
to signals that must not be corrupted, and to trace backwards through the inverter and buffer
instances until it detects a real driver.
June 2013
41

CPF Support
Impact on Simulation Behavior
Input ports are not corrupted for domain inputs when the only loads on the input ports are
identified to be always-on buffer and inverter instances.
They behave exactly like feedthrough nets without any lodes in the domain. However, if there
are other lodes in the domain, and there is a path with an odd number of inverters between
the point of entry to the domain and the exit from the domain, an artificial inverter device is
placed at the exit of the domain. This inverter device is driven by the net that drives the
corruption device at the domain input, rather than by an actual driver. This preserves the
current power shutoff simulation behavior of corrupting nets with loads.
For more information on feedthrough wires, see Feedthrough Wires on page 48.
Impact on Isolation
For isolation purposes, no buffers and inverters in the fan-in cone of the identified pins will be
considered as a driver or a load.
Expressions in CPF Commands

In many CPF commands, you specify a control condition. For example, in a
create_power_domain command, you use the -shutoff_condition option to specify
the condition when the power domain is shut off, or in a create_isolation_rule
command, you use the -isolation_condition option to specify the condition when the
specified pins should be isolated.
These control conditions are indicated in the CPF specification by using the word
expression as the argument to a command option. For example:
create_power_domain ... -shutoff_condition expression
The expression can be a complex expression (unless explicitly noted otherwise in the CPF
specification).
Verilog syntax is used in expressions.
The following restrictions apply to expressions in control conditions:
The final result of the expression evaluation must be one bit wide.
Only the following operators are allowed:
!
June 2013
logical negation
42

CPF Support
&
bit-wise binary and
bit-wise binary or
bit-wise binary xor
~^ or ^~
bit-wise binary xnor
&
reduction and
reduction or
reduction xor
For the binary operators, the operands must be one bit wide. In the following example
expressions, pse and ice are one bit wide, and pge is a 3-bit vector (pge[0:2]).
{top.pse}
{!top.pse}
{top.pge[2]}
{top.pse | top.ice}
{!top.pse | !top.ice}
{!(top.pse | top.ice)}
{top.pse | top.ice & top.pge[1]}
{(top.pse | top.ice) & top.pge[0]}
{top.pse & (!top.ice ^ top.pge[2])}
The expression is evaluated using the precedence order specified in the Verilog LRM.
From highest to lowest, the precedence order is as follows:
!
&
^
~^ or ^~
|
For example, the expression:
w | x & y ^ z
evaluates to:
w | ((x & y) ^ z)
Parentheses can be used to change the operator precedence.
June 2013
43

CPF Support
The reduction operators are unary operators whose operand is a vector, and whose
result is equivalent to applying the corresponding logical operator to each of the
elements of the vector. For example:
reg [0:1] enable;
reg [0:3] out;
{&out}
// Same as: {out[0] & out[1] & out[2] & out[3]}
{&enable | |out}
// Same as: {(enable[0] & enable[1]) | (out[0] | out[1] | out[2] | out[3])}
{&out | enable[0]}
// Same as: {(out[0] & out[1] & out[2] & out[3]) | enable[0]}
{enable[1] & ôut}
// Same as: {enable[1] & (out[0] ^ out[1] ^ out[2] ^ out[3])}
The operand of the reduction operator must be an object. The operand cannot be an
expression. For example:
June 2013
44

CPF Support
reg [0:1] a;
reg [0:3] b;
{!&a}
// Supported
{&a|&b}
// Supported. Parsed as {&a | (&b)}
{a&|b}
// Supported. Parsed as {a & (|b)}
{&!a}
// Not supported
{&(a|b)}
// Not supported
Because of confusion with the Verilog logical operators && and ||, the following
expressions generate an error stating that the && or || operator is not a legal operator
in a CPF expression:
{a||b}
// Error. Not parsed as {a | (|b)}
{a&&b}
// Error. Not parsed as {a & (&b)}
Loop Variables Excluded from Corruption

Loop variables control internal for and while loops. When a power domain is shut down,
loop variables are excluded from corruption. Both Verilog and VHDL loop variables are
disabled from corruption.
The -lps_loopvar_verbose option prints out all loop variables that are excluded from
corruption.
Note: This loop variable support sometimes causes slightly optimistic results, but it is
necessary to avoid infinite loops in simulation.
Examples
The following example excludes the variable data from corruption when used in a Verilog
while statement.
always @ (data or loc)
begin
loc = 0;
//If Data is zero, then loc is 32 (invalid value)
if (data == 0) begin
loc = 32;
end
else begin
while (data[0] == 0) begin
loc = loc + 1;
June 2013
45

CPF Support
data = data >> 1;
end
end
$display ("DATA = %b LOCATION = %d",data,loc);
end
The following example excludes the variable ch1 from corruption when used in a Verilog for
loop.
always @*
begin
no_list[0] <= 5'h00;
for (ch1 = 1; ch1 < NBCH;ch1=ch1 +1)
begin
if(active_ch[ch1])
no_list[ch1] <= ch1;
else
no_list[ch1] <= 5'
h00 | no_list[ch1-1];
end
end
The following example excludes the variable i from corruption when used in a VHDL while
loop.
Shift_3: process (Input_X)
variable i : POSITIVE := 1;
begin
L3: while i <= 8loop
Output_X(i) <= Input_X(i+8) after 5 ns;
i := i + 1;
end loop L3;
end process Shift_3;
The following example excludes the self-declared variable count_value from corruption
when used in a VHDL for loop.
Shift_5: process (Input_X)
subtype Range_Type is POSITIVE range 1 to 8;
begin
L5: for count_value in Range_Type loop
Output_X(count_value) <= Input_X(count_value +8) after 5 ns;
end loop L5;
end process Shift_5;
June 2013
46

CPF Support
Limitations
The following limitations exist in the current release:
A power domain that is subject to power shutoff can consist of Verilog instances and
VHDL components. SystemC constructs and/or data structures cannot be part of a
power-down domain. The elaborator generates a warning if it detects SystemC
constructs in a power-down domain, and the constructs are ignored.
Only digital components are supported. Verilog AMS or VHDL AMS components located
inside a power domain that is subject to power shutoff are ignored with a warning.
Only synthesizable code is supported in a power domain that is subject to power shutoff.
The current release includes support for feedthrough wires. See Feedthrough Wires on
page 48 for details on feedthrough support for Verilog, VHDL, and mixed Verilog/VHDL
designs.
The current release provides limited support for SystemVerilog constructs:
In this release, support for SystemVerilog interfaces is limited. Some aspects of the
System Verilog interfaces, such as tracing loads and drivers with the feedthrough
graph, are supported.
Do not use SystemVerilog interfaces located on a domain boundary with low power
simulation.
SystemVerilog const construct. See SystemVerilog const Constructs on page 54

for information on support for the SystemVerilog const construct.
The SystemVerilog logic data type is supported.
All other SystemVerilog data types (bit, byte, shortint, int, longint, user-defined
types, enumerated data types, structures, unions, and so on) and constructs, such as
clocking blocks, program blocks, classes, packages, and so on, are not supported and
cannot be part of a power-down domain. The elaborator generates a warning if it detects
these SystemVerilog constructs in a power-down domain, and the constructs are
ignored.
Some VHDL coding styles can have a significant effect on the accuracy of low-power
simulations. See VHDL Coding Style Recommendations on page 57 for details.
Low-power simulation behavior is done through the implicit behavior specified by CPF
commands or through the cell simulation models in the netlist. When simulating a
low-power design at the RTL level, the implicit behavior (isolation, state retention, and
power down) is provided by commands in the CPF file. When simulating a post-synthesis
netlist, the low-power behavior is provided by the cell simulation models, and the virtual
June 2013
47

CPF Support
logic implicitly modeled by the simulator must be disabled by using command-line
options (-lps_iso_off and -lps_rtn_off).
You should not instantiate low-power cells in your RTL code in some, but not all,
locations. The implicit CPF behavior is either enabled, in which case the implicit behavior
will be imposed on the inserted low-power cells, or disabled (using -lps_iso_off and
-lps_rtn_off), in which case no virtual logic will be created for sites that have no cells
inserted but that are identified as sites for low-power in the CPF file. If you must simulate
a mixed RTL/gate design, the CPF commands associated with the inserted low-power
logic cells must be either commented out or removed from the CPF file before simulating.
Feedthrough Wires
Feedthrough wires are wires that pass through a power domain without affecting, or being
affected by, logic inside the power domain. An input that does not have other readers (loads)
inside the power domain is connected to an output that does not have any other writers
(drivers) inside the domain. These wires are not corrupted when the domain is powered
down.
The wire cannot pass through any logic inside the power domain. If a wire splits inside a
power domain (that is, if the same primary input is assigned to multiple outputs), a continuous
assignment in which a primary input is directly linked to a primary output without passing
through any logic is treated as a feedthrough wire. Wires with loads inside the power domain
are corrupted.
Note: When compiling VHDL code in 3-step mode, that is, when using ncvhdl, use the
-lps_ft_graph switch. The simulator uses a feedthrough and driver/load analysis
infrastructure that requires VHDL files to be compiled with the -lps_ft_graph option
(ncvhdl -lps_ft_graph). The switch is not needed when compiling VHDL code with
irun. While some VHDL files do not require the preprocessing enabled by the
-lps_ft_graph option, Cadence recommends that the option always be used when
compiling VHDL files for low-power simulation. In the illustrations shown in this section:
= simple assignment
= driver or load
June 2013
48

CPF Support
top
dut1
D
1
DFF_Q1 D1
Q1
D2
Q2
Q3
D
3
Q4
DFF_Q3 D3
dout1
dout2
dout3
dout4
Consider the following assignment statements:

Verilog
VHDL
assign Q1 = !D1;
Q1 <= NOT D1;
assign Q2 = D2;
Q2 <= D2;
June 2013
/* Because of the load that drives to Q1,

D1 is corrupted inside dut1 when the
power domain is powered down. */
/* A continuous assignment connects a power

domain primary input to a primary output.
This continuous assignment is treated as
a feedthrough wire, and D2 is not
corrupted outside of dut1 when the power
domain is powered down. */
49

CPF Support
assign Q3 = !D3;
Q3 <= NOT D3;
assign Q4 = D3;
Q4 <= D3;
/* D3 splits inside the power domain.

Because of the load that drives to
Q3, D3 is corrupted inside dut1 when
the domain is shut down. */
/* Because there are no loads driving to Q4,

this continuous assignment is treated as
a feedthrough wire. The outside logic
directly connected to the wire is driven
directly by the driver of the wire at the
power domains primary input. */
The following types of assignment statements are identified as feedthrough wires if they meet
the restrictions noted above.
Simple assignment of input to output

Verilog
VHDL
assign outp = inp;
outp <= inp;
Bit-selects
Verilog
VHDL
assign outp[1] = inp;
outp(1) <= inp;
assign outp = inp[1];
outp <= inp(1);
assign outp[1] = inp[2];
outp(1) <= inp(2);
Part-selects
Verilog
VHDL
assign outp[1:2] = inp;
outp(1 to 2) <= inp;
assign outp = inp[5:4];
outp <= inp(5 downto 4);
assign outp[1:2] = inp[5:4];
outp(1 to 2) <= inp(5 downto 4);
Assignments with a delay

Verilog
VHDL
assign out = #1 in;
out <= in after 1ps;
Delayed assignments can be combined with non-delayed assignments.
Concatenation of signals
Note: VHDL does not allow concatenations on the left-hand side of an assignment.
June 2013
50

CPF Support
Verilog
VHDL
assign outp = {inp, inp, inp, inp};
outp <= inp & inp & inp & inp;
assign outp = {inp1, inp2, inp3, inp4};
outp <= inp1 & inp2 & inp3 & inp4;
assign out = {in[0], in[1]};
out <= in(0) & in(1);
assign out = {in1[0], in1[2], in1[3:0];
out <= in1(0) & in1(2) & in1(3 downto

0);
assign out[7:4] = {in[3:1], in[0]};
out(7 downto 4) <= a(3 downto 1) &

a(0);
assign {out1, out2} = in1;

assign {out1, out2} = {in1, in2};
Assignments using the Verilog replication operator. For example:

assign outp = { 4{inp} };
Busses with sources in multiple domains

When assigning to a bus, the inputs can come from different domains. Each bit of the bus
is analyzed separately to determine if the wire is a feedthrough. In the following example,
the path from sig3 to sig4[3] is not a feedthrough.
sig1
sig4[3:1]
sig2
sig3
Verilog
VHDL
assign sig1_tmp = sig1;
sig1_tmp <= sig1;
sig2_tmp <= sig2;
assign sig3_tmp = !sig3;
sig3_tmp <= NOT sig3;
assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp};
assign sig4[3:1] = sig_concat;
sig_concat <= sig3_tmp &

sig2_tmp & sig1_tmp;
sig4(3 downto 1) <= sig_concat;
The following is a more complicated example. In this example:
The path from sig1 to sig5 is a feedthrough.
The path from sig1 to sig4[1] is a feedthrough.
June 2013
51

CPF Support
The path from sig1 to sig6 is not a feedthrough.
The path from sig2 to sig4[2] is not a feedthrough.
sig6
sig5
sig1
sig4[3:1]
sig2
sig3
Verilog
VHDL
assign sig6 = !sig1;
sig6 <= NOT sig1;
assign sig5 = sig1;
sig5 <= sig1;
sig1_tmp <= sig1;
assign sig2_tmp = !sig2;
sig2_tmp <= NOT sig2;
sig3_tmp <= sig3;
assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp};
assign sig4[3:1] = sig_concat;
sig_concat <= sig3_tmp &

sig2_tmp & sig1_tmp;
sig4(3 downto 1) <= sig_concat;
Hierarchical connections from upper to lower modules are supported, as illustrated in the
following figure.
June 2013
52

CPF Support
PD1
PD2
PD3
O
U
T
P
U
T
S
I
N
P
U
T
S
= Feedthrough assignment
= Hierarchical connection
A continuous assignment normally behaves like a buffer. If you want to override the default
behavior of treating the forms of continuous assignment shown above as wires, use the
elaborator -lps_assign_ft_buf option. A continuous assignment will not be treated as a
feedthrough, and the net will be forced to X when the domain is powered down.
Feedthrough Values Displayed in SimVision
As explained above, if a wire splits inside a power domain (that is, if the same primary input
is assigned to multiple outputs), a continuous assignment in which a primary input is directly
linked to a primary output without passing through any logic is treated as a feedthrough wire.
Wires with loads inside the power domain are corrupted. In the following example, the path
June 2013
53

CPF Support
from D3 to Q4 is a feedthrough, but the path from D3 to Q3 is not a feedthrough, and D3 is
corrupted inside the module when the domain is shut down.
Q3
D3
Q4
Corruption occurs at the input. In the current implementation, SimVision (and Tcl commands)
will also display the feedthrough wire as corrupted. However, for the feedthrough wire, the
outside logic directly connected to the wire is driven directly by the driver of the wire at the
power domains primary input. In other words, inside the module, D3 will be shown as
corrupted, but Q4 will have the correct value.
SystemVerilog Interfaces
Note: In this release, support for SystemVerilog interfaces is limited. Some aspects of the
System Verilog interfaces, such as tracing loads and drivers with the feedthrough graph, are
supported.
Do not use SystemVerilog interfaces located on a domain boundary with low power
simulation.
SystemVerilog const Constructs
The SystemVerilog const construct specifies that the left-hand-side is assigned to a
constant value. For example,
const logic var1 = 1'b1;
assign abc = var1;
This is similar to the following Verilog assignment command:

assign abc = 1'b1;
The simulator does not corrupt const variables. Wires or nets connected to a const variable
are restored after power up.
Interfaces at the Power Domain Boundary
In this case, an interface is used to connect module instances that are defined to be in
different power domains. For example, consider the following HDL hierarchy:
June 2013
54

CPF Support
tbench
dut
intf_inst
// Interface instance
inst1(intf_inst)
// Module instance (in power domain PD1)
inst2(intf_inst)
// Module instance (in power domain PD2)
u_pmc
The Verilog code is as follows:
June 2013
55

CPF Support
interface myintf;
wire a, b, c, d;
modport master (input a, b, output c, d);
modport slave (output a, b, input c, d);
endinterface
module m (myintf.master i);
...
endmodule
module s (myintf.slave i);
...
endmodule
module dut;
myintf intf_inst();
m inst1(.i(intf_inst));
s inst2(.i(intf_inst));
endmodule
In this example, inst1 and inst2 are module instances connected through interface
instance intf_inst. The instances inst1 and inst2 have been defined as power
domains in the CPF file, as follows:
set_design dut
create_power_domain -name topdmn -default
-instances inst1 \
-shutoff_condition {u_pmc.pso_en[0]}
-instances inst2 \
end_design
Interfaces within a Power Shut Off Domain

In this case, the interface is within a power domain. For example:
June 2013
56

CPF Support
tbench
dut
// Power domain PD1

intf_inst
// Interface instance
inst1(intf_inst)
// Module instance
inst2(intf_inst)
// Module instance
u_pmc
In this example, inst1 and inst2 are module instances connected through interface
instance intf_inst. The power domain defined in the CPF surrounds the dut instance.
set_design dut
create_power_domain -name topdmn -default
create_power_domain -name maindmn \
-instances dut \
end_design
Referring to Design Objects in an Interface

Commands in the CPF file can refer to the interface and modport ports. Because an interface
instance introduces a scope, the hierarchical path to an object in an interface must include
the interface instance name. For example:
intf_inst.req
// Signal req in the interface instance
VHDL Coding Style Recommendations

This section presents some coding styles that have a significant effect on the accuracy of
low-power simulations when subjected to unknown (X or U) situations. The following
restrictions apply only to the DUT, not to the testbench or behavioral models.
Data Constructs
The use of any data type other than std_logic or std_ulogic is not supported. This is
necessary because only these data types can assume the value of U (undefined).
All internal signals and FFs in a chip (DUT) must initially start at U, and then come out of this
undefined state in a predictable manner as the reset signal is applied. If integers, enumerated
data types, or user data types are used in the DUT, these data types will assume their default
states (0, left-hand element, and so on) when going through power shutdown instead of being
June 2013
57

CPF Support
injected with unknowns (X). Consequently, the simulation will not accurately predict the silicon
behavior when going through power shutoff, and the behavior must be verified some other
way.
Troublesome Constructs
Some VHDL constructs can lead to overly optimistic results.
Constrained array type declarations

type MEMORY is array (0 to 1023) of INTEGER;
variable RAM : MEMORY;
Subtype declarations
subtype MEM_ADR is INTEGER range 0 to 1023;
Unconstrained array type

type WORD_32 is array 31 downto 0 of BIT ;
type MEMORY is array ( POSITIVE range <> ) of WORD_32 ;
signal FAST_MEM : MEMORY ( 0 to 1023 );
Note: The integer and bit data types used in the examples above cannot be corrupted
during power shutoff because the default value for each is 0 (integer) or 0 (bit).
Enums
If a state machine has been designed with the states defined as enums, and the reset state
is listed in the left-most position, it will be impossible to detect a reset problem. This is
because any time the state is undefined, it will assume the left-most value in the enum
description. Consequently, the result will be an appearance of being reset. To avoid this
problem, the reset state should be listed in any position except the left-most element.
Constants
Another limitation is the restoration of constants when a powered-down domain is powered
up. The simulator supports simple constant expressions as shown in the following example.
June 2013
58

CPF Support
library ieee;
use ieee.std_logic_1164.all;
entity SUB_A is
generic (G1 : integer := 3);
port (out1 : out std_logic;
out2, out6 : out integer;
out3, out4 : out std_logic_vector(3 downto 0);
out5 : out std_logic_vector(4 downto 0));
end entity SUB_A;
architecture RTL of SUB_A is
begin
out1 <= '1';
-- Scalar constant
out2 <= 2;
-- Integer
out3 <= "1100";
-- Vector
out4 <= (others => '1');
-- Aggregate onstant definition
out5(4 downto 2) <= "010";
-- Part-select / Bit-select
out6 <= G1;
-- Assignment from generics
end architecture RTL;
The above constants are recognized by the VHDL simulator, and will be powered down and
restored correctly. However, in both Verilog and VHDL, there are many ways of writing RTL
code that synthesizes down to a constant. Currently, the simulator does not recognize any
form of a constant expression except for the simple cases shown above.
Type Conversions
Type conversions are commonly found in VHDL code. The following type conversions are not
supported for low-power simulations:
std_logic <=> integer
std_logic <=> real
real <=> std_logic
June 2013
59

CPF Support
real <=> integer
time <=> integer
real <=> time
signed_int <=> integer
unsigned_int <=> integer
std_ulogic <=> integer
std_ulogic <=> real
std_logic <=> natural
std_logic <=> positive
std_ulogic <=> natural
std_ulogic <=> positive
converting to type integer using std_logic_arith::conv_integer ()
Processes that Use Variables of Type Integer
In the example below, Q is an integer that changes on the rising edge of Clk. If the circuit
powers down while Q is changing, Q will not be corrupted because it is an integer. This could
cause differences between simulation and silicon. If Q was of type std_logic, this example
would work correctly after power up.
entity count16 is
port (Clk, Rst, Load : in std_ulogic;
Data : in std_ulogic_vector(3 downto 0);
Count : out std_ulogic_vector(3 downto 0));
end entity count16;
architecture count16a of count16 is
begin
process(Rst,Clk)
variable Q: integer range 0 to 15;
begin
if Rst = '1' then
-- Asynchronous reset
Q := 0;
June 2013
60

CPF Support
elsif rising_edge(Clk) then
if Load = '1' then
Q := to_uint(Data);
-- Convert vector to integer
elsif Q = 15 then
Q := 0;
else
Q := Q + 1;
end if;
end if;
Count <= to_vector(4,Q);
-- Convert integer to vector

-- for use outside the process
end process;
end architecture count16a;
June 2013
61

CPF Support
June 2013
62
3
Using CPF for Designs Using Power
Shutoff
Power Shutoff (PSO), also called power gating, is one of the most effective power
management techniques for reducing power. In PSO, selected functional blocks of the chip
are individually powered down when they are not in use to save leakage and dynamic power.
Logic blocks (hierarchical instances), leaf instances, and pins that use the same main power
supply and that can be simultaneously switched on or off are said to belong to the same
power domain. The example design in Figure 3-1 has three power domains:
The top-level of the design, top, and hierarchical instances, inst_C and pm_inst, are
always switched on: They belong to power domain PD1.
Hierarchical instances inst_A and inst_B are always switched on and off
simultaneously: They belong to power domain PD2.
Hierarchical instance inst_D can be switched on and off independently from

hierarchical instances inst_A and inst_B: It belongs to power domain PD3.
June 2013
63

Using CPF for Designs Using Power Shutoff
Figure 3-1 Example of Design with PSO
top
PD1
PD2
inst_A
inst_B
PD3
inst_C
inst_D
pm_inst
pge_enable
ice_enable
pse_enable
See Power Domains on page 66 for information on specifying power domains in the CPF
file.
When a power domain is powered down, all signals and wires within the shutdown region
transition to the unknown state. All sequential elements (registers) and variables within the
powered-down region lose their state and are forced to the logic value X for the entire shutoff
period. This behavior is referred to as state loss or corruption. See Chapter 4, State Loss
for more information.
When a power domain is powered down, the states of certain sequential elements (registers,
latches, flip-flops) in the power domain must be saved and retained for the entire shutoff
period. When the power domain is powered back up, the saved states must be written back
into the registers. To ensure that a powered-down block resumes normal operation after
power up, these sequential elements can be replaced by special state retention cells. See
Chapter 5, State Retention for information on specifying state retention rules in the CPF file.
June 2013
64

To prevent floating, unpowered signals (represented by the logic value X) in a power domain
that is powered down from propagating to a power domain that remains on, the outputs of
blocks being powered down need to be isolated before power can be switched off, and they
need to remain isolated until after the block has been fully powered up. To accomplish this
isolation, isolation cells are placed between the two power domains. Most of the time,
isolation cells are inserted at the output boundaries of the powered down domains. In some
cases, isolation cells may need to be placed at the block inputs to prevent connection to
powered-down logic. See Chapter 6, Isolation for information on specifying isolation rules in
the CPF file.
Special control signals are used to shut down a power domain and to enable state retention
and isolation. The following table shows the control signals used in the example.
Control Signals
Power Domain
power switch
isolation
state retention
PD1
no control signal
no control signal
no control signal
PD2
ps_enable[0]
ice_enable[0]
pge_enable[0]
PD3
ps_enable[1]
ice_enable[1]
pge_enable[1]
Accurate PSO simulation behavior depends on the correct transition sequence of the power
control signals for both power-down and power-up cycles.
Power-down
1. Isolation signal is asserted. The simulator forces all outputs of the block to the specified
CPF values.
2. State retention control is asserted. The current values of all retention flops specified in
the CPF are saved.
3. Power shutoff signal is asserted. The power domain is powered down, forcing all internal
design elements to X.
Power-up
4. Power shutoff signal is deasserted. The power domain is powered up.

5. State retention control is deasserted. Retained values in the retention flops are restored.
6. Isolation signal is deasserted. Isolation values forced on the outputs are removed.
See Generating Assertions to Verify Power Control Signals on page 303 for details on the
correct transition sequence of the power control signals, and for information on the
June 2013
65

-lps_verify command-line option you can use to automatically generate assertions that
check for the correct sequence of control signals during simulation.
Power Domains
A power domain is a collection of instances, pins, and ports that share the same power
distribution network and that either can be simultaneously switched on or off, or treated as
always on.
A power domain is defined in the CPF file with a create_power_domain command. This
command creates a power domain and specifies the instances and boundary ports and pins
that belong to the domain.
The following create_power_domain commands define the power domains for the
example shown in Example of Design with PSO on page 64.
create_power_domain -name PD1 -default
create_power_domain -name PD2 -instances {inst_A inst_B} \
-shutoff_condition {pse_enable[0]}
create_power_domain -name PD3 -instances inst_D \
-shutoff_condition {pse_enable[1]}
See the Common Power Format Language Reference for a complete description of the
create_power_domain command.
Power domains are scope-specific. If you change the scope to a hierarchical instance (using
the set_instance command), a power domain definition applies to only that hierarchical
instance or to the instances (children) of that hierarchical instance.
The -instances option specifies the instances that belong to the power domain.
Instances referred to in a create_power_domain command between a set_design

and end_design pair can be hierarchical instances or instances of a macro cell.
Instances referred to in a create_power_domain command between a

set_macro_model and end_macro_model pair can be registers in the behavioral
model of the macro cell. See Defining the Macro Model Power Domains on page 208
for more information.
One (and only one) power domain must be specified as the default power domain with the
-default option. All instances of the design that are not associated with a specific power
domain belong to the default power domain.
June 2013
66

The -shutoff_condition option specifies the condition when the power domain is shut
off. If you do not specify a shutoff condition, the power domain is considered to be always on.
A switchable power domain can be:
Internal switchable. This domain can be powered down by an on-chip power or ground
switch. The domain derives its power from another domain through a power switch
network.
To model an internal switchable domain, use the -shutoff_condition option to
specify the shutoff condition, and the -base_domains option to specify the domain(s)
from which the switchable domain gets its power supply. See Base and Derived Power
Domains on page 67 for more information.
Note: In CPF 1.1, the switchable domain is referred to as a derived domain, and the
domains from which the derived domain gets its power supply are referred to as base
domains. The base domains are specified with the -base_domains option. In CPF
1.0e, the domains were referred to as primary and secondary domains, respectively,
and you specified the secondary domains with the -secondary_domains option. In
CPF 1.1, the -secondary_domains option has been renamed to -base_domains.
On-chip controlled external switchable. This domain can be powered down by an

external power switch (outside of the chip), but the external switch is controlled by signals
on the chip.
To model an on-chip controlled external switchable domain, use the -shutoff
condition option with the -external_controlled_shutoff option.
Use the -boundary_ports option to specify a list of inputs and outputs that are considered
part of the power domain. Boundary ports can only be specified for the primary inputs or
outputs of the top-level DUT or of a macro model. See Declaring Boundary Ports with the
-boundary_ports Option on page 71 for details on this option.
Base and Derived Power Domains

In CPF, a power domain can be defined as a base domain of another power domain (referred
to as the derived domain). A base domain is defined as follows:
A power domain X is a base power domain of power domain Y if the primary power and
ground nets of power domain X provide the power supply to domain Y through some
power switch network.
Defining a base domain lets you:
Model the secondary pin of a physical cell.
June 2013
67

Shut off the derived domain when the base domain is powered down.
Share the power switches of the base domain.
Simplify the power domain shutoff conditions specified in the CPF file.
In CPF, you define the power domains with create_power_domain commands. Use the
-base_domains option to specify a list of the base domains that supply external power to
the derived power domain. The derived domain is powered down if either its shutdown
condition is true or if all of its base power domains are switched off.
In Figure 3-2 on page 68, power domain PD is defined as the base power domain of domain
PD1. When the shutoff condition for domain PD is true, the domain is powered down, and so
is domain PD1, including the standard cells, SR, AO, and the isolation cells.
Figure 3-2 Derived Power Domain with a Base Power Domain - Example 1
create_power_domain -name PD \
-default \
-shutoff_condition A \
-instances ...

-shutoff_condition B \
-instances ... \
-base_domains PD

-from PD1
create_state_retention_rule -name sr1 \

-domain PD1 \
-restore_edge ...
Secondary Power Domains of Special Low-Power Instances

Special low-power instances within a power domain, such as isolation cells and state
retention cells, can have their own secondary power domain. The primary power and ground
June 2013
68

nets of the secondary domain provide the power supply to the secondary power and (or)
ground pins of the instance.
The secondary power domain for special low-power logic is defined using the
-secondary_domain option of the corresponding create_xx_rule command. For
example, to specify that a register instance reg1 in power domain PD1 is a register that must
be replaced with a state retention cell, use the create_state_retention_rule
command. To specify that power domain PD provides the continuous power when the cell is
in retention mode, use the -secondary_domain option.
create_state_retention_rule -name PD1_sr \
-instances {reg1} \
-restore_edge {...} \
-secondary_domain {PD}
In Figure 3-3 on page 70:
Power domain PD_ON is an always-on domain (no shutoff condition is specified).
Power domain PD is defined as the base power domain of domain PD1. When the shutoff
condition for domain PD is true, the domain is powered down, and so is domain PD1. The
standard cells in domain PD1 are shut off. The always-on buffer (AO) and the isolation
cells are connected to an external power supply and are not shut off.
The create_state_retention_rule command includes the

-secondary_domain option to specify that domain PD_ON provides the power supply
to the shadow register of the state retention cell. By default, the secondary power domain
of the specified state retention logic is the base domain defined for the parent domain
containing the retention logic (domain PD, in this example). The -secondary_domain
option is used to override this default.
June 2013
69

Figure 3-3 Derived Power Domain with a Base Power Domain - Example 2
create_power_domain -name PD_ON \

-instances ...
-default \
-shutoff_condition A \
-instances ...

-shutoff_condition B \
-instances ... \
-base_domains PD

-from PD1
create_state_retention_rule -name sr1 \

-domain PD1 \
-restore_edge ... \
-secondary_domain PD_ON
An isolation cell or a state retention cell can be powered only by a single secondary domain.
If a power domain has multiple base domains, you must specify the base power domain that
provides the power supply to the secondary power pin of the instance.
In Figure 3-4 on page 71, power domain PD3 has two base power domains, PD1 and PD2.
Domain PD2 is specified as the secondary domain for the state retention logic.
June 2013
70

Figure 3-4 Derived Power Domain with Multiple Base Power Domains
VDD1
VDD2
SW
SW
SW
SW
PD2
PD1
C
SW
VDDSW
SR
PD3
create_power_domain -name PD1 -shutoff_condition A -instances ...

create_power_domain -name PD2 -shutoff_condition B -instances ...
create_power_domain -name PD3 -shutoff_condition C -instances ... \
-base_domains {PD1 PD2}
create_state_retention_rule -name sr1 -domain PD3 \
-secondary_domain PD2
Declaring Boundary Ports with the -boundary_ports Option

The create_power_domain -boundary_ports option lets you assign ports to a specific
power domain.
create_power_domain -name power_domain_name \
-boundary_ports pin_list \
-shutoff_condition expression ...
Using the -boundary_ports option to specify the domain association of ports is allowed
only for the following two cases:
June 2013
71

Primary inputs or outputs of the top-level DUT
if the port is a primary output of the top-level design, the boundary port domain is
the domain of the loads of the port outside the design.
If the port is a primary input of the top-level design, the boundary port domain is the
domain of the drivers of the port outside the design.
While in a simulation environment, the primary ports of a top-level design may be

connected to a testbench and have drivers/loads inside the testbench. These ports may
not be connected to the actual drivers or loads, which can only happen when the design
is integrated. Specifying the domain association of the unconnected or unavailable
drivers or loads allows tools to analyze the design and facilitate its integration.
Primary inputs or outputs of a macro model

A CPF macro model specifies the power behavior of a macro cell. Because the macro
cell only has a behavioral model to describe its functionality, the modeling of the internal
power network is done primarily through the use of boundary ports.
For a macro model, the domain association of a boundary port is as follows:
if the port is a primary output of a macro cell, the boundary port domain is the
domain of the driver(s) of the port inside the macro cell.
If the port is a primary input of a macro cell, the boundary port domain is the domain
of the loads of the port inside the macro cell.
The domain association of design elements is important in determining corruption (or power
state) and placement of isolation. Specifically, the power state of the drivers intended for a
boundary port is reflected in the power state of the boundary port.
Note: Because the internals of a macro model are not accessed, the power state of a macro
model output declared as a boundary port is reflected by the outside connection of the output.
For isolation filtering, the domain association of the boundary port is considered during the
driver/load analysis. if the boundary port is an input of a top-level design or an output of a
macro cell, then the boundary port domain is considered as a driver domain for an isolation
rule applicable to the port. if the boundary port is an output of a top-level design or an input
of a macro cell, the boundary port domain is considered as a load domain for an isolation rule
applicable to the port.
The following examples show how the -boundary_ports option works and how it can be
useful for simulation modeling.
June 2013
72

Example 1: Signal Driven from PD1 to PD2, with a Load Inside PD2
PD4
PD2
PD1
pd2_inst
pd1_inst
PD3
In this example, without the -boundary_ports option, if PD1 and PD2 are both powered on,
the signal at A will be driven to B uncorrupted. However, if port B is specified as shown below
in the CPF command, then the signal entering port B will be corrupted whenever PD3 is shut
off, even if PD1 and PD2 are on.
create_power_domain -name PD1 -shutoff_condition shutoff_pd1 -instances pd1_inst
create_power_domain -name PD2 -shutoff_condition shutoff_pd2 -instances pd2_inst
# Domain PD3 is an empty virtual domain (no instances, just pins).
create_power_domain -name PD3 -shutoff_condition shutoff_pd3 \
-boundary_ports pd2_inst.B
create_power_domain -name PD4 -default
This example illustrates the situation where pin B of the IP block (pd2_inst) is intended to
be driven by a pin of another piece of IP, which has its driver (pin A) in a switchable domain.
However, this second piece of IP is not currently available, so the user is temporarily
connecting the IP block to an always-on testbench. By specifying pin B as shown above, the
signal driving pin B will be corrupted exactly as if it were coming from the intended IP block.
This ensures that the environment surrounding the IP block is identical to the final
environment.
Example 2: Carving out Different Power Domains from a Single Behavioral Model
Because modeling low-power behavior is relatively new, most RAM, ROM, processor, and
other IP models from vendors are not power aware. The vendors supply functional models
that perform well if the power is always present. However, when the power is removed, these
models usually malfunction.
June 2013
73

The following example shows how to transform a single behavioral model, written without any
power intent, to one with multiple power domains. The example illustrates a way to add CPF
information to the overall model so that you can simulate power-down scenarios.
Because one of their primary uses is to functionally model vendor IP accurately, boundary
ports are often used in conjunction with the set_macro_model command. This example
also illustrates a typical use of the set_macro_model command.
In this RAM model, there are three domains: the default always-on domain (PD_ON), one for
the memory array (PD_CORE), and one for the peripheral logic (PD_SW). The memory core
and the peripheral logic must be controlled independently, and are therefore separate
domains with their own shutoff signals. In addition, the testbench is always powered on.
PD4
PD_ON
PD_TB
addr
data_in
PD_SW
BB
A
testbench
PD_CORE
we
ce
RAM
(IP block)
The RTL code for the RAM IP block is as follows:

module sram (we, ce, data_in, addr, &);
input we, ce;
input [15:0] data_in;
input [7:0] addr;
// ram memory array
reg [15:0] ram_core [0:2047]
// memory block
always @(posedge clk or negedge reset)
begin: core_logic
if (we_int && ce_int)
ram_core[addr_int] = data_in_int;
June 2013
74

else if (!we_int && ce_int)
dout_int = ram_core[addr_int];
end
// input signal buffers
always @(addr)
begin: input_sig_logic
addr_int = addr;
data_in_int = data_in
we_int = we;
ce_int = ce;
end
The CPF commands are in two CPF files: the top-level file (top.cpf) and the lower-level file
(sram.cpf).
# Top-level CPF file: top.cpf
set_hierarchy_separator "/"
# The -testbench option in the following set_design command is necessary because
# a default power domain is not defined for the testbench scope.
set_design testbench -testbench
# You must follow the set_design with set_instance to link in the sram.
# Create two virtual domains so that they can be mapped to the lower
# level domains in the macro model
create_power_domain -name PD_core_tb \
-shutoff_condition {pse_core}
create_power_domain -name PD_sw_tb \
-shutoff_condition {pse_sw}
# The next command will map the testbench domains to the lower-level domains
# in the macro model
set_instance xSRAM -domain_mapping { {PD_SW PD_sw_tb} \
{PD_CORE PD_core_tb} }
# Source the lower-level CPF file
source ../cpf/sram.cpf
end_design
June 2013
75

# Lower-level CPF file: sram.cpf
# Define macro model for ram
# NOTE: All CPF commands in this file are ignored by implementation tools.
# They are necessary for simulation only.
set_macro_model ram
# Create the default power domain for the RAM
create_power_domain -name PD_ON -default
# Define two domains: one for the memory core and one for the peripheral pins
create_power_domain -name PD_SW \
-boundary_ports {we ce addr data_in}
create_power_domain -name PD_CORE \
-instances ram_core
# Add isolation rules, state retention rules, etc. here
end_macro_model
In this example, the PD_SW domain must be mapped to the upper-level PD_sw_tb domain,
and the PD_CORE domain must be mapped to the upper-level PD_core_tb domain. The
set_instance -domain_mapping command links these domains together. Whenever the
top-level domain shuts off, the corresponding lower-level domain reflects this shutoff state.
Whenever pse_sw is active, the pins ce, we, addr, and data_in get corrupted. This causes
the always block, input_sig_logic, to see Xs at all of its inputs, and therefore emulate
shutdown behavior.
Likewise, whenever pse_core is active, the memory array (ram_core) will be corrupted.
This emulates a RAM that has lost its contents.
The rest of the RTL code in the RAM model is always on, and will respond normally to any
inputs.
By defining various pins to be in different power domains (through the -boundary_ports
options), it is possible to separate different regions of a single model into many independent
parts. This is analogous to placing each of these regions in separate instances, and then
assigning these instances to their own power domains. However, it is not necessary to rewrite
the vendor IP code to accomplish this.
June 2013
76
4
State Loss
At the physical level, when a power domain shutoff condition is enabled, the appropriate
switches are opened, resulting in a loss of voltage to the domain. With no proper biasing, the
local voltages float, and the output of every cell in the powered-down region is undetermined.
At the logic simulation level, this is modeled by corrupting all internal drivers and processes
within the power domain, unless they are driven by an external driver or are part of an
always-on cell. The output of all corrupted drivers and processes is the unknown logic value
X. Corrupted drivers and processes do not generate any new simulation activity until the
domain is powered up again. In addition, all previously scheduled events associated with
corrupted drivers and processes are canceled and unscheduled.
In simulation, a power domain is powered down when the power domain shutoff condition
evaluates to true. In addition, because an unknown value (X, U, or Z) on the power shutoff
control signal means that the state of the power domain is unknown, a domain is also
powered down when the shutoff control signal has an unknown value. At the time that
low-power simulation starts (the time specified with the -lps_stime option, or time 0 if
-lps_stime is not used), the current value of all power control signals is evaluated. The
domain is corrupted if the shutoff signal is true or has an unknown value. If the -lps_stime
option is used, the power domain is corrupted if the shutoff signal is true or X/U/Z at the
specified time, and remains true or X/U/Z after the specified time.
All signals and wires within the shutdown region transition to the unknown state. All sequential
elements (registers) and variables within the powered-down region lose their state and are
forced to the logic value X for the entire shutoff period.
Note: You can use the -lps_no_xzshutoff option (ncelab -lps_no_xzshutoff or
irun -lps_no_xzshutoff) to turn off the default X/U/Z shutoff behavior. The simulator will
ignore all transitions to X/U/Z values on shutoff conditions.
When a power domain is turned on after PSO, corruption within the domain ends. The forces
are released, all internal drivers and processes become alive again, normal simulation activity
resumes, and the values of power domain variables can change. This power-on behavior
could result in glitches in the values of domain signals similar to those that occur when real
hardware is powered up.
June 2013
77

State Loss
Existing HDLs lack the general language constructs required to reflect PSO behavior such as
corruption. In addition, differences between HDL languages prohibit a common semantic
definition for variable corruption. The following sections describe the corruption semantics of
Verilog and VHDL implemented in the simulator.
Verilog
When a power domain is powered down, all variables within the shutoff domain are assigned
the unknown logic value X. All nets and wires within the region are also assigned X, unless
they are part of an always-on cell.
VHDL
In VHDL, std_logic, std_logic_vector, std_ulogic, and std_ulogic_vector
signals are corrupted by assigning the unknown logic value X. By default, other variables are
corrupted by assigning their left value for corruption. The left value is the initial default value
assigned by VHDL to all variables at the beginning of simulation.
The default VHDL corruption behavior can result in unanticipated PSO simulation behavior.
For example, assigning left for corruption of VHDL user-defined type variables leaves these
variables in the same state (after PSO) as they were when the simulation first started at time
0. Since enumerated data types cannot be forced to X, command-line options have been
implemented that let you control how enumerated types are corrupted at power down. See
Corruption of VHDL User-Defined Enumerated Types on page 83 for details.
VHDL integers in a switchable power domain are corrupted to 0 when the domain powers off.
You can use the global -lps_int_nocorrupt option to disable the corruption of all VHDL
integers in the design.
If an integer is used as an index of an array, corrupting the integer could result in an index
constraint violation. You can use the -lps_int_index_nocorrupt option to specify that
the current value of an integer used as an array index is to be frozen when the corresponding
power domain is powered down. The integer keeps this frozen value throughout the shutdown
period. The array itself is corrupted normally. See Corruption of VHDL Integers on page 90
for more information on the corruption of VHDL integers.
Specifying a Constant for a Shutoff Control Expression

In some situations, it is useful to set the shutoff condition for a power domain to a constant.
For example, suppose that the design includes IPs that are reused at the top level, and that
CPF files have been developed for these IPs. The IP CPF uses virtual ports (created with
set_design -ports) to pass the shutoff condition(s) from a higher scope to a lower scope.
June 2013
78

State Loss
#IP.cpf
...
...
set_design IP -ports {top_pwr}
# Create a virtual port
create_power_domain -name {PD_default} \

-default
-shutoff_condition {top_pwr}
...
...
At the top level, the CPF can use port mapping to map a virtual port to a design signal that
has a value of 1 or 0. For example:
# top.cpf
...
...
set_design TOP
create_power_domain -default \
-shutoff_condition {VD_pwr_on}
set_instance IP_inst -port_mapping {top_pwr VD_pwr_on}
source IP.cpf
end_design
However, this design signal (VD_pwr_on) may not be available in the testbench. In this case,
you could:
Modify the testbench to declare a dummy signal, and then map the virtual port to the
dummy signal.
set_design TOP -testbench
set_instance IP_inst -port_mapping {top_pwr VD_power_on}
source IP.cpf
end_design
Specify a literal in the -port_mapping option and map the virtual port to the literal. This
avoids having to modify the testbench to implement a dummy signal. For example:
#top.cpf
...
...
June 2013
79

State Loss
set_design TOP -testbench
set_instance ip_inst -port_mapping {top_pwr 1}
source IP.cpf
end_design
The mapping of literals is only allowed in a set_instance -port_mapping command.

Literals cannot be specified directly as the shutoff condition in a create_power_domain
command. The literals map only to the shutoff condition in a create_power_domain
command. They do not map to any other control condition, such as isolation or state retention
control conditions.
Only the following literals are allowed:
1 or 1b1. These literals are treated as TRUE. If the shutoff control expression is 1, the
power domain will be powered off at the start of simulation and remain off throughout the
simulation.
0 or 1b0. These literals are treated as FALSE. If the shutoff control expression is 0, the
power domain will be powered on at the start of simulation and will remain on unless the
domain has a switchable base domain and that base domain is powered off.
If you specify a literal, the -lps_stime option has no effect. That is, if the condition is 1, the
concerned power domain will shut off at the start of simulation even if -lps_stime is
specified.
Complex expressions with literals, such as !0 or (!1 & !0), are not supported. This
situation can occur if block-level power domain has a complex expression for its shutoff
condition, and in the top level, all the virtual ports are mapped to a literal.
Example
In this example, the CPF file for an IP block creates three power domains. Domains PD_1 and
PD_2 are switchable domains. Domain PD_1 is the base domain of PD_2. Domain PD_2 will
be powered off when PD_1 is powered off.
The set_design -ports command specifies two virtual ports, pso1 and pso2, which are
needed for the power shutoff control signals at the top level.
In the CPF file for the top level, the set_instance -port_mapping command maps the
virtual port pso1 to its parent-level driver, design signal pso1. The virtual port pso2 is
mapped to literal 0. Because the shutoff control expression for domain PD_2 is a literal 0,
June 2013
80

State Loss
PD_2 will be powered on at the start of simulation and will only be powered off if domain PD_1
is powered down.
#IP.cpf
set_cpf_version
1.1
set_time_unit
"ns"
set_design IP -ports {pso1 pso2}
# Create two virtual ports
create_power_domain -name {PD_default} \

-default
-instances {inst_level_2_1} \
-shutoff_condition {pso1} \
-base_domains {PD_default}
-instances {inst_level_2_2} \
-shutoff_condition {pso2} \
-base_domains {PD_1}
end_design
#top.cpf
set_cpf_version
1.1
set_time_unit
"ns"
set_design top -testbench

set_instance ip_inst -port_mapping {{pso1 pso1} {pso2 0}}
source IP.cpf
end_design
June 2013
81

State Loss
Corruption of Top-Level Ports

Top-level ports of the design can be explicitly defined as boundary ports using the
create_power_domain -boundary_ports option. The specified ports are associated
with the domain being created.
Top-level input ports are assumed to have a driver in the domain associated with the port.
Top-level output ports are assumed to have a load in the domain associated with the port.
If the domain associated with explicitly-defined boundary ports is a switchable domain, the
ports are corrupted when the associated domain is shut off.
By default, top-level ports that are not explicitly defined as boundary ports are implicitly
defined as boundary ports associated with the default domain. Input ports are assumed to
have a driver in the default domain, and output ports are assumed to have a load in the default
domain. If the default domain is a switchable domain, the implicit boundary ports are
corrupted when the domain is shut off.
In the following example, the DUT is instantiated in a testbench.
TB
PDD
A
B
PD1
PD2
M
N
DUT
Domain PDD is the default power domain. This domain is always-on. Ports A, B, C, and M are
defined as boundary ports of a switchable domain called PD3.
June 2013
82

State Loss
create_power_domain -name PDD -default
-boundary_ports {A B C M} \
-shutoff_condition {pso}
Input ports A, B, and C are assumed to have a driver in their associated domain, PD3. Output
port M is assumed to have a load in domain PD3.
Ports D and N, which have not been defined as explicit boundary ports, become implicit
boundary ports associated with the default domain PDD. Input port D is assumed to have a
driver in domain PDD, and output port N is assumed to have a load in domain PDD.
If domain PD3 is powered down, the top-level ports associated with this domain will be
corrupted even if the input ports are driven by an always-on driver in the testbench. Ports D
and N will not be corrupted because they are associated with the default domain, which is
always-on.
You can use the -lps_notlp option to turn off the default behavior for ports that are not
explicitly defined as boundary ports with -boundary_ports. In this example, ports D and N
would not be implicitly defined as boundary ports, and the ports would not be associated with
the default domain.
Corruption of VHDL User-Defined Enumerated Types

The VHDL enumerated type is a widely-used construct for modeling state machines.
According to VHDL semantics, any object of an enumerated type can only have values
defined as enumeration literals of the enumerated type. By default, enumerated type objects
are corrupted to the left-most value when power is shut down.
This default corruption to the 'left value raises issues for simulating accurate power shutdown
behavior. For example, if a state machine has been designed with the states defined as
enums, and the reset state is listed in the left-most position, it will be impossible to detect a
reset problem. This is because any time the state is undefined, it will assume the left-most
value in the enum description. Consequently, the result will be an appearance of being reset.
To avoid this problem, the reset state should be listed in any position except the left-most
element.
There are several command-line options that you can use to control the corruption of VHDL
enums:
June 2013
83

State Loss
ncsim -lps_enum_right (or irun -lps_enum_right)

When power is shut off, corrupt objects of VHDL user-defined enumerated types with the
right-most values. This option selects the right-most enumeration literal as the corruption
value.
ncsim -lps_enum_rand_corrupt [seed] (or irun

-lps_enum_rand_corrupt [seed])
When power is shut off, corrupt objects of VHDL user-defined enumerated types with a
value that is randomly selected from the enumeration literals.
When a domain is powered down, this option randomly selects one of the enumeration
literals as the corruption value. The selected enumeration literal is not the same as the
current value, and the left-most value is selected only if there is no other choice.
Specifying a seed value is optional, but will produce repeatable results. If no seed is
specified, the default is 0.
Note: The -lps_enum_right and -lps_enum_rand_corrupt options are both

simulation-time (ncsim) options that apply to the entire design. Using both options on the
command line generates an error.
ncvhdl -lps_implicit_pso (or irun -lps_implicit_pso)

Enable an implicit power-down state for VHDL user-defined enumerated types.
This option adds an implicit enumeration literal as the right-most literal of the enumerated
type to represent the power off state. If the enumeration literals in the enumeration type
definition are character literals, an X enumeration literal is added. If the enumeration
literals in the enumeration type definition are identifiers, an X enumeration literal is
added.
Note: The -lps_implicit_pso option is a compile-time (ncvhdl) option that may not
apply globally to the entire design. This option can be used together with either
-lps_enum_right or -lps_enum_rand_corrupt. If the source file that defines the
enumerated type has been compiled with -lps_implicit_pso, objects of that type will
be corrupted with the implicit value (X or X). If an enumerated type has not been
compiled with -lps_implicit_pso, objects of that type will be corrupted using the
-lps_enum_right or -lps_enum_rand_corrupt semantics.
If the enumerated type definition includes an X or X enumeration literal, the elaborator
generates an error informing you that you must use one of the following elaborator
options to provide a value to be used as the power-down state:
June 2013
84

State Loss
ncelab -lps_implicitpso_char value (or irun -lps_implicitpso_char

value)
Specifies a character literal to be used as the power-down state. If the enumeration
literals in the enumeration type definition are character literals, the character literal
specified with the -lps_implicitpso_char option is implicitly added as the
right-most enumeration literal in the definition of the enum.
-lps_implicitpso_char A
Note: If the source file that contains the definition of the enumerated type has not been
compiled with -lps_implicit_pso, the -lps_implicitpso_char option is ignored
with a warning.
ncelab -lps_implicitpso_nonchar value (or irun

-lps_implicitpso_nonchar value)
Specifies a non-character literal (identifier) to be used as the power-down state. If the
enumeration literals in the enumeration type definition are identifiers, the identifier
specified with the -lps_implicitpso_nonchar option is implicitly added as the
right-most enumeration literal in the definition of the enum.
-lps_implicitpso_char A
Note: If the source file that contains the definition of the enumerated type has not been
compiled with -lps_implicit_pso, the -lps_implicitpso_nonchar option is
ignored with a warning.
Note: Adding an implicit enumeration literal by using -lps_impicit_pso,
-lps_implicitpso_char, or -lps_implicitpso_nonchar has some effects on user
code. See Effects of Adding an Implicit Enumeration Literal on page 87 for more information.
Example
Consider the following declaration of an enumerated type:
type statedefs is
(ZERO, FIVE, TEN, FIFTEEN, TWENTY, TWENTY_FIVE, THIRTY, THIRTY_FIVE, FORTY,
FORTY_FIVE, FIFTY, FIFTY_FIVE, SIXTY);
signal state : statedefs;
...
When power is shut off, the corruption value of signal state depends on the command-line
option.
-lps_enum_right will corrupt with the right-most value (SIXTY).
June 2013
85

State Loss
-lps_enum_rand_corrupt will randomly select one of the enumeration literals (which

is different from the current value) as the corruption value.
-lps_implicit_pso will implicitly add an X enumeration literal as the right-most literal

of the enumerated type to represent the power off state. At power down, state will be X.
If you compile with -lps_implicit_pso, and the enumerated type includes X as an

enumeration literal, you must use -lps_implicitpso_nonchar to specify an implicit
enumeration literal to be used as the corruption value.
State elements are not restored automatically at power up. They remain corrupted at power
up unless they are restored due to save/restore operations, a reset, or events generated after
resumption of normal operation.
For example, consider the following code:
type statedefs is
(ZERO, FIVE, TEN, FIFTEEN, TWENTY, TWENTY_FIVE, THIRTY, THIRTY_FIVE, FORTY,
FORTY_FIVE, FIFTY, FIFTY_FIVE, SIXTY);
signal state : statedefs;
...
...
when TWENTY =>
if (nickel_in = '1') then
state <= TWENTY_FIVE;
elsif (dime_in = '1') then
state <= THIRTY;
elsif (quarter_in = '1') then
state <= FORTY_FIVE;
end if;
...
...
when FIFTY => then
state <= IDLE;
when FIFTY_FIVE => then
state <= IDLE;
when SIXTY => then
state <= IDLE;
...
...
if you use -lps_enum_rand_corrupt, one of the values is picked at random as the

corruption value. If the random corruption picks a value of TWENTY, at power up the next state
June 2013
86

State Loss
is defined by the state machine. When power is restored, if nickel_in, dime_in, and
quarter_in are all 0, the state machine will hold at state TWENTY, and stay at this value until
one of these variables becomes 1 or until there is a reset. The value at power up is a result
of what the state machine computes as the next state based on its inputs.
However, if the random corruption picks a value of FIFTY, FIFTY_FIVE, or SIXTY, the next
state is always IDLE and hence you see this value at power up.
As long as the state machine state is unknown, all signals derived from that state are also
unknown. For example, suppose that this state machine is used in a concurrent assignment:
my_sig <= '0' when state = TWENTY else '1';
If my_sig is in a switchable domain, it is corrupted to X at shutoff. my_sig could be a 0 or 1,

depending on the value of state. If state remains at TWENTY (the randomly-selected
corruption value) at power up, the concurrent assignment is not re-evaluated and my_sig
stays at X.
Effects of Adding an Implicit Enumeration Literal

Using the -lps_implicit_pso, -lps_implicitpso_char, or
-lps_implicitpso_nonchar option adds an implicit enumeration literal as the right-most
literal of the enumerated type. This has effects on user code when using specific constructs
and on the value returned by some Tcl commands.
Tcl commands and SimVision

All value access commands return the implicit literal so that you can see the implicit
value, which indicates power shutoff.
VHPI design and value access

The implicit enumeration literal is hidden when accessed through VHPI design access
mechanisms. However, all value access routines return the implicit value.
Case statements
All case statements that have case expressions with the subtype as an enumerated type
have an implicit choice inserted for the implicitly-added enumeration literal.
case <expression> is
when <implicit_enum> =>
-- Implicitly-added choice with no statements
when STATE_0 => ...

when STATE_1 => ...
...
other choices
June 2013
87

State Loss
...
end case;
This ensures that case statements are complete as per VHDL semantics. No statements
are added for this choice to ensure that any state machines modeled with the case
statement remain in the shutoff/corrupted state until state elements are restored or the
state machines are reset.
Predefined Attributes
There are several predefined attributes that apply to an enumerated type. A subset of
these attributes can be affected due to the implicitly-added literal. For these attributes,
the simulator ignores the existence of the implicit literal under certain situations to
preserve the power on behavior of the design. The behavior of the attributes is shown in
the following table.
Attribute
Behavior with Implicit Literal
TRIGHT
Simulator ignores the implicitly-added literal, and returns the literal that
lies just to the left of the right-most (implicit) literal.
THIGH
Simulator ignores the implicitly-added literal, and returns the literal that
is one less than the highest (implicit) position number.
TIMAGE(X)
This attribute returns a string representation of the value of parameter

X, which is an expression of the enumerated type.
If parameter X evaluates to the unknown implicit literal, the simulator
returns a string representation of the value so that you can detect
expressions that are in the unknown state due to power shut off.
TVALUE(X)
This attribute takes a string parameter X and returns the literal value
that matches the string representation.
If parameter X evaluates to the string representation of the implicit
literal, the simulator returns the value of the literal.
TPOS(X)
Returns the position number of the value of parameter X.

Checking the position number of the implicit literal is not allowed. The
simulator generates an error if the parameter evaluates to the implicit
literal.
June 2013
88

State Loss
Attribute
Behavior with Implicit Literal
TVAL(X)
Takes an integer parameter and returns the literal that corresponds to

the position indicated by the integer.
The simulator generates an error if the result is not in the range T'LOW
to THIGH. The implicit literal is not considered to be in this range. The
simulator generates an error if the integer parameter points to the
position of the implicit literal.
TSUCC(X)
Takes a parameter, which is an expression of the enumerated type,

and returns the literal whose position number is one greater than the
evaluated parameter value.
The simulator generates an error if X equals T'HIGH or if X is not in the
range T'LOW to T'HIGH. The implicit literal is not considered to be in
this range. The simulator generates an error if X evaluates to the
implicit literal.
TPRED(X)
Takes a parameter, which is an expression of the enumerated type,

and returns the literal whose position number is one less than the
evaluated parameter value.
The simulator generates an error if X equals T'LOW or if X is not in the
range T'LOW to T'HIGH. The implicit literal is not considered to be in
this range. The simulator generates an error if X evaluates to the
implicit literal.
TLEFTOF(X)
Takes a parameter expression whose type is the base type of the

enumerated type and returns the value that is to the left of the
parameter in the range of the enumerated type.
The simulator generates an error if X equals T'LEFT or if X does not
belong to the range T'LOW to T'HIGH. The implicit literal is not
considered to be in this range. The simulator generates an error if X
evaluates to the implicit literal.
TRIGHTOF(X)
This attribute takes a parameter expression whose type is the base

type of the enumerated type and returns the value that is to the right of
the parameter in the range of the enumerated type.
The simulator generates an error if X equals T'RIGHT or if X does not
belong to the range T'LOW to T'HIGH. The implicit literal is not
considered to be in this range. The simulator generates an error if X
evaluates to the implicit literal.
June 2013
89

State Loss
Corruption of VHDL Integers

By default, VHDL integers in a switchable power domain are corrupted to 0 when the domain
powers off.
Disabling the Corruption of All integers

You can use the elaborator -lps_int_nocorrupt option (ncelab
-lps_int_nocorrupt or irun -lps_int_nocorrupt) to disable the corruption of all
VHDL integers in the design.
Using this option can be useful when debugging initial low-power issues and getting a
low-power simulation to run. However, disabling the corruption of all integers means that the
simulator is treating the VHDL integers as if they are continuously powered objects. For
domains that include these integers that means that the simulator is being overly optimistic in
not corrupting the integer when power for the domain is switched off. In reality the synthesized
result of the integer will be powered by the switched supply for the domain. Consequently RTL
vs. gate behavior for the object will be different. Therefore, the elaborator generates the
following warning when the option is used:
ncelab: *W,INTNOC: All VHDL integer corruption is turned off. RTL vs gate results
will differ for VHDL integers within shutoff domains.
This option should be removed after initial problems have been resolved.
Disabling the Corruption of VHDL Integers Used as an Array Index

powers off. If an integer is used as an array index, this could result in an index constraint
violation.
In the following code snippet, the range of integer c_int is 0 to 11. This integer is used as
an index to the array int_reg.
ENTITY unicntr IS
GENERIC(n : Positive := 6); --size of counter/shifter
PORT(clock, serinl, serinr : IN std_logic; --serial inputs
mode : IN std_logic_vector(2 DOWNTO 0); --mode control
reset_n : in std_logic; --reset for counter
datain : IN std_logic_vector((n-1) DOWNTO 0); --parallel inputs
dataout : OUT std_logic_vector((n-1) DOWNTO 0); --parallel outputs
termcnt : OUT std_logic); --terminal count output
END unicntr;
June 2013
90

State Loss
ARCHITECTURE v1 OF unicntr IS
signal int_reg : std_logic_vector((n-1) DOWNTO 0) := "100101";
signal c_int : integer range 0 to 11 := 2;
signal pat : integer := 4;
signal flag : std_logic := '0';
signal sout : std_logic_vector(2 downto 0) := "000";
BEGIN
pat <= c_int + 1;
p1:process (clock) begin
if (clock'event and clock='1') then
if (reset_n='0') then
c_int <= 1;
else
if (c_int < 10) then
c_int <= c_int +1;
end if;
end if;
end if;
end process;
main_proc : PROCESS
BEGIN
WAIT UNTIL rising_edge(clock);
CASE mode IS
--reset
WHEN "000" => int_reg <= (OTHERS => '0');
--parallel load
WHEN "001" => int_reg <= datain;
...
...
END CASE;
END PROCESS;
det_zero : PROCESS(int_reg, c_int) --detects when count is 0
BEGIN
termcnt <= '1';
FOR c_int IN int_reg'Range LOOP
June 2013
91

State Loss
IF int_reg(c_int) = '1' THEN
termcnt <= '0';
EXIT;
END IF;
END LOOP;
END PROCESS;
--connect internal register to dataout port
dataout <= int_reg((n-1) downto 1) & int_reg(c_int-1);
flag <= '0' when (c_int =1) else '1';
sout <= "111" when (pat = 2) else "010";
END v1;
When the corresponding power domain shuts off (at time 33ns), all integers are corrupted to
0. This results in the following index constraint violation:
% irun -access +c -v93 -top tb \
-lps_cpf top.cpf -lps_verbose 3 \
tb.vhd top.vhd
...
...
ncsim> probe -screen :t1:c_int
Created probe 1
ncsim> stop -pdname :PD1 -continue
Created stop 1
ncsim> run 150 ns
Time: 20 NS: :t1:c_int = 1
33 NS + 3 (stop 1: Power Domain :PD1 is OFF)
// Domain PD1 powers down
:PD1 ./top.cpf line 6

Time: 33 NS: :t1:c_int = 0
// Integer c_int corrupted to 0
ncsim: *E,TRINDXC: index constraint violation.

File: ./top.vhd, line = 70, pos = 50
Scope: :t1:$PROCESS_001
Time: 33 NS + 3
./top.vhd:70 dataout <= int_reg((n-1) downto 1) & int_reg(c_int-1);
Use the elaborator -lps_int_index_nocorrupt option (ncelab

-lps_int_index_nocorrupt or irun -lps_int_index_nocorrupt) to disable the
corruption of VHDL integers that are used as an array index. This option specifies that the
current value of an integer used as an array index is to be frozen when the corresponding
June 2013
92

State Loss
power domain is powered down. The integer keeps this frozen value throughout the shutdown
period. The array itself is corrupted normally.
When the domain powers back up, there may be no transition on these frozen integers. In this
case, signals will not be updated, and processes that are sensitive to the integers will not be
replayed. The -lps_int_index_nocorrupt option identifies processes that are sensitive
to these integers and replays them.
Note: In the current release, this feature is not supported if the integer that is used as an array
index is declared as an element in a complex user-defined VHDL type, such as a record.
In this example, when power domain PD1 powers up, signal flag is updated and process
det_zero, which is sensitive to c_int, is replayed.
% irun -access +c -v93 -top tb \
-lps_cpf top.cpf -lps_int_index_nocorrupt -lps_verbose 3 \
tb.vhd top.vhd
...
...
ncsim> probe -screen :t1:c_int :t1:flag :t1:termcnt
Created probe 1
ncsim> stop -pdname :PD1 -continue
Created stop 1
ncsim> run 65 ns
Time: 0 FS: :t1:c_int = 2: :t1:flag = '1': :t1:termcnt = '0'
Time: 20 NS: :t1:c_int = 1: :t1:flag = '1': :t1:termcnt = '0'
33 NS + 3 (stop 1: Power Domain :PD1 is OFF)
// Domain PD1 powers down. Current

// value of c_int is frozen

Time: 33 NS: :t1:c_int = 1: :t1:flag = 'X': :t1:termcnt = '0'
is frozen at its current value
// Value of c_int
Time: 33 NS: :t1:c_int = 1: :t1:flag = 'X': :t1:termcnt = 'X'

63 NS + 2 (stop 1: Power Domain :PD1 is ON)
// Domain PD1 powers up.

// Signal flag is updated.
// Process det_zero is replayed.

June 2013
93

State Loss
Ran until 65 NS + 0
ncsim> exit
Disabling the Corruption of Specific Integers With set_sim_control

You can disable the corruption of specific integers in the design by using the
set_sim_control -action disable_corruption command. For example, the
following command disables the corruption of target objects c_int (the integer used as an
index to an array in the example in the previous section), and del (an integer used to specify
a delay).
set_sim_control -action disable_corruption -type integer \
-targets {c_int del}
See set_sim_control for details on this command.

You can run HAL to automatically generate set_sim_control commands that will disable
the corruption of integers that should not be corrupted. You can then add these commands
to your CPF file.
State Loss and Forced Signals

When a power domain is powered down, all signals, wires, sequential elements, and
variables are corrupted. The force mechanism is similar to that used by a Verilog force
statement, a Tcl force command, or the $nc_force task. Because only one force can be
active at a time on a single node, the low-power corruption overrides previous forces. When
power is restored, signals do not return to a previously forced value.
The simulator can issue a warning (LPFORC) when a force is lost due to power shutdown.
However, the warning message is not displayed by default. To enable the display of LPFORC
messages, you can:
Set the value of the Tcl variable show_force to 1.

ncsim> set show_force 1
This variable must be set to 1 at the time that the forces are applied in order to enable
the display of the warning.
Elaborate the design with the -show_forces option (ncelab -show_forces or irun
-show_forces). This automatically sets the value of the Tcl show_force variable to 1.
Invoke the simulator with the -gui option. This automatically sets the value of the Tcl
show_force variable to 1.
June 2013
94

State Loss
For example:
% irun -f run.f -input sim.tcl -gui
ncsim> force test.top1.A1.aa 1
ncsim> run 400ns
ncsim: *W,LPFORC: [LPS] A user defined force has been detected on signal
test.top1.A1.aa. The power domain PDA is being powered down, and this force will
be lost (240 NS).
Ran until 400 NS + 0
For Verilog, if you want to replay the force after power is restored, place the force statements
in a labeled initial block, and then use the set_sim_control -action
power_up_replay CPF command to replay that initial block on power-up. See Replaying
initial Blocks for details.
Disabling Corruption
In some cases, you may have to disable the default simulation corruption semantics for
selected objects in parts of the design. For example, to model non-volatile memory, the state
elements in the memory must not be corrupted when power is shut off.
In the current release, you can disable the corruption of integers, reals, and Verilog reg type
variables. Use the set_sim_control -action disable_corruption command to
specify a list of variables that the simulator must not corrupt when the domain is shut down.
For example, the following command disables corruption for target objects q1, q2, and q3,
which are of type reg.
-targets {q1 q2 q3}
See Disabling Corruption of Integers, Reals, or Verilog reg Variables on page 33 for details.
June 2013
95

State Loss
June 2013
96
5
State Retention
When a power domain is powered down, the states of certain sequential elements (registers,
latches, flip-flops) in the power domain must be saved and retained for the entire shutoff
period. When the power domain is powered back up, the saved states must be written back
into the registers. To ensure that a powered-down block resumes normal operation after
power up, these sequential elements can be replaced by special state retention cells.
The CPF create_state_retention_rule command specifies the design intent for state
retention behavior. This command identifies the design registers or instances in a switchable
power domain that must be replaced with state retention cells, and specifies the control signal
and/or conditions that control the save and restore operation of the retention registers.
At the RTL level, state retention is implicitly modeled by mimicking the effect of inserting
appropriate state retention cells. The CPF state retention behavioral model is as follows:
When the save condition specified in the create_state_retention_rule command
changes from false to true, the state of the registers is saved. When the restore condition
changes from false to true, the saved values are restored to the registers. Transitions to X and
Z result in corruption of the content of both the master and shadow register.
After synthesis, the gate-level netlist includes state retention cells that provide the state
retention behavior. These cells are identified with a CPF
define_state_retention_cell command, and the virtual logic implicitly modeled by
the simulator at the RTL level is disabled by using the -lps_rtn_off command-line option.
Selecting the Targeted Registers or Instances

The registers or instances that must be mapped to state retention cells are selected by the
-domain or -instances option. Specific instances can be excluded from state retention by
using the -exclude option. You can also use the -target_type option to filter the instance
list based on a given target type (flop, latch, or both).
-domain power_domain
Selects all registers in the specified power domain.
June 2013
97

State Retention
create_state_retention_rule -name SR_rule1 \
-domain {PD1} \
...
-instances instance_list
Selects all registers in the specified instances.
-instances {A/B/I1} \
...
-instances {A/B/a_reg A/B/b_reg} \
...
-exclude instance_list
Excludes the specified list of instances from the list of instances selected with -domain
or -instances.
The -exclude option excludes elements that are selected by the rule that contains the
-exclude option. The -exclude option in a state retention rule is applied only to that
rule. For example, suppose that a power domain PD1 contains five registers: reg1,
reg2, reg3, reg4, and reg5. The CPF file includes the following two
create_state_retention_rule commands:
-domain PD1 \
-exclude {test/u1/reg3 test/u1/reg4 test/u1/reg5} \
...
-domain PD1 \
-exclude {test/u1/reg1 test/u1/reg2} \
...
The first rule selects all registers in PD1, then excludes reg3, reg4, and reg5. That is,
this rule selects reg1 and reg2.
The second rule selects all registers in PD1, then excludes reg1 and reg2. That is, this
rule selects reg3, reg4, and reg5.
In this example, all five registers are selected for state retention. No register is excluded.
June 2013
98

State Retention
-target_type {flop | latch | both}

Specifies the type of sequential elements in the selected instances to convert to state
retention registers. If you specify both, sequential elements of types flop and latch can
be converted. The default for the Incisive simulator is both.
The following command specifies that all flops in instances test/u1 and test/u2 are
to be replaced with state retention registers:
-instances {test/u1 test/u2} \
-target_type {flop} \
...
Identification of Sequential Elements

By using the -instances and -exclude options to the
create_state_retention_rule command, you can specify a precise list of logic
elements whose state needs to be retained. When more general state retention rules (using
the -domains option or wildcards) are written, the simulator, which does not have the same
view of state elements that an implementation tool does, must be able to qualify the selected
logic elements for state retention. In particular, it must be able to identify latches and flip flops
and to distinguish these sequential elements from combinational ones.
In releases prior to INCISIV10.2-S40, the simulator could not correctly distinguish many
sequential elements from combinational elements. This sometimes resulted in non-state
elements being retained. This leads to an over-optimistic RTL simulation behavior that can
differ from the simulation of the gate netlist generated by the synthesis tool, which identified
the sequential elements subject to state retention and replaced these elements with state
retention cells.
In the current release, the simulator analyzes the HDL code associated with the elements
specified in the create_state_retention_rule command, identifies latches and flip
flops, and applies state retention only to these sequential elements.
Note: In the current release, the simulator cannot detect if individual bits of an array are
combinational or sequential. All bits will be treated the same, and state retention may be
applied to bits that are combinational.
By default, state retention is applied to both flops and latches. The -target_type option
can be used to specify that retention is to be applied to flops only or to latches only.
Use the -lps_srfilter_verbose option to enable reporting of state retention filtering
information. This option prints a list of elements selected in a
create_state_retention_rule command that have been disqualified from retention,
June 2013
99

State Retention
either because the element was determined to be combinational, or because the element did
not satisfy the target type requirement.
If all of the elements selected in a create_state_retention_rule command are
determined to be combinational, or if there are no sequential elements of the type specified
with -target_type, the rule is ignored. By default, no warning is generated when a rule has
been optimized away. Use the -lps_srruleopt_warn option to enable the printing of
warning messages.
Identification of VHDL Sequential Elements
VHDL sequential elements consists of two types of storage elements: edge-sensitive and
level-sensitive.
Edge-sensitive elements consist of different types of flip-flops that are sensitive to an edge
on the clock. The clock signal must be BIT, STD_ULOGIC, or their subtypes (STD_LOGIC,
for example).
The simulator can correctly identify edge-sensitive sequential elements if the syntax used for
specifying an edge of a clock is as follows:
clock_edge ::=
RISING_EDGE(clk_signal_name)
| FALLING_EDGE(clk_signal_name)
| clock_level and event_expr
| event_expr and clock_level
clock_level ::= clk_signal_name = '0' | clk_signal_name = '1'
event_expr ::= clk_signal_name'EVENT | not clk_signal_name'STABLE
The RISING_EDGE and FALLING_EDGE functions are as declared by the package

STD_LOGIC_1164 of IEEE Std. 1164-1993.
Rising (Positive) Edge Clock

The following expressions represent a rising edge clock:
RISING_EDGE(clk_signal_name)
clk_signal_name = '1' and clk_signal_name'EVENT
clk_signal_name'EVENT and clk_signal_name = '1'
clk_signal_name = '1' and not clk_signal_name'STABLE
not clk_signal_name'STABLE and clk_signal_name = '1'
June 2013
100

State Retention
Falling (Negative) Edge Clock

The following expressions represent a falling edge clock:
FALLING_EDGE(clk_signal_name)
clk_signal_name = '0' and clk_signal_name'EVENT
clk_signal_name'EVENT and clk_signal_name = '0'
clk_signal_name = '0' and not clk_signal_name'STABLE
not clk_signal_name'STABLE and clk_signal_name = '0'
Guidelines for Writing Rules

CPF state retention rules should be as explicit as possible. Cadence strongly recommends
that you use the following guidelines when writing state retention rules:
Try to use the -instances option to specify an exact list of logic elements for state
retention.
Because specifying all registers in a power domain with -domain can result in an
optimistic model of state retention, use this option with caution.
Specifying the name of a hierarchical instance with -instances will replace all registers
in the specified instance and in all of its children. Try to avoid specifying hierarchical
instance names.
Do not use very general wildcards. Use wildcards in a carefully constructed list to get the
best match between simulation and implementation. For example, avoid specifications
like the following, which uses a general wildcard:
-instances {A/B/*} \
...
Limit the use of wildcards to situations in which you know that the wildcard will match only
the intended state elements. For example, if you have used a naming convention in which
_reg is used to identify registers, you can use the following specification:
-instances {A/B/*_reg} \
...
Specifying the Control Conditions

Which options you use with the create_state_retention_rule command to specify the
save and restore condition(s) depends on how you model the state retention behavior. The
logic you model can have:
June 2013
101

State Retention
A single retention control. See Modeling State Retention with a Single Retention
Control on page 102.
Separate save and restore controls. See Modeling State Retention with Separate Save
and Restore Controls on page 104.
Additional conditions that must be met to start the save or restore operation and keep it
going until it is finished. For example, you may want to model state retention logic that is
sensitive to a reset signal. See Modeling State Retention with Save or Restore
Preconditions on page 105.
A state retention rule can be specified without a save or restore condition. See Incomplete
State Retention Rules on page 115 for details on how an incomplete rule is handled.
Modeling State Retention with a Single Retention Control
To model retention logic with only one retention control, use the -save_edge and
-restore_edge options.
-save_edge expr
Saves the current value when the expression changes from false to true and the
power is on. Restores the saved value when the power is turned back on.
-restore_edge expr
Saves the current value when the expression changes to false and the power is on.
Restores the saved value when the expression changes from false to true and the
power is on.
-save_edge expr -restore_edge expr

Saves the current value when the save expression changes to true and the power is on.
Restores the saved value when the restore expression changes to true and the power
is on. In this case, one expression is the inversion of the other expression.
June 2013
102

State Retention
In the following figure, the retention control signal is called pg.
Retention control becomes
active and power is on
Region 1
Retention mode
with power on
pg
Retention control
becomes inactive
Power on
Power off
Region 2
Region 3
Retention mode
with power off
Retention mode
with power on
Using -restore_edge
In the example shown in Figure 3-1 on page 64, there is a single state retention control signal
for the power domains.
The state retention control signal for power domain PD2 is pge_enable[0].
The state retention control signal for power domain PD3 is pge_enable[1].
The following create_state_retention_rule commands specify that the current values

of all registers in the domains are saved when the control expressions change to false, and
that the saved values are restored when the control expressions change from false to true.
create_state_retention_rule -name st1 -domain PD2 \
-restore_edge {!pm_inst.pge_enable[0]}
-restore_edge {!pm_inst.pge_enable[1]}
Using -save_edge
The following rules specify that the current values are saved when the control expressions
change from false to true. No restore edge is specified, so the saved values are restored
when the power is turned back on.
-save_edge {pm_inst.pge_enable[0]}
-save_edge {pm_inst.pge_enable[1]}
June 2013
103

State Retention
Modeling State Retention with Separate Save and Restore Controls
To model retention logic with separate save and restore controls, use both the -save_level
and -restore_level options.
In the following figure, the save control signal is called sr_save, and the restore control
signal is called sr_restore.
Save is
active
Save is
inactive
Region 1
sr_save
Region 2
Retention mode
with power on
Restore is Restore is
active
inactive
Power on
Power off
Region 3
Region 4
Retention mode
with power off
Retention mode
with power on
Region 5
sr_restore
The CPF standard states that the current values are saved as long as the save expression is
true, and that the saved values are restored as long as the restore expression is true. In
the Incisive simulators:
The register saves the current value as soon as the save expression evaluates to true.
The register restores the saved value at the last moment when the restore expression
evaluates to true.
The following rule specifies that the current values are saved as soon as sr_save evaluates
to true. The saved values are restored at the end of the period where sr_restore
evaluates to true.
-save_level {sr_save} \
-restore_level {sr_restore}
June 2013
104

State Retention
Save is
active
Save is
inactive
Region 1
Region 2
active
inactive
Power on
Power off
Region 3
Region 4
Region 5
sr_save
sr_restore
Save current values
Restore values
Modeling State Retention with Save or Restore Preconditions

The logic you model may be sensitive to additional conditions besides the save and restore
control signals. For example, the state retention cells may include a reset signal. These
additional conditions are specified in a create_state_retention_rule command with
the following options:
-save_precondition expr
-restore_precondition expr
The following examples illustrate the effects of these options.

Single Retention Control with a Save Precondition
If a save precondition is specified, the current values are saved when the save condition
evaluates to true and if the save precondition expression also evaluates to true. The
precondition must remain true for the entire period until power shutdown. For example:
create_state_retention_rule -name SR1 \
-restore_edge {!pg} \
-save_precondition {rst}
June 2013
105

State Retention
Save condition and save

precondition are both true
Power off
Region 1
Power on
Retention control
becomes inactive
Region 3
Region 2
pg
rst
Save
If the save precondition is always false or is false at any time before power is shut off (that
is, if the precondition is false at any time during Region 1), two modeling choices are available:
Save the values of the registers right before power goes down. This is the default
behavior. For example:
Save condition
is true
Precondition is
always false
Power off
Region 1
Power on
Region 2
Retention control
becomes inactive
Region 3
pg
rst
Save
June 2013
106

State Retention
Save condition
is true
Precondition
is false
Power off
Region 1
Retention control
becomes inactive
Power on
Region 2
Region 3
pg
rst
Save

Precondition
becomes false
Region 1
Power on
Power off
Retention control
becomes inactive
Region 3
Region 2
pg
rst
Save
Re-evaluate
values
Save again
Corrupt the saved value in the shadow register for the remainder of Region 1. The value
of the master register will be X when values are restored.
You must use the simulator -lps_alt_srr option to enable this behavior (ncsim
-lps_alt_srr or irun -lps_alt_srr).
June 2013
107

State Retention
For example:
Precondition
becomes false
Region 1
Retention control
becomes inactive
Power on
Power off
Region 3
Region 2
pg
rst
Save
Corrupt values in
shadow register
Single Retention Control with a Restore Precondition

If a restore precondition is specified, the saved values are restored when the restore condition
evaluates to true and if the restore precondition also evaluates to true. The precondition
must remain true for the entire period after power on. For example:
-restore_edge {!pg} \
-restore_precondition {rst}
June 2013
108

State Retention
Restore condition
is true
Save condition
is true
Power off
Region 1
Power on
Restore precondition
is true
Region 3
Region 2
pg
rst
Restore
Save
If the restore precondition is always false or is false before the restore condition evaluates
to true (that is, if the restore precondition is false at any time between power up and restore),
two modeling choices are available:
Do not restore the value in the shadow register. This is the default behavior. For example:
Restore condition
is true
Save condition
is true
Region 1
Power off
Power on
becomes false
Region 3
Region 2
pg
rst
No restore
Save
Corrupt the saved value in the shadow register for the remainder of Region 3. Restore
when the restore condition becomes true. The value of the master register will be X
when values are restored.
June 2013
109

State Retention
For example:
Restore condition
is true
Save condition
is true
Region 1
Power off
Power on
becomes false
Region 3
Region 2
pg
rst
Save
Restore
Corrupt values in
shadow register
Separate Save and Restore Controls with a Save Precondition

If a save precondition is specified, the current values are saved when the save condition
evaluates to true and if the save precondition expression also evaluates to true. The
precondition must remain true for the entire period during which the save condition is true.
For example:
-restore_level {sr_restore} \
-save_precondition {rst}
June 2013
110

State Retention

Region 1
Power off
Region 2
inactive
active
Power on
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Restore values
Save
If the save precondition is always false or is false at any time before the save signal
becomes inactive (that is, if the precondition is false at any time during Region 1), two
modeling choices are available:
Save the current values when the save signal becomes inactive. This is the default
behavior. For example:
Save condition
is true
Precondition is
always false
Region 1
Power off
Region 2
inactive
active
Power on
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Restore values
Save
June 2013
111

State Retention

Save precondition
becomes false
Region 1
Power off
Region 2
inactive
active
Power on
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Save
Re-evaluate
values
Restore values
Save again
Corrupt the saved value in the shadow register for the remainder of Region 1. The value
of the master register will be X when values are restored.
For example:
June 2013
112

State Retention

Save precondition
becomes false
Region 1
Region 2
inactive
active
Power on
Power off
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Save
Restore values
Corrupt values
in shadow
register
Separate Save and Restore Controls with a Restore Precondition

If a restore precondition is specified, the saved values are restored when the restore condition
expression evaluates to false and the restore precondition expression is evaluated to be
true for the entire period during which the restore condition is true. For example:
-restore_level {sr_restore} \
-restore_precondition {rst}
June 2013
113

State Retention
Restore condition Restore condition

is false
is true
Save condition is true
Power off
Power on
is true
Region 1
Region 2
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Save
Restore values
If the restore precondition is always false or becomes false before the restore expression
becomes false (that is, if the precondition is false at any time during Region 5), two
modeling choices are available:
Do not restore the value in the shadow register. This is the default behavior. For example.
is false
is true
Power off
Power on
becomes false
Region 1
Region 2
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
No restore
Save
June 2013
114

State Retention
Corrupt the saved value in the shadow register for the remainder of Region 5. Restore
when the restore condition becomes false. The value of the master register will be X
when values are restored.
For example:
is false
is true
Power off
Power on
becomes false
Region 1
Region 2
Region 3
Region 4
Region 5
sr_save
sr_restore
rst
Save
Corrupt values in
shadow register
Restore
Incomplete State Retention Rules

A create_state_retention_rule is incomplete if:
For a single retention control, both -save_edge and -restore_edge are not
specified.
For separate save and restore controls, either -save_level or -restore_level is

not specified, or both options are not specified.
Incomplete rules must be completed or they will be ignored.

Incomplete state retention rules are completed as follows:
June 2013
115

State Retention
For a single retention control, where both -save_edge and -restore_edge are not
specified.
Use the default save condition specified with -default_save_edge in the

create_power_domain command that created the corresponding power domain.
Use the default restore condition specified with -default_restore_edge in the

create_power_domain command that created the corresponding power domain.
If neither default is specified, the rule remains incomplete and is ignored.
For separate save and restore controls:
If -save_level is not specified, use the default save condition specified with
-default_save_level in the create_power_domain command that created
the corresponding power domain. If a default save condition is not specified, ignore
the create_state_retention_rule command.
If -restore_level is not specified, use the default restore condition specified with
-default_restore_level in the create_power_domain command that
created the corresponding power domain. If a default restore condition is not
specified, ignore the create_state_retention_rule command.
If both -save_level and -restore_level are not specified, use the default
save and restore condition specified in the create_power_domain command. If
both default conditions are not specified, ignore the
create_state_retention_rule command.
Note: If a default save or restore condition is specified in the create_power_domain

command and a save or restore condition is specified in the
create_state_retention_rule command, the condition specified in the
create_state_retention_rule command takes precedence.
June 2013
116
6
Isolation
A power domain is usually connected to other power domains. When a domain is powered
down, isolation logic must be added between domains to prevent the propagation of unknown
states from a power domain that is powered down to a power domain that remains on.
The CPF create_isolation_rule command specifies the design intent for isolation
behavior. This command identifies the net segments that must be isolated, their isolation
values, and when isolation should happen.
At the RTL level, pin isolation is implicitly modeled by mimicking the effect of inserting the
appropriate isolation cell. This virtual isolation cell is inserted outside the power domain as a
driver that drives the wire connected to the port. The isolation logic drives a logic value to the
power-on domain connected to the pin.
After synthesis, the gate-level netlist includes isolation cells that provide the isolation
behavior. These cells are identified with a CPF define_isolation_cell command, and
the virtual logic implicitly modeled by the simulator at the RTL level is disabled by using the
-lps_iso_off command-line option.
Note: In some cases, the simulator may optimize away a create_isolation_rule
command. By default, no warning is generated when a rule is ignored. Use the
-lps_isoruleopt_warn option to enable the printing of warning messages. See Logging
Isolation Information on page 150 for more information.
Selecting Nets for Isolation

The create_isolation_rule command has several options that let you specify the net
segments that must be isolated. Using these options, you can write rules that range from
generic rules, which do not explicitly specify the targeted net segments, to rules that are very
specific.
-from power_domain_list
Selects net segments driven by logic in the specified from domains and with at least one
leaf load in another power domain.
June 2013
117

Isolation
-to power_domain_list
Selects net segments driving logic in the specified to domains and that are driven by a
signal from another power domain.
-from and -to

Selects net segments that drive logic in the specified to domains and that are driven by
logic in the specified from domains.
Note: The CPF specification states that every isolation rule must have a -from option, a -to
option, or both -from and -to. If a rule does not meet this requirement, an ISOSPEC warning
is generated and the isolation rule is ignored.
-pins pin_list
Selects net segments that are connected to, driven by, or driving the specified pin(s). You
can specify ports and instance pins.
The -pins option must always be used with the -from, -to, or -from and -to options.
-from and -pins

Selects net segments that drive or connect to the specified pins, and that are driven
by logic in the specified from domains and have a load in some other domain.
-to and -pins

Selects net segments that are driven by or connected to the specified pins, and that
are driving logic in the specified to domains and are driven by logic in another
domain.
-from, -to, and -pins

Selects net segments that are driven by or connected to the specified pins, that drive
logic in the specified to domains, and that are driven by logic in the specified from
domains.
The -pins option isolates net segments connected to, driven by, or driving the specified
pin(s) provided that the specified pins meet the driver and load analysis conditions of the
isolation rule. In effect, this option lets you filter the set of pins selected by the -from,
-to, or -from -to options. For example, if you specify:
-to PD2 -pins {C, E}
Only net segments that pass through C or E will be isolated if there is a load in PD2 and
a driver in another power domain.
June 2013
118

Isolation
-exclude pin_list
Excludes the specified ports or pins.
This option lets you exclude certain net segments that have been selected for isolation.
Any net segments already chosen for isolation that are driven by, connected to, or driving
the specified pin(s) will be excluded.
Note: You can only specify ports or instance pins with the -exclude option. The
wildcard character can be used only in the specification of the ports or pins. For example,
suppose you want to exclude all pins of instance :forgen(0):sm. The -exclude
option would be:
-exclude {forgen(0).sm.*}
-force
Places isolation at the pins specified with the -pins option regardless of the other
conditions of the isolation rule.
The -force does no driver or load analysis. An isolation rule with a -force simply
places isolation at the -pins location. It should, therefore, be used with care.
The -force options requires -pins pin_list to specify the pins to be isolated.
You can use wildcards when specifying the pins, but an error is generated if the wildcard
is used to select all pins, whether at the top level (-force -pins {*}) or at a leaf level
(for example, -force -pins {a/b/*}). A specific pin list specification using wildcards
is allowed. For example:
-force -pins {*_out}
-force -pins {a/b/in*}
Using a -from or a -to filter is not required. If a create_isolation_rule with a

-force also includes -from, -to, or both -from -to, an ISOFRCF warning is issued
stating that these options will be ignored.
A create_isolation_rule with a -force is ignored with an ISOFRC warning if:
The -exclude option is present
The -no_condition option is present
Note: When isolating to tristate (using create_isolation_rule

-isolation_output tristate), you must also include the -force option. See
Specifying Isolation Values on page 131 for more information.
June 2013
119

Isolation
Ignoring Isolation Rules

An isolation rule is ignored (unless it is specified with the -force option) if it is specified for:
A floating net
An undriven net
A net that has its leaf-level driver and loads in the same power domain
A net that is connected to an inout pin (unless -force -pins is used)
Tie-high or tie-low signals in a switchable domain are corrupted when the domain is powered
down. Nets driven by these tie-high or tie-low signals must be isolated if they are connected
to a domain that is powered on. The isolation value (see Specifying Isolation Values on
page 131) must be high for a net driven by a tie-high and low for a net driven by a tie-low.
Note: For Verilog, isolation of ports declared as inout is not supported. For VHDL, isolation
of ports declared as inout or buffer is not supported. For example, if a port I1.A is
declared as an inout port, a NOISOIO warning is generated, and the following CPF rule will
not insert isolation:
create_isolation_rule -name foo -to PD2 -pins {I1/A} ....
Isolation Placement
By default, the virtual isolation cells are placed at the power domain input pin of the
destination domain (the to domain). You can use the update_isolation_rules
-location command to control the placement of isolation. See Controlling Isolation
Placement on page 127 for details.
Examples
The following example illustrates the effect of the various options used to select the net
segments to be isolated. For each example command, the location of the isolation cells is also
noted. In this design:
Instances I1 and I2 belong to power domain PDA
Instance I3 belongs to power domain PDB.
Instance I4 belongs to power domain PDC.
June 2013
120

Isolation
top
I1
I2
A
PDA
D
E
B
I3
F
C
I
G
H
PDB
I4
J
K
PDC
June 2013
121

Isolation
Table 6-1 Effect of Net Segment Selection Options

Isolation Rule
Net Segments Selected
Isolate net segments driven by logic in the

specified from domain and with a load in another
domain.
-from PDA \
...
This rule isolates net segments:
CG. Isolation is placed at pin G.
CJ. Isolation is placed at pin J.
BF. Isolation is placed at pin F.
Pin H is also isolated.

Net segments AD and BE are not isolated
because the leaf-level driver and loads are in the
same power domain.
This rule is ignored for the net connected to pin I
because it is a floating net.
-to PDB \
...
Isolate net segments driving logic in the specified

to domain and that are driven by logic from
another power domain.
Pin H is also isolated because it is driven by a

tie-low signal that is in a switchable domain.
-from PDA -to PDC \
...
Isolate net segments that drive logic in the

specified to domain and that are driven by logic
in the specified from domain.
This rule isolates net segment CJ. Isolation is
placed at pin J.
June 2013
122

Isolation
Isolation Rule
Isolate net segments that drive or connect to pin

B, and that also meet the requirements of the
-from option.
-from PDA \
-pins {B} \
...

-from PDA \
-pins {D} \
...
This rule isolates net segment BF. Isolation is

placed on pin F.
D, and that also meet the requirements of the
-from option.
No isolation is inserted.
This rule does not meet the requirements of the
-from option. While the net segment connected
to pin D has a driver in the specified from
domain, the load connected to pin D is in the
same power domain.

-from PDA \
-pins {I} \
...

-to PDB \
-pins {F,G} \
...

I, and that also meet the requirements of the
-from option.
No isolation is inserted. The net segment driving
pin I has a driver in the from domain, but no
load in another domain. Isolation is ignored for a
floating net.
Isolate net segments that are driven by or
connected to pins F and G, and that also meet
the requirements of the -to option.

-to PDC \
-pins {K} \
...
June 2013

connected to pin K, and that also meet the
requirements of the -to option.
This rule isolates net segment CK. Isolation is
placed at pin K.
123

Isolation
Isolation Rule
Isolate all net segments that meet the

requirements of the -from option, except for the
net segment that is connected to, driven by, or
driving pin J.
-from PDA \
-exclude {J} \
...
Net segment CJ is not isolated because pin J

has been excluded.
-to PDC \
-pins {J} \
-exclude {K} \
...

connected to pin J and that also meet the
requirements of the -to option. Exclude net
segments connected to, driven by, or driving pin
K.
This rule does not isolate any net segments.
Isolation cannot be placed at pin J because this
would isolate K, which has been excluded.

-force -pins {I, D} \
...
-force -pins {C} \
-exclude {J} \
Force isolation at pins I and D.

Isolation is placed at pins I and D. No
driver/load analysis is performed.
This rule is ignored with an ISOFRC warning.
Cannot use -exclude with -force.
...
June 2013
124

Isolation
In the following example:
Instance I1 belongs to power domain PDA
Instance I3 belongs to power domain PDC.
Instance I2 belongs to the default power domain PDD.

i2
i1
PDD
PDA
out
mod1
i3
PDC
create_isolation_rule -name ISO -from PDA -to {PDD PDC}
This isolation rule specifies that the load in domain PDD and the load in domain PDC are to be
isolated. In this example, two isolation devices are initially placed at the power domain input
pins of the to domains:
At the power domain input pin of domain PDC
Because instance i2 is embedded in power domain PDD, the power domain input pin for
PDD is the output pin of the from domain.
The simulator then detects that the isolation device at the input pin of domain PDC is
redundant and eliminates it. The isolation placed at the output port of PDA will isolate both
loads.
June 2013
125

Isolation
i2
iso cell
i1
PDD
PDA
out
mod1
i1.out
i3
PDC
The following rule specifies that the load in domain PDD is to be isolated, but not the load in
domain PDC:
create_isolation_rule -name ISO -from PDA -to PDD
In this example, the isolation cell is placed at the power domain input pin of the to domain
(which is the same as the output pin of the from domain (i1.out)). However, this would also
isolate the load in domain PDC as shown above. To satisfy the rule, the output port of PDA is
split before the isolation device, and a link (called a direct link port) is created from the driver
in PDA to the load in PDC, as shown in the following figure:
iso cell
i1
PDD
i2
PDA
out
mod1
i3
PDC
i1.out
in
Only the load in domain PDD is isolated. The entire net (i1.out) has the isolation value. You
must probe inside PDC (i3.in) to see the value of i1.out.
June 2013
126

Isolation
Controlling Isolation Placement

By default, the virtual isolation cells are placed at the power domain input pin of the
destination domain. You can control the placement of isolation by using the
update_isolation_rules -location command. The syntax is:
update_isolation_rules -names rule_list -location {to | from | parent}
The -names option specifies the name(s) of the isolation rules to be updated.
The -location option can have one of the following arguments:
to instantiates the isolation logic inside a hierarchy belonging to the destination power
domain. Isolation will be placed at the boundary of the destination domain. In some
cases, however, it may be moved inside the destination domain for simplicity (for
example, if moving the placement would avoid having to split ports.)
from instantiates the isolation logic inside a hierarchy belonging to the originating
power domain.
parent instantiates the isolation logic in the parent domain of either the driving or the
destination domain. The domain is determined from the -isolation_target option in
the create_isolation_rule command. The -isolation_target option
determines when the isolation rule applies.
If the rule contains -isolation_target from, the rule applies when the power
domain of the drivers of the selected pins is switched off. Isolation is placed in the
parent hierarchy of the outermost logic hierarchy of the driving power domain.
If the rule contains -isolation_target to, the rule applies when the power
domain of the loads of the specified pins is switched off. Isolation is placed in the
parent hierarchy of the outermost logic hierarchy of the destination power domain.
Note: The default for -isolation_target is from.

In back-to-back isolation scenarios, two isolation devices, an off-to-on device and an on-to-off
device, are placed on the same net segment. For back-to-back isolation, the -location
option not only determines the placement of the isolation cells but can also determine the
ordering of the two cells. See Back-to-Back Isolation on page 142 for details.
The following examples illustrate the effect of the -location option on isolation placement.
June 2013
127

Isolation
Example 1
PDD
PD3
PD1
PD2
A
Table 6-2 Effect of update_isolation_rules -location Option

Isolation Rule
Isolation Placement
Isolation is placed at pin A, right at the port.
-from PD1 -to PD2 \

...
update_isolation_rules -names ISO1 \
-location from
Isolation is placed at pin B, right at the port.
-from PD1 -to PD2 \

...
-location to
Place isolation in the parent domain of the

driving domain (selected by
-isolation_target from \ -isolation_target from).
-from PD1 -to PD2 \
...
Isolation is placed in domain PDD outside of

pin A.
-location parent
June 2013
128

Isolation
Isolation Rule
Isolation Placement

destination domain (selected by
-isolation_target to).
-from PD1 -to PD2 \

-isolation_target to \
...
Isolation is placed in domain PD3 outside of

pin B.
-location parent
Example 2
PDD
PDGreen
PDRed
inst1
PDBlue
A
In this example, the instance inst1 is associated with power domain PDGreen.
June 2013
129

Isolation

Isolation Rule
Isolation Placement
Isolation is placed at pin D, and at pin E.
-to PDGreen \
...
Isolation cannot be placed at pin B because this

would isolate domain PDRed.

-location to
-to PDGreen \
-pins E \
Isolation is placed at pin E.

The -pins E option filters out pin D.
...
-location to
-to PDGreen \
...

Isolation cells are placed:

-location parent
In domain PDD, outside of pin B.

In domain PDRed, outside of pin E.
Port splitting is performed to avoid isolating

domain PDRed.
-to PDGreen \
-pins C \
...

Isolation is placed in domain PDRed outside of
pin E.
The -pins C option filters out pin D.
-location parent
June 2013
130

Isolation
Isolation Rule Priority

If multiple isolation rules are defined for the same port within the same scope, the rule with
the highest priority is applied first. The priority of isolation rules is as follows (from highest
priority to lowest priority):
Isolation rule with -force -pins options
Isolation rule with a -pins option and both -from and -to options
Isolation rule with a -pins option and either a -from or -to option
Isolation rule with both -from and -to options
Isolation rule with either a -from or -to option
If multiple isolation rules that have the same priority level apply to the same driver-receiver
pair with the same isolation_target, the last isolation rule specified in the CPF scope is applied
first. If subsequent isolation rules result in overlapping isolation at a port, a MULTISO warning
is issued for each ignored port.
Note: The -exclude option does not affect isolation rule precedence.
Specifying Isolation Values

Use the -isolation_output option to control the output value at the output of the isolation
cells when isolation is enabled. The output can be:
lowForces the output to the logic low value (0). This is the default.
highForces the output to the logic high value (1).
holdForces the output to the same logic value as the value of the signal being
isolated.
tristateForces the output to the Z value.
Note: The -isolation_output clamp_high and clamp_low arguments are supported.

For simulation, clamp_high and clamp_low are functionally equivalent to
-isolation_output high and low.
The logic behavior of low and high isolation is as follows: When the isolation control
expression is false (or, if you have used the -no_condition option, when the power
domains containing the drivers of the selected net segments are powered up), no isolation
occurs and the port signal value is propagated. When the isolation control expression is true
(or, if you have used the -no_condition option, when the power domains containing the
June 2013
131

Isolation
drivers of the selected net segments are shut off), isolation is enabled, and the signal value
propagated from the port is either 0 (for low isolation) or 1 (for high isolation). If the control
signal value should ever be X, the signal value propagated from the port is also X.
For hold isolation type, the value of the isolated output is latched when the isolation control
is enabled.
For the tristate isolation type, the value of the isolated output is the Z value.
Both lps_verbose 3 and lps_iso_verbose output type tristate. See Logging
Isolation Information on page 150, for more information.
Note: When multiple drivers are present, use -force in the isolation rule.
create_isolation_rule -force {pin_name}-isolation_output tristate
When multiple drivers are selected for isolation to tristate and there is no -force option,
lps_isofilter_verbose includes <MD> and lists isolation filtered due to multiple drivers.
Example For Multiple Drivers with Tristate Isolation Output
Use -force in the isolation rule to get isolation on ports that have multiple drivers.
This example shows out1 has five drivers.
The following command is illegal since it specifies five drivers for out1.
create_isolation_rule ISO -from PD1 -to PD3 -isolation_output tristate
June 2013
132

Isolation
When -force is not present, the multiple driver, <MD> warning is issued and isolation
filtered due to multiple drivers is listed.
The following command is legal since it uses -force with multiple drivers.
create_isolation_rule ISO1 -pins {I1/out1 I2/out1} -force -isolation_output
tristate
Controlling Isolation Enable and Disable

Based on the design intent, isolation enable and disable can be controlled by:
An explicit isolation control signal

Use the -isolation_condition expression option to specify the isolation
condition. Nets are isolated when the condition expression evaluates to true. For
example:
-from PDA \
-isolation_condition {iso_en} \
...
The power shutoff or power up of the driving power domains (the power domains
containing the drivers of the selected net segments).
Use the -no_condition option to specify that there is no explicit isolation condition.
This option specifies that the isolation logic is automatically enabled when the power
domains containing the drivers of the selected net segments are shut off. For example:
-from PDA \
-no_condition \
...
The simulator ensures that isolation is enabled before power shutdown to prevent the
propagation of unknown states on an isolated net. Isolation is automatically disabled
when the power domains are powered up.
A default isolation condition specified for the power domain that contains the leaf level
driver of the selected net
IP blocks can have special requirements for input ports. For example, when the signals
driving these input ports are switched off, the signals must be held at specific values. For
these input ports, no isolation condition can be specified because the IP developer has
no knowledge of how the IP will be used. For these cases, isolation rules must be created
June 2013
133

Isolation
without enable conditions (neither the -isolation_condition nor the
-no_condition option is specified).
If neither -isolation_condition nor -no_condition is specified, the rule is
considered incomplete. To complete an incomplete isolation rule, the simulator checks
the create_power_domain command for the originating (driving) power domain(s) of
the selected net segments to see if a default isolation condition was specified with the
-default_isolation_condition option. If a default isolation condition is defined,
that condition is used as the isolation condition.
Note: For an incomplete isolation rule, the create_isolation_rule command can
be specified only for net segments that connect to an input port of a module or a macro
cell.
Isolation Cells With Additional Controls

Some isolation cells include a synchronous enable pin or a set/reset pin, in addition to the
asynchronous isolation enable pin. These additional control pins must be specified with the
-isolation_control option. This option specifies a list of controls, where the format of
each control is as follows:
{control_type expression}
Where control_type is a keyword that indicates the type of isolation control, and
expression is a simple boolean expression to describe the driving function of the control
logic.
The control_type can be one of the following:
sync_enable
This type of control can only be used with isolation output type high or low.
This type specifies that the control is a synchronous enable pin. The corresponding
expression must be true when the isolation condition is asserted or deasserted. The
expression can be corrupted when the isolation condition is asserted.
A warning is generated if the isolation condition becomes true when the sync_enable
expression is false.
If sync_enable becomes true and the isolation condition is asserted, disabling the
sync_enable has no effect.
June 2013
134

Isolation
Examples:
-isolation_condition {iso_drvr} \
-isolation_control { {sync_enable en_drvr} } \
-secondary_domain iso_supply_domain \
-isolation_output low
-isolation_condition {iso_drvr} \
-isolation_control { {sync_enable en_drvr} } \
-isolation_output high
set
This type of control can only be used with -isolation_output hold.
This type specifies that the control is an asynchronous set pin. When the corresponding
expression is true, the stored value and isolation output will be set to 1 regardless of the
stored state.
Example:
-isolation_condition {!iso_drvr} \
-isolation_control { {set isoprez_drvr} } \
-isolation_output hold
reset
This type of control can only be used with -isolation_output hold.
This type specifies that the control is an asynchronous reset pin. When the
corresponding expression is true, the stored value and isolation output will be set to 0
regardless of the stored state.
Example:
-isolation_condition {!iso_drvr} \
-isolation_control { {reset isoclr_drvr} } \
-isolation_output hold
An error is generated if both sync_enable and either set or reset types of isolation
controls are specified in the same rule.
June 2013
135

Isolation
Specifying a Secondary Domain for an Isolation Rule

Isolation cells can have a secondary domain. The secondary domain is the domain whose
primary power and ground nets provide the power supply to the secondary power and ground
pins of the cell that is inserted in the from domain that is being switched off.
Use the create_isolation_rule -secondary_domain option to specify the
secondary domain for an isolation rule.
The isolation logic is considered powered on as long as the secondary domain is powered
on. If the secondary domain is powered off, the isolation cell drives an X value instead of the
low, high, or hold value specified with the -isolation_output option.
Note: According to the CPF specification, if a secondary domain is not specified, the
secondary domain defaults to the driving domain of the isolation enable signal. In the current
release, if a secondary domain is not specified, the simulator treats the isolation cells as
always-on.
Isolation of Glue Logic

Isolation can be applied to glue logic blocks. Isolation is placed at the nearest power domain
boundary.
Glue logic loads are identified by the output port driving the glue logic load(s). Glue logic
drivers are identified as the input port driven by the glue logic driver.
Instance i1 belongs to power domain PDA
Instance i2 belongs to power domain PDC
June 2013
136

Isolation
Power domain PDB contains a glue logic block

PDB
i1
PDA
out
i1.out
i2
PDC
in
The following isolation rule specifies isolation on the load in PDB, but not in PDC.
create_isolation_rule -name ISO1 -from PDA -to PDB ....
Isolation is placed at the to domain boundary, which is the same as the from domain
boundary because the glue logic block is embedded in domain PDB. To prevent isolation to
the load in domain PDC, the output port of PDA is split and a link (called a direct link port) is
created from the driver in PDA to the load in PDC, as shown in the following figure.
PDB
iso cell
i1
PDA
out
i2
PDC
i1.out
in
Only the load in domain PDB will be isolated. The entire net (i1.out) will have the isolation
value. You must probe inside PDC (i2.in) to see the value of i1.out.
June 2013
137

Isolation
In the following example, the glue logic block is in domain PDB. This domain also contains an
instance 13.
i3
PDB
i1
PDA
out
i1.out
i2
PDC
in
The following isolation rule specifies isolation to the load in instance i3 and to the glue logic
load, both of which are in domain PDB.
create_isolation_rule -name ISO1 -from PDA -to PDB ....
Isolation is placed at the power domain input pin of the to domain. Because the glue logic
block and instance i3 are embedded in domain PDB, the input port of the to domain is the
output port of the from domain (i1.out). To prevent isolation to the load in domain PDC, the
output port of PDA is split as shown in the following figure.
i3
PDB
iso cell
i1
PDA
out
i1.out
i2
PDC
in
June 2013
138

Isolation
Isolation of Top-Level Ports

Top-level ports of the design can be explicitly defined as boundary ports using the
Top-level input ports are assumed to have a driver in the domain associated with the
boundary port.
Top-level output ports are assumed to have a load in the domain associated with the
boundary port.
domain.
The create_isolation_rule -from and -to options filter out pins for isolation based
on drivers and loads:
-to requires that there are loads inside the specified to domain and that the net segment
is driven by a signal from another power domain.
-from requires that there are drivers inside the specified from domain and at least one
leaf load in another power domain.
The semantics of these options also applies to the top-level ports and their associated
domains. If you write a rule to isolate the inputs of a DUT (-to), input isolation will be inserted
only if there is a load in the DUT. A driver in the associated domain of the input port is
assumed, and this driver must not be in the same domain as the specified to domain. For
example, if the load in the DUT is in the default domain and the boundary ports are implicit
boundary ports, no isolation is placed because they have a driver and load in the same
domain.
If you write a rule to isolate the outputs of a DUT (-from), the ports will be isolated only if
there is a driver in the DUT. A load in the associated domain of the output port is assumed,
and this load must not be in the same domain as the specified from domain.
In the following example, the DUT is instantiated in a testbench.
June 2013
139

Isolation
TB
PDD
PD2
PD1
A
M
B
C
N
D
DUT
Domain PDD is the default power domain. This domain is always-on. Ports A, B, C, and M are
defined as boundary ports of a switchable domain called PD3.
-boundary_ports {A B C M} \
-shutoff_condition {pso}
Input ports A, B, and C are assumed to have a driver in their associated domain, PD3. Output
port M is assumed to have a load in domain PD3.
Ports D and N, which have not been defined as explicit boundary ports, become implicit
boundary ports associated with the default domain PDD. Input port D is assumed to have a
driver in domain PDD, and output port N is assumed to have a load in domain PDD.
Given the following create_isolation_rule command, input isolation will be inserted on
ports A, B, and C because the driver and load requirements are met. A driver is assumed in
the associated domain of these ports (PD3), and there is a load in PD1.
Isolation will also be placed on port D because there is (an assumed) driver in the default
domain PDD and a load in PD1.
June 2013
140

Isolation
set_design TB -testbench
create_isolation_rule -name ... \
-to PD1 \
-isolation_condition ... \
Given the following create_isolation_rule command, output isolation will be inserted

on port M because the driver and load requirements are met. There is a driver in domain PD2,
and a load is assumed in the associated domain, PD3. Isolation will also be placed on port N
because there is a driver in domain PD2, and a load is assumed in the associated domain for
this port, PDD.
-from PD2 \
The default isolation behavior also applies to cases where the DUT is instantiated in a
wrapper if the ports are wired to the testbench through the wrapper.
TB
DUT
A
C
B
PD_dut
Ports A and B are assumed to have an outside driver, either in a domain explicitly associated
with these ports, or in the default domain if they are implicit boundary ports. A -to PD_dut
isolation rule will isolate the ports if there is a load in PD_dut, and if the boundary port is not
PD_dut.
Port C is assumed to have an outside load, either in a domain explicitly associated with this
port, or in the default domain if it is an implicit boundary port. A -from PD_dut isolation rule
will isolate the port if there is a driver in PD_dut, and if the boundary port is not PD_dut.
The default behavior also applies to a modeling style in which both the testbench and the DUT
are at the top level, and in which the testbench drives DUT signals through out-of-module
June 2013
141

Isolation
references. Inputs to the DUT will be isolated if there is a load in the DUT, and outputs from
the DUT will be isolated if there is a driver in the DUT.
DUT
TB
The isolation behavior described above applies only to the top-level ports of the DUT. In the
following example, ports B and C are not top-level ports. They cannot be defined as boundary
ports and will not become implicit boundary ports. For isolation to be placed on net segment
BC, there must be a driver in domain PD_ip1 and a load in domain PD_ip2 even though it
travels through the testbench.
set_design -testbench TB
-to PD_ip2 \
# Must be a load in PD_ip2 and a

driver in another domain.
TB
IP1
A
IP2
B
PD_ip1
PD_ip2
Back-to-Back Isolation
In some cases, you may need to place two isolation devices, an off-to-on device and an
on-to-off device, on the same net segment. A common scenario is when a switchable domain
drives a standby domain. If the domain of the driver is off, the domain of the load(s) must be
isolated to prevent the propagation of unknown values. If the domain of the load(s) is in
June 2013
142

Isolation
standby, the domain must be isolated to prevent the inputs from changing. If the domain of
the load(s) is off, inputs must be isolated to prevent electrical issues (this scenario is not
relevant to simulation because, in the current release, the inputs to a domain that is off have
an unknown value during simulation).
Back-to-back isolation can be achieved by specifying the create_isolation_rule
-isolation_target {from | to} option. Two create_isolation_rules are
written, both of which specify the same net.
One of the rules includes -isolation_target from to indicate that isolation should
be on when the domain of the driver is off.
The other rule uses -isolation_target to to indicate that isolation should be on

when the domain of the load(s) is off.
Example 1
In this example, the net segment has two power domain boundaries.
PDD (AON)
i3
PDC
PDA (SW, Stby)
PDB (SW, Stby)

i2
i1
out1
in1
The CPF file includes the following rules:

create_power_domain -name PDA -instances i1 -shutoff_condition p1.pso1
create_power_domain -name PDB -instances i2 -shutoff_condition p1.pso2
create_power_domain -name PDC -instances i2 -shutoff_condition p1.pso3
June 2013
143

Isolation
create_isolation_rule -name ISOfrom \
-from PDA -to PDB \
-isolation_target from \
-isolation_condition p1.iso1 \
create_isolation_rule -name ISOto \
-from PDA -to PDB \
-isolation_condition p1.iso2 \
For back-to-back isolation, the placement and ordering of the two isolation devices is
significant. The placement and ordering of the devices is controlled by using the
update_isolation_rules -location command. See Controlling Isolation Placement
on page 127 for details on this command.
Devices Placed at Different Locations (-location to and -location from)
If the devices are not placed at the same location, they are ordered according to their
placement. For example, if the two create_isolation_rule commands shown above are
updated as follows:
update_isolation_rules -names ISOto -location from
update_isolation_rules -names ISOfrom -location to
The device protecting the destination domain (-isolation_target to) will be placed at
the boundary of the driving domain, right at port out1. The device protecting the driving
domain (-isolation_target from) will be placed at the boundary of the destination
domain, right at port in1.
June 2013
144

Isolation
PDD (AON)
i3
PDC
PDA (SW, Stby)
PDB (SW, Stby)

i2
i1
out1
T
in1
F
Both Devices Placed in the Driving Domain (-location from)

If the isolation devices are both placed in the driving domain (-location from), the
ordering of the isolation devices will be the device protecting the destination domain
(-isolation_target to), then the device protecting the driving domain
(-isolation_target from).
update_isolation_rules -names ISOfrom -location from
update_isolation_rules -names ISOto -location from
Note: Multiple isolation rule names can be specified on one command. For example:
update_isolation_rules -names ISOfrom ISOto -location from
PDD (AON)
i3
PDC
PDA (SW, Stby)
PDB (SW, Stby)

i2
i1
out1
in1
T F
June 2013
145

Isolation
Both Devices Placed in the Destination Domain (-location to)
If the isolation devices are both placed in the destination domain (-location to), the
ordering of the isolation devices will be the device protecting the driving domain
(-isolation_target from), then the device protecting the destination domain
(-isolation_target to).
update_isolation_rules -names ISOfrom -location to
update_isolation_rules -names ISOto -location to
PDD (AON)
i3
PDC
PDA (SW, Stby)
PDB (SW, Stby)

i2
i1
out1
in1
F T
Both Devices Placed in a Parent Domain (-location parent)

If the isolation devices are both placed in a parent domain (-location parent), the
ordering of the isolation devices will be the device protecting the driving domain
(-isolation_target from), then the device protecting the receiving domain
(-isolation_target to).
update_isolation_rules -names ISOfrom -location parent
update_isolation_rules -names ISOto -location parent
In this example, the device protecting the driving domain is placed in domain PDC, outside of
the port out1. The device protecting the destination domain is placed in domain PDD, outside
of the port in1.
June 2013
146

Isolation
PDD (AON)
i3
PDC
PDA (SW, Stby)
PDB (SW, Stby)

i2
i1
out1
in1
Example 2
In this example, the net segment only has one power domain boundary.
PDD (default domain, AON)

PDO (AON)
PD1 (SW, Stby)
PD2 (SW, Stby)
in1
out1
When back-to-back isolation is requested but only one power domain boundary is available,
the isolation device placed at the domain boundary is expanded to support the two user
isolations. Both the from and to isolations are applied to the same power domain boundary.
June 2013
147

Isolation
The CPF file includes the following rules:
create_isolation_rule -name ISOfrom1 \
-from PD1 -to PD2 \
-isolation_output high \
-isolation_condition p1.iso1
create_isolation_rule -name ISOto2 \
-from PD1 -to PD2 \
-isolation_output low \
create_isolation_rule -name ISOto1 \
-from PD2 -to PD1 \
-isolation_output high \
create_isolation_rule -name ISOfrom2 \
-from PD2 -to PD1 \
-isolation_output low \
In this example, the isolation device placed at p2.in1 supports both isolation rules
ISOfrom1 and ISOto2. The isolation device placed at p2.out1 supports both isolation
rules ISOto1 and ISOfrom2.
June 2013
148

Isolation
PDD (default domain, AON)

PDO (AON)
PD1 (SW, Stby)
in1
PD2 (SW, Stby)
out1
F2/T1
F1/T2
In the Waveform Window, a diagonal pattern is shown behind the waveform for isolation ports
during the region of time when isolation is in effect. With back-to-back isolation, a port is
specified in multiple isolation rules having different isolation conditions. The diagonal pattern
is drawn for all isolation rule conditions that the port is specified in.
With back-to-back isolation, an isolation port may have multiple CPF drivers. For driver tracing
in SimVision, all isolation devices and their corresponding isolation rules are included. If both
rules are active, the isolation device closest to the pin will be the active driver and this will be
listed first.
Viewing Isolation Outputs

When isolation is enabled, the simulator adds a virtual isolation cell outside the power domain
as a driver, which then drives the wire connected to the port. That is, isolation is applied to
the outside connection of the domain ports, and the inside connections are corrupted during
power down. To see the value of the isolation output, you must probe the wire/signal that is
connected to the primary output being isolated, not the port itself.
For example, suppose your design contains a module DUT instantiated in your testbench as
shown in the following code.
June 2013
149

Isolation
module DUT(inPort, outPort);
input inPort;
output outPort;
...
endmodule
module testbench();
wire inWire, outWire;
DUT dut (.inPort(inWire), .outPort(outWire));
...
endmodule
inPort is an input port, and outPort is an output port that is being isolated using CPF.
In this example, testbench.dut.outPort is the inside connection, and
testbench.outWire is the outside connection of the port. When the power domain is shut
off, the value of testbench.dut.outPort is X. To view the isolation value, you must probe
the wire connected to the isolated port. In the example above, the value of
testbench.outWire will be the expected CPF isolation value.
Note: In the current release, the inputs to a power domain that has been shut off are
corrupted. The isolation value for inputs is only visible when the domain is on or in standby
state.
Logging Isolation Information

There are several command-line options you can use to log isolation information:
-lps_verbose {1 | 2 | 3}
This option includes isolation information in the output, along with the other low-power
information. The amount of detail depends on the argument, with 3 providing the most
information. See the description of this option for details on what isolation information is
printed with each verbosity level.
-lps_iso_verbose
This option logs only the isolation information.
The output contains the location of the create_isolation_rule in the CPF file, the
isolation condition, the isolation value, and a list of the isolated signals in the following
format:
June 2013
150

Isolation
Iso rule at source:
test.cpf:18
Iso control condition:

Iso output:
(test.t1.p1.out1)
low
test.t1.d1.out1[2]
test.t1.d1.out1[1]
Iso rule at source:
test.cpf:13
Iso control condition:

Iso output:
(test.t1.p1.out1)
high
test.t1.d2.in1[3]
By default, the isolation information is written to the default log file (ncelab.log or
irun.log). Use the -lps_logfile option to create a log file that contains only the
isolation information. For example:
-lps_iso_verbose
(Writes isolation information to the

default log file)
-lps_iso_verbose -lps_logfile iso.log (Writes isolation information

to iso.log)
-lps_isofilter_verbose
This option enables reporting of isolation filtering information. Messages are printed for
pins that have not been isolated because they do not satisfy the driver or load
requirements for isolation, because placing an isolation device on the pin would be
redundant, because the pin is invalid, or because the pin has been filtered out by the
-exclude or -pins option.
By default, the isolation filtering information is written to the default log file (ncelab.log
or irun.log). Use the -lps_logfile option to create a log file that contains only the
isolation filtering information. For example:
(Writes isolation filtering information

to the default log file)
-lps_isofilter_verbose -lps_logfile iso.log (Writes isolation filtering

information to iso.log)
To get a log file containing all isolation information, including the isolation filtering
messages, use the following three options:
-lps_isofilter_verbose -lps_iso_verbose -lps_logfile filename.log
-lps_isoruleopt_warn
This option prints a warning message if an isolation rule has been optimized away.
June 2013
151

Isolation
By default, no warning message is generated when a create_isolation_rule
command is ignored. Use -lps_isoruleopt_warn to enable the printing of warning
messages, such as the following example:
ncelab: *W,NOISELE: [LPS] The isolation rule (ISO1) has no element
(./cpf.cpf:9) and the rule has been optimized away.
Viewing Isolation in SimVision

In the Power Sidebar, when you expand a power domain, information on isolation is shown
under two items:
Isolation Ports
Expanding this item shows all of the isolation ports. Different icons are used to indicate
the current isolation state of the port. See Power Sidebar Icons for a description of the
various icons used for isolation. If bits of a bus are isolated, the bits are listed separately.
For example:
Isolation Rules
This shows all of the isolation rules associated with the power domain.
You can place the cursor over any port or over any isolation rule to get detailed information
about that specific port or rule.
June 2013
152

Isolation
You can probe power domains and view them in the Waveform window, including all data
required to determine the domain state, such as state retention elements, retained signals,
and isolation ports. When you send the domain to the Waveform window, SimVision creates
a group that contains all of these domain elements. In the Waveform Window, slated red lines
are used to indicate that a port is isolated. See Using the Power Sidebar in the Waveform
Window for an example.
In the Schematic Tracer, isolated ports are indicated with a white box at the port. The isolation
type is also shown.
Ports that are isolated low are shown with a down arrow.
Ports that are isolated high are shown with a up arrow.
Ports that are isolated hold are shown with a square.
A triangle is used to indicate that a bus has mixed isolation (for example, some bits of the
bus are isolated high, other bits are isolated low). In the following schematic, the port
tb.dut.m1.add_ab.a is isolated low. Port tb.dut.m1.add_ab.b has mixed
isolation.
June 2013
153

Isolation
Note: Back-to-back isolation is not displayed correctly if both isolation cells are located on
the same port. Only one device is displayed.
June 2013
154
7
Dynamic voltage frequency scaling (DVFS) is a power management technique in which the
voltage used in a component is increased or decreased depending on performance
requirements. In a DVFS design, different portions of the design operate on different voltages,
and some portions can dynamically change voltages depending on the design mode or can
even be switched off. Scaling down the voltage and frequency of components when peak
performance is not required can significantly reduce power consumption.
In a DVFS design, you must:
Specify the nominal operating conditions. A nominal operating condition is a typical

operating condition under which the design or blocks perform. An operating condition is
determined by the voltages of all power supplies applied to a power domain, including
the power voltage, ground voltage, and the body bias voltage for PMOS and NMOS
transistors. Depending on the technology used, this set of voltages determines whether
the state of a power domain is on, off, or in standby mode.
Specify the power domains. In DVFS designs, a collection of logic blocks (hierarchical
instances) and leaf instances that use the same main power supply and whose voltage
and frequency can simultaneously change or be switched off belong to the same power
domain.
Define the conditions that control the transition of power domains to specific nominal
conditions.
Specify the time it takes for power domains to transition from one nominal condition to
another nominal condition.
CPF includes commands that let you specify the transition of power domains to specific
nominal conditions:
By defining controls with power modes and power mode transitions

To define this type of domain transition control, you specify the nominal conditions, create
the power domains, and then define the power modes. A power mode defines the state
of the nominal conditions of all of the power domains in a specified scope of the design.
June 2013
155

In other words, a power mode is a collection of power domains, each of which operates
at a specific nominal condition.
The combination of a power domain and its nominal condition is called a domain
condition. Domain conditions for a power mode are specified with the
-domain_conditions option of the create_power_mode command.
# Create nominal conditions
create_nominal_condition -name high \
-voltage 1.2 -state on
create_nominal_condition -name low \
# Create power modes
create_power_mode -name M1 \
-domain_conditions {PD1@high PD2@low}
-domain_conditions {PD1@low PD2@high}
After defining the power modes, you define the power mode transitions. A mode
transition describes a transition from one power mode to a different power mode. Mode
transitions are defined with the create_mode_transition command. For example:
create_mode_transition -name mt1 \
-from M1 -to M2 \
-start_condition {pmc.mte[1]}
See Controlling Power Domain Transitions with Power Mode and Mode Transition
Controls on page 159 for details.
By defining controls at the domain level

At the domain level, you specify the nominal conditions for a power domain and, for each
nominal condition, the condition that starts the transition to the specific nominal
condition.
The combination of a nominal condition and its start condition is called an active state
condition. The active state conditions for a power domain are specified with the
-active_state_conditions option of the create_power_domain command. For
example:
# Create nominal conditions
create_nominal_condition -name high \
June 2013
156

create_nominal_condition -name low \
# Specify active state conditions
-instances ... \
-shutoff_condition ... \
-active_state_conditions {high@pmc.ase_high low@pmc.ase_low}
See Controlling Power Domain Transitions with Domain-Level Controls on page 172 for
details.
Because CPF includes both domain-level controls and mode-level controls, it is possible to
drive domain condition transitions using either methodology. At a higher level of abstraction,
you can define power modes and mode transitions. Driving the simulation through the power
mode specification is useful for exploring and debugging domain control.
At a lower level of abstraction, you can have a mix of mode-level and domain-level controls.
Each specification can be incomplete, with the two complementing each other to define the
complete control over domain conditions. In this case simulation is performed with the
-lps_pmode option. See Controlling Power Domain Transitions with Power Mode and Mode
Transition Controls on page 159 for details. Or the two specifications can be complete, with
the domain-level specification implementing the mode-level specification, which provides a
way to verify the former. In this case simulation is performed with the -lps_pmcheck_only
option. See Controlling Power Domain Transitions with Domain-Level Controls on page 172
for details.
Controlling a Power Mode Simulation

You can drive the simulation using the domain-level controls or the mode/mode transition
controls. The choice of methodology, or use model, is controlled by the following elaborator
command-line options.
-lps_mvs
This option turns on voltage scaling simulation and voltage tracking. All domain
transitions are specified at the domain level using the create_power_domain
command (-shutoff_condition and -active_state_conditions). Power mode
(create_power_mode) and mode transition (create_mode_transition)
commands, if present in the CPF file, are ignored. Built-in power mode and mode
transition checking is not performed.
June 2013
157

-lps_pmode
This option turns on power mode simulation, mode tracking, and built-in mode checking,
in addition to voltage tracking.
Use -lps_pmode if you intend to drive the simulation through the power mode
specification. Power mode and mode transition commands affect the domain states and
state transitions. Specifying all active state conditions at the domain level is not
necessary. Checks are performed to ensure consistency between domain-level and
mode-level controls. The simulator generates a warning if there is a conflict between the
power modes and the active state conditions.
The -lps_pmode option implies -lps_mvs. You can include both options on the
command line, or just -lps_pmode.
% irun -lps_cpf dut.cpf -lps_mvs -lps_pmode ....
% irun -lps_cpf dut.cpf -lps_pmode ....
-lps_pmcheck_only
This option specifies that power mode and mode transitions will be used for verification
only. Domain-level controls drive the domain transitions, and the power modes are used
for verification, not control.
In this mode, all nominal conditions, active state conditions, and power mode and mode
transitions must be specified.
The -lps_pmcheck_only option implies -lps_mvs and -lps_pmode. You can
include all three options on the command line, or just -lps_pmcheck_only.
% irun -lps_cpf dut.cpf -lps_mvs -lps_pmode -lps_pmcheck_only ....
% irun -lps_cpf dut.cpf -lps_pmcheck_only ....
Power Mode Example

Figure 7-1 on page 159 shows the power domain hierarchy for the example used in the
following sections. There are three power domains:
pdT, the default power domain, is always on.

This power domain can operate at two voltage levels (nominal conditions): .8V and 1.2V.
pdA contains instance instA. The power shutoff signal is pseA.

This power domain can operate at two voltage levels: .8V and 1.2V.
pdB contains instance instB. The power shutoff signal is pseB.

This power domain can operate at three voltage levels: .5V, .8V, and 1.2V.
June 2013
158

The design also includes a second top-level module, which defines the power module
controller. This controller generates the shutoff control signals, save and restore state
retention signals, and signals to control the power domain transitions.
Figure 7-1 Power Mode Example
top
pdT
instA
pdB
pdA
instB
pseB
pseA
Controlling Power Domain Transitions with Power Mode

and Mode Transition Controls
Note: The source files for the example used in this section are included in your installation at
the following location:
install_directory/doc/PowerForwardUG/examples/power_modes
To write a power mode specification, you must:

1. Define the nominal conditions used in the design. See Defining the Nominal Conditions
on page 160.
2. Specify the power modes. See Specifying the Power Modes on page 160.
3. Describe the legal power mode transitions. See Describing the Power Mode Transitions
on page 162.
4. Specify the time it takes for power domains to transition from one nominal condition to
another nominal condition. See Specifying the Time It Takes for Power Domain
Transitions on page 165.
June 2013
159

Defining the Nominal Conditions

To specify the nominal conditions, use the create_nominal_condition command.
Syntax:
-name string
-voltage float [-ground_voltage float]
[-state {on | off | standby}]
[-pmos_bias_voltage float] [-nmos_bias_voltage float]
All voltages must be specified in volts (V).

Each nominal condition must be specified as one of the following states:
off. The logic of a power domain in an off state will be corrupted unless a base power
domain in an on state is used to maintain valid values.
on. The logic of a power domain in an on state is fully operational. This is the default if
the voltage specified with the -voltage option is non-zero.
standby. The logic of a power domain in a standby state maintains its logic values as
long as the inputs are stable. If the inputs are changed, the values are corrupted.
The nominal conditions defined for the example are specified with the following
create_nominal_condition commands:
create_nominal_condition -name NC_08 \
create_nominal_condition -name NC_12 \
create_nominal_condition -name NC_OFF \
-voltage 0.0 -state off
create_nominal_condition -name NC_STANDBY \
-voltage 0.5 -state standby
Specifying the Power Modes

A power mode defines the state of the nominal conditions of all power domains in a specified
scope of the design. In other words, a power mode is a collection of power domains, each of
which operates at a specific nominal condition.
June 2013
160

Power modes let you identify which combinations of power domain states are valid, and which
are not. Any combination of nominal conditions that is not defined in the CPF file is considered
an illegal power mode.
Use the create_power_mode command to define the power modes.
Syntax:
create_power_mode
-name string [-default]
{-domain_conditions domain_condition_list
| -group_modes group_mode_list
| -domain_conditions domain_condition_list -group_modes group_mode_list}
Note: The -group_modes option is used to specify the mode of each power mode control
group to be considered with the defined mode. See Power Mode Control Groups on
page 177 for information on power mode control groups.
If you define any power mode, you must define one (and only one) power mode as the default
mode. The default mode, specified with the -default option, is the mode that corresponds
to the initial state of the design.
Use the -domain_conditions option to specify the nominal condition of each power
domain to be considered in the specified power mode. A power domain can be associated
with only one nominal condition for a given power mode.
A domain condition specifies a power domain in a specific nominal condition using the
following format:
domain_name@nominal_condition_name
For example:
-domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_12}
In the example, the valid power modes for the design are shown in the following table:
Figure 7-2 Legal Power Modes
Power Mode
M1
June 2013
Corresponding Power Domains and

Nominal Conditions
pdT
pdA
pdB
NC_08
NC_08
NC_OFF
161

Power Mode
Corresponding Power Domains and

Nominal Conditions
pdT
pdA
pdB
M2
NC_08
NC_OFF
NC_08
M3
NC_12
NC_12
NC_12
M4
NC_08
NC_OFF
NC_OFF
M5
NC_12
NC_12
NC_STANDBY
The power modes shown in the table are specified with the following create_power_mode
commands:
-domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF}
-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_08}
# Power mode M3 is the default power mode. This corresponds to
# the initial state of the design.
-default \
-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF}
-domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_STANDBY}
Describing the Power Mode Transitions

A power mode transition describes a transition from one power mode to a different power
mode. It defines the power mode from which to transition and the power mode to which to
transition, the condition that triggers the transition, and the time needed to complete the
transition.
Mode transitions let you control how the chip is allowed to change from one power mode to
another power mode. Mode transitions that are not defined in the CPF file are considered
illegal transitions.
June 2013
162

Use the create_mode_transition command to describe the legal mode transitions.
Syntax:
-name string
-from power_mode -to power_mode
-start_condition expression [-end_condition expression]
[ -cycles [integer:]integer -clock_pin clock_pin
| -latency [float:]float ]
Note: The -cycles and -clock_pin options are not supported in the current release.
The -from and -to options, which specify the power mode from which to transition and the
power mode to which to transition, are both required.
Use -start_condition to specify the condition that triggers the power mode transition.
The -end_condition option can be used to specify the condition that acknowledges that
the design is in the power mode specified with the -to option.
Use the -latency option to specify the time needed to complete the power mode transition.
Specify the time in the units specified with the set_time_unit command.
If you specify two numbers, the first number indicates the minimum time needed, and the
second number indicates the maximum time needed.
If you specify only one value, it is considered to be the maximum number. You can
override this default and use the minimum time with the elaborator -lps_mtrn_min
option.
The following figure shows the legal power mode transitions and the transition start conditions
for the example:
June 2013
163

Figure 7-3 Legal Power Mode Transitions
M2
M1
mte[5]
mte[1]
mte[2]
mte[4]
mte[6]
M4
M3
M5
mte[3]
In a create_mode_transition command, the starting mode (-from) and the transition

start condition (-start_condition) must uniquely determine the destination mode (-to).
For example, in the diagram above, transitions from M3 to M1, M2, or M5 are valid. Therefore,
mte[1], mte[4], and mte[6] must be unique signals. The other signals used as the start
condition (mte[2], mte[3], and mte[5]) could be the same signal.
For the example, the power mode transitions shown in the diagram above are specified with
the following create_mode_transition commands:
-from M3 -to M1 \
-from M1 -to M4 \
-from M4 -to M3 \
-from M3 -to M2 \
June 2013
164

-from M2 -to M4 \
-from M3 -to M5 \
Specifying the Time It Takes for Power Domain Transitions

The delay is determined by the transitional properties of the power domain, which are
specified with an update_power_domain command. The delay can be specified with the
-transition_slope or -transition_latency option.
Note: The -transition_cycles option is not supported in the current release.
Use the -transition_slope option to specify the transition rate for the supply voltage
of the domain during any state transition of the domain.
update_power_domain -name domain_name \
-transition_slope [float:]float
The unit for a transition rate is volts per time unit (specified by the set_time_unit
command). By default, the transition rate is defined as V/ns (volts per nanosecond).
If you specify two numbers, the first number indicates the minimum transition rate,
and the second number indicates the maximum transition rate.
If you specify only one value, it is considered to be the maximum transition slope.
By default, the simulator uses the maximum transition time. You can override this default
and use the minimum slope with the elaborator -lps_dtrn_min option (ncelab
-lps_dtrn_min or irun -lps_dtrn_min). If a single number has been specified,
the number is treated as the minimum.
Examples:
update_power_domain -name pdA \
-transition_slope 0.2
update_power_domain -name pdB \
-transition_slope 0.2:0.4
June 2013
165

Use the -transition_latency option to specify the transition time from a specific
nominal condition to another specific nominal condition. The syntax is:
-transition_latency {from_nom to_nom@[float:]float}
from_nom specifies the nominal condition of the starting power state.

to_nom specifies the nominal condition of the next power state.
If you specify two numbers, the first number indicates the minimum time needed to
complete the transition, and the second number indicates the maximum time
needed to complete the transition.
If you specify only one value, it is considered to be the maximum transition time.
Specify the time in the units specified by the set_time_unit command. The default
time unit for set_time_unit is ns.
By default, the simulator uses the maximum transition time. You can override this default
and use the minimum latency with the elaborator -lps_dtrn_min option (ncelab
-lps_dtrn_min or irun -lps_dtrn_min). If a single number has been specified,
the number is treated as the minimum.
Note: The CPF specification allows a list of latencies. For example:
-transition_latency {nom1 nom2@1.2 nom3 nom4@2.0}
Specifying a latency list is not supported in the current release. Only one to_nom
argument can be specified. You can specify multiple commands to update the same
power domain. All unique transitions (with different starting and ending states) will be
appended to form a complete state transition table for the domain. If any specific
transition is specified more than once, the transition time specified in the last
update_power_domain command will be used.
Examples:
update_power_domain -name PD1 \
-transition_latency {NC_off NC_standby@2.3}
-transition_latency {NC_standby NC_slow@1.4:2.0}
Resolving Transition Slope and Transition Latency Specifications

The following rules are used when a transition slope and/or transition latency is specified:
If a domain has just the slope defined, use that slope for all transitions.
June 2013
166

If a domain has both a slope and latency defined, use the latency where it exists, and
use the slope for transitions that do not have a latency defined.
When merging a child domain to a parent domain:
If the child domain has a larger latency value than the parent, use the larger value
(with a warning).
If the parent domain has a larger latency value than the child, use the larger value
(without a warning).
If a latency is defined for the child domain, but no latency is defined for the parent
domain, use the latency from the child domain (without a warning).
Example
Suppose that a power domain PD1 has four nominal conditions and three transitions, as
follows:
0v (NC_off) to .8v (NC_standby)
.8v (NC_standby) to 1.2v (NC_slow)
1.2v (NC_slow) to 1.5v (NC_fast)
The following two commands define transition latencies for the first two transitions:
-transition_latency {NC_off NC_standby@2.3}
-transition_latency {NC_standby NC_slow@1.4}
A transition slope (in V/ns) is also defined for domain PD1 with the following command:
-transition_slope .3
In this example, the defined transition latencies will be used for the first two transitions.
The transition slope will be used for the third transition. The transition time is 1 ns
(.3v/(.3v/ns)).
June 2013
167

Running the Example

Note: The example is included in your installation at the following location:
install_directory/doc/PowerForwardUG/examples/power_modes
In this example, domain condition controls are specified at the mode level in the CPF file with
create_power_mode and create_mode_transition commands. Use the
-lps_pmode option to run the example. This option turns on power mode simulation and
specifies that mode-level controls drive domain state transitions.
The power module controller (pmc.v) for this example sets the mode transition enable signal
(mte), specified as the start_condition in the create_mode_transition commands, to
specific values. The value of mte determines the value of signal desired_mode, which
controls the power domain transitions.
In this example, a transition slope is specified for domain pdA with the following command:
# Specify transition rate for power domain pdA (0.2 volts/ns)
See Specifying the Delay for a Power Domain to Reach its Destination Nominal Condition
on page 173 for details on the command.
To run the example with irun:
irun -access +rwc -gui -input input.tcl \
-lps_cpf dut.cpf -lps_pmode -lps_stime 1ns -lps_verbose 3 \
dut.v pmc.v &
To run in multi-step invocation mode:

ncvlog -messages dut.v pmc.v
ncelab -messages -access +rwc -lps_cpf dut.cpf -lps_pmode \
-lps_stime 1ns -lps_verbose 3 \
worklib.top worklib.pmc
ncsim -gui -input input.tcl worklib.top &
The simulation output in the SimVision console window shows the following:
The system is initially in power mode M3, specified as the default mode in the CPF file.
All power domains are in nominal condition NC_12 (1.2 V).
At time 99 ns, mode transition mt1 (from mode M3 to mode M1) begins. Mode M1 is
defined as follows:
June 2013
168

-domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF}
At time 99 ns, domain pdT transitions to nominal condition NC_08 (no transition slope
has been defined for pdT).
At time 99 ns, domain pdA starts transitioning from NC_12 (1.2 V) to NC_08 (.8 V). The
transition slope for pdA is defined as .2V/ns.
At time 100 ns, the power shutoff signal for domain pdB (pseB) is asserted. A transition
slope for pdB has not been defined, so pdB transitions to nominal condition NC_OFF at
100 ns.
At time 101 ns, power domain pdA has finished transitioning to nominal condition NC_08.
ncsim> run
0 clk=0 data=000000 ndata=111111
5 clk=1 data=000001 ndata=111110
...
95 clk=1 data=001010 ndata=110101
At simulation time 99 NS:
Mode transition mt1 [M3->M1] has started.

condition NC_08
Power domain pdT has transitioned to nominal

nominal condition NC_08
Power domain pdA has started transitioning to

Power domain pdB is being powered off

Power domain pdB has transitioned to power off state
100 clk=0 data=001010 ndata=xxxxxx

Power domain pdA has finished transitioning to
Mode transition mt1 [M3->M1] has completed.

...
June 2013
169

At time 194 ns, mode transition mt2 (from mode M1 to mode M4) begins. Mode M4 is
defined as follows:
-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF}
At time 194 ns, the power shutoff signal for domain pdA (pseA) is asserted, so data
goes to X. Domain pdA starts transitioning from nominal condition NC_08 (.8 V) to
nominal condition NC_OFF.
At time 198 ns, power domain pdA has finished transitioning to NC_OFF.
Power domain pdA is being powered off

off state
Power domain pdA has started transitioning to power
194 clk=0 data=xxxxxx ndata=xxxxxx

power off state

...
At time 298 ns, domain pdA starts transitioning from NC_OFF to NC_12 (1.2 V). The
transition is completed at time 304 ns. The restore signal (pgeA) occurs at 304 ns, and
data is restored.

condition NC_12
Power domain pdT has transitioned to nominal
Power domain pdA is being powered up

Power domain pdB is being powered up
June 2013
170

condition NC_12
Power domain pdB has transitioned to nominal

304 clk=0 data=010011 ndata=101100

305 clk=1 data=010100 ndata=101011
...
...
At time 502 ns, the system is in power mode M2. Power mode transition mt3 (from M4 to
M3) is illegal.
At time 503 ns, domain pdA starts transitioning from NC_OFF to NC_12. The restore
signal comes at 506 ns, which is during the transition time, so nothing gets restored.
current mode (M2)
Power mode transition (mt3) is illegal for the

transition is in progress
Power domain pdA is being power up while no mode


At simulation time 509 NS: The system is now in a transitional or undefined

mode, and has not reached a stable power mode yet
...
...
718 clk=1 data=011110 ndata=100001

...
815 clk=1 data=101000 ndata=010111
At time 816 ns, the system is in mode M3, and mode transition mt6 (from mode M3 to
mode M5) starts. Domain pdB transitions to the standby state. While the domain is in
June 2013
171

standby mode, its inputs should be isolated and should not toggle. When an input does
toggle during standby mode, the input is corrupted, and a standby mode input violation
warning message is generated.
At time 825 ns, bit 0 of the input bus instB.x toggles and is corrupted. As more bits of
the bus toggle, the bits go to X, and additional messages are generated.
Use the -lps_stdby_nowarn option to suppress the input violation messages.

condition NC_STANDBY
Power domain pdB has transitioned to nominal
Standby mode input violation (top.instB.x[0])!
825 clk=1 data=101001 ndata=01011x

830 clk=0 data=101001 ndata=01011x
835 clk=1 data=101010 ndata=0101xx

840 clk=0 data=101010 ndata=0101xx
...
Simulation complete via $finish(1) at time 1 US + 0
./dut.v:23
#1000 $finish;
ncsim>
Controlling Power Domain Transitions with Domain-Level

Controls
Note: The source files for the example used in this section are included in your installation at
the following location:
install_dir/doc/PowerForwardUG/examples/power_modes_plus_active_state_cond
To create domain-level controls:

1. Define the operating voltages (nominal conditions) used in the design.
2. Specify the conditions for the power domains to transition to specific nominal conditions.
3. Specify the delay it takes for a power domain to reach its destination nominal condition.
June 2013
172

Defining the Nominal Conditions

Use the create_nominal_condition command to specify the nominal conditions. See
Defining the Nominal Conditions on page 160.
Specifying the Conditions for the Power Domains to Transition to Specific

Nominal Conditions
Use the create_power_domain -active_state_conditions option to specify the
boolean conditions for a power domain to transition to specific nominal conditions.
Use the following format to specify an active state condition:
nominal_condition_name@expression
When a condition changes to true, the power domain starts the transition to the specified
nominal condition.
The active state conditions for the three power domains in the example are specified with the
following three create_power_domain commands:
create_power_domain -name pdT \
-default \
-active_state_conditions {NC_08@pmc.aseT08 NC_12@pmc.aseT12}
create_power_domain -name pdA \
-instances instA \
-shutoff_condition pmc.pseA \
-base_domains {pdT}
-active_state_conditions {NC_08@pmc.aseA08 NC_12@pmc.aseA12}
create_power_domain -name pdB \
-instances instB \
-shutoff_condition pmc.pseB \
-base_domains {pdT}
-active_state_conditions {NC_STANDBY@pmc.aseB05
NC_08@pmc.aseB08 NC_12@pmc.aseB12}
Specifying the Delay for a Power Domain to Reach its Destination Nominal
Condition
The delay is determined by the transitional properties of the power domain, which are
specified with an update_power_domain command. The delay can be specified with the
June 2013
173

-transition_slope or -transition_latency option. See Specifying the Time It
Takes for Power Domain Transitions on page 165 for details.
Inheritance of Active State Conditions

Normally, each domain should have active state conditions and nominal conditions defined,
as the active state conditions cause a domain to assume the correct nominal condition.
If a domain has active state conditions specified, the voltage is driven by its active state
conditions. In the example shown above, every domain (pdT, pdA, and pdB) has active state
conditions defined, and the voltage of the domains is driven by the respective active state
conditions.
When a derived domain does not have any nominal conditions or active state conditions
defined, it will inherit them from its parent (base domain).
A derived domain will inherit voltage from its base domain only when:
The derived domain does not have active state conditions.
The derived domain has only one base domain. If the derived domain has multiple base
domains, a warning is generated stating that the derived domain cannot inherit voltages
from multiple base domains. For these cases, active state conditions should be specified
for the domain.
There are no restrictions on the active state conditions for the base and derived domains. No
checks are performed, and no warning is generated, if the derived domain has a nominal
condition that is different from its base domains.
Note: The derived domain also inherits the delays of the base domain.
Examples
Domain PDD has active state conditions.
Domain PD1 inherits active state conditions from PDD.
Domain PD2 inherits active state conditions from PD1.
June 2013
174

create_power_domain name PDD \

-active_state_conditions {nc08@asc08 nc10@acs10}
create_power_domain name PD1 \
-base_domains {PDD}
-base_domains {PD1}
Domain PD1 inherits active state conditions from PDD.
Domain PD2 will use its own active state conditions.

-base_domains {PDD}
-base_domains {PD1}
Domain PD1 will use its own active state conditions.
Domain PD2 has multiple base domains. Domain PD2 cannot inherit active state
conditions from both PDD and PD1, and a warning is generated.
June 2013
175


-active_state_conditions {nc05@asc05 nc09@asc09}
-base_domains {PDD PD1}
Running the Example

Note: The example used in this section is included in your installation at the following
location:
install_dir/doc/PowerForwardUG/examples/power_modes_plus_active_state_cond
In this example, domain condition controls are specified in the CPF file both at the
mode/mode transition level (with create_power_mode and create_mode_transition
commands) and at the domain level (with active state conditions). You can drive the
simulation with either set of controls.
The power module controller (pmc.v) for this example sets the mode transition enable signal
(mte), specified as the start_condition in the create_mode_transition commands,
to specific values. The value of mte determines the value of signal desired_mode, which
controls the values of the active state enable signals.
In the example, a transition slope is defined for power domain pdA with the following
command:
Use the -lps_pmode option to drive the simulation using the power mode/mode
transition specification.
-lps_cpf dut.cpf -lps_pmode -lps_stime 1ns -lps_verbose 3 \
dut.v pmc.v &
Use the -lps_pmcheck_only option to drive the simulation using the active state
conditions. This option specifies that power mode and mode transitions will be used for
verification only. Domain-level controls drive the domain transitions, and the power
modes are used for verification, not control.
June 2013
176

-lps_cpf dut.cpf -lps_pmcheck_only -lps_stime 1ns -lps_verbose 3 \
dut.v pmc.v &
Power Mode Control Groups

A power mode control group is a set of power domains with an associated set of power modes
and mode transitions that apply to this group only. All power modes defined for this group can
only reference power domains within this group. All power mode transitions can only
reference power modes defined for this group.
Power mode control groups are used in a hierarchical flow where a piece of reusable IP has
defined power modes in the CPF for that IP. When the IP block is instantiated, the CPF for the
higher level can define its own power mode control group. The power modes defined in that
control group can then specify:
The nominal condition of each power domain to be considered in the specified power
mode (using the create_power_mode -domain_conditions option)
The mode of each power mode control group to be considered in the specified power
mode (using the create_power_mode -group_modes option)
Each power domain must belong to one and only one power mode control group. Also, each
power mode control group must have one and only one default power mode.
A power mode control group can contain other power mode control groups. If a power mode
control group has another power mode control group as its member and the other power
mode control group is not referenced in any power mode definition, the other power mode
control group is assumed to be in the default power mode of that group.
If a power mode control group in a lower scope is not referred to by another power mode in
an upper scope, the power mode at the block level is ignored at the top level.
Default Power Mode Control Group

A default power mode control group is automatically created for each CPF scope. To
reference the default power mode control group of a scope, use the hierarchical path from the
current scope to the targeted scope.
The default power mode control group for a scope contains all those power domains defined
in this scope that are not declared as members of an explicitly defined power mode control
group. In other words, if all power domains of a scope belong to an explicitly defined power
mode control group, the default power mode control group has no members.
June 2013
177

User-Created Power Mode Control Group

Within a scope, you can create one or more power mode control groups. A power mode
control group can be referenced by its hierarchical name in top-level CPF commands.
The set_power_mode_control_group and end_power_mode_control_group
commands define the start and end of a power mode control group definition. These
commands group a set of CPF commands that define the power modes and power mode
transitions that apply to this group only.
Syntax
set_power_mode_control_group -name group
{ -domains domain_list
| -groups group_list
| -domains domain_list -groups group_list }
The options are:
-name group
Specifies the name of the power mode control group.
-domains domain_list
Specifies the list of power domains controlled by the power control manager associated
with the specified group.
A power domain that is not part of any power mode definition within a power mode control
group is assumed to be powered down.
-groups group_list
Specifies the list of power mode control groups whose power control manager is
controlled by the power control manager associated with the specified group.
The following CPF commands are allowed in a power mode control group definition:
create_analysis_view (not relevant for simulation)
create_power_mode
update_power_mode
June 2013
178

Example 1: Using a Default Power Mode Control Group
In the following example, BLOCKA is a hierarchical block consisting of two power domains,
PD_C1 and PD_C2.
TOP
INST_A
BLOCKA
PD_B
PD_C1
PD_C2
The power modes and mode transitions for BLOCKA are shown in the following diagram.
M3a
M1
M1a
M3
M1b
M2a
M2
The CPF file for this block defines the power domains, power modes, and power mode
transitions for the block. The power modes and power mode transitions are defined with
respect to the power domains at this level of hierarchy in the design.
June 2013
179

# BLOCKA.cpf
set_design BLOCKA
create_power_domain -name PD_C1 -instances ...
create_power_domain -name PD_C2 -instances ...
create_nominal_condition -name on \
create_nominal_condition -name off \
create_nominal_condition -name ... \
-voltage ... \
-state ...
No explicit power mode control group is created.

The default power mode control group contains
both power domains defined in this scope.
Mode M1 is the default power mode.

create_power_mode -name M1 -default \
Each power mode control group must
-domain_conditions {PD_C1@off PD_C2@on}
have one default power mode.
create_power_mode -name M1a \
-domain_conditions {...}
create_power_mode -name M1b \
-domain_conditions {PD_C1@on PD_C2@on}
Power domain PD_C2 is not referenced, and
-domain_conditions {PD_C1@on}
is assumed to be in the off state.
create_mode_transition -name CT1 -from M1 -to M2

create_mode_transition -name CT2 -from M1 -to M1a
create_mode_transition -name CT3 -from M1a -to M1b
create_mode_transition -name CT4 -from M1b -to M2
...
[Other legal mode transitions]
...
end_design
While the CPF file for the IP block must specify all power modes and mode transitions that
are required for the correct low-power behavior of the block, only a subset of these power
modes may be relevant when the IP block is instantiated in the design. For example, when
BLOCKA is used in the design, modes M1, M2, and M3 may be the only modes that are
relevant.
June 2013
180

Creating a power mode control group at the higher level lets you define a group that includes
the power mode control group for the IP block. Then, when you define the power modes, you
can specify that the power mode control group for the block must be in one of the relevant
power modes.
Note: When BLOCKA in the example is instantiated, the hierarchical scope name of the block
(INST_A) must be used to refer to the default power mode control group for BLOCKA.
The following file is the CPF file for design TOP. In this file, a power mode control group called
top is created. This group includes power domain PD_B and the default power mode control
group for BLOCKA.
When defining a power mode for design TOP:
Use the -domain_conditions option for any power domains at this level of hierarchy.
Use the -group_modes option to refer to the power mode of BLOCKA.
For example:
create_power_mode -name T3 -domain_conditions {PD_B@on} -group_modes {INST_A@M3}
If the power mode control group for BLOCKA is not referenced in a top-level power mode
definition, it is assumed to be in the default mode of the power mode control group (mode M1
in this example).
June 2013
181

# TOP.cpf
set_design TOP
create_power_domain -name PD_B
Create power mode control group. This group
contains power domain PD_B and the default
power mode control group for BLOCKA. The
hierarchical scope name of BLOCKA (INST_A)
is used to refer to this control group.
set_instance INST_A
include BLOCKA.cpf
set_power_mode_control_group -name top \

-domains PD_B -groups INST_A
create_power_mode -name T1 \
-domain_conditions {PD_B@on}
Mode T1 does not reference the power mode control group

(INST_A), so the power mode control group is assumed
to be in its default mode (mode M1).
Mode T2 is created with domain PD_B at nominal
condition off and power mode control group of BLOCKA
(INST_A) in power mode M2, in which both block-level
domains PD_C1 and PD_C2 are at nominal condition on.
-domain_conditions {PD_B@off} \
-group_modes {INST_A@M2}
Power mode T3 is the default mode.
create_power_mode -name T3 -default \

-domain_conditions {PD_B@on} \
-group_modes {INST_A@M3}
create_mode_transition -name TT1 -from T1 -to T2
end_design
End power mode control group definition.
Example 2: Using a User-Created Power Mode Control Group

In Example 1, the CPF file for BLOCKA did not contain set_power_mode_control_group
and end_power_mode_control_group commands to define a power mode control group.
A default group was created, which was referred to in the top-level CPF using the hierarchical
scope name of the block (INST_A).
The BLOCKA.cpf file in Example 1 could have been written using an explicitly created power
mode control group. IP blocks can also, of course, contain multiple power mode control
groups with unique names.
The following example includes a user-created power mode control group in the CPF file for
the IP block. This example illustrates:
How to refer to this power mode control group in the top-level CPF
June 2013
182

How different instantiations of the IP block can have unique power mode and mode
transition specifications
The following file is the block-level CPF file.

# BLOCKA.cpf
set_design BLOCKA
create_power_domain -name PD_C1
create_power_domain -name PD_C2
create_nominal_condition -name on \
create_nominal_condition -name off \
create_nominal_condition -name ... \
-voltage ... \
-state ...
Create power mode control group BLOCKA_PMCG.

This group contains both power domains
defined in this scope.
set_power_mode_control_group -name BLOCKA_PMCG \

-domains {PD_C1 PD_C2}
Default power mode for the power mode
create_power_mode -name M1 -default \
control group.
-domain_conditions {PD_C1@off PD_C2@on}
create_power_mode -name M1b \
-domain_conditions {PD_C1@on PD_C2@on}
Power domain PD_C2 is not referenced, and
-domain_conditions {PD_C1@on}
is assumed to be in the off state.

create_mode_transition -name CT2 -from M1 -to M1a
[Other legal mode transitions]
...
end_design
June 2013
End power mode control group BLOCKA_PMCG definition.
183

The following is the top-level CPF file. In this file, IP block BLOCKA is instantiated two times
as BLOCKA_inst1 and BLOCKA_inst2. Each instantiation includes a power mode control
group, which contains power modes and mode transitions that are unique to that instance.
The power mode control group for BLOCKA (BLOCKA_PMCG) is referenced by its hierarchical
name in the top-level CPF commands.
June 2013
184

# TOP.cpf
set_design TOP
create_power_domain -name PD_B
Create power mode control group topPMCG1. This
group contains power domain PD_B and power mode
control group BLOCKA_PMCG for BLOCKA. Use the
hierarchical scope name to refer to this control
group.
set_instance BLOCKA_inst1
include BLOCKA.cpf
set_power_mode_control_group -name topPMCG1 \

-domains PD_B -groups BLOCKA_inst1/BLOCKA_PMCG
-domain_conditions {PD_B@on}
Mode T1 does not reference the power mode control group

(BLOCKA_PMCG), so the power mode control group is
assumed to be in its default mode (mode M1).
Mode T2 is created with domain PD_B at

nominal condition off and power mode control
-domain_conditions {PD_B@off} \
group BLOCKA_PMCG in power mode M2.
-group_modes {BLOCKA_inst1/BLOCKA_PMCG@M2}
...
[Other power mode definitions for BLOCKA_inst1]

...
[Other power mode transitions for BLOCKA_inst1]
...
End power mode control group topPMCG1 definition.
Create power mode control group topPMCG2.
This group contains power domain PD_B and
power mode control group BLOCKA_PMCG for
BLOCKA. Use the hierarchical scope name to
refer to this control group.
set_instance BLOCKA_inst2
include BLOCKA.cpf
set_power_mode_control_group -name topPMCG2 \

-domains PD_B -groups BLOCKA_inst2/BLOCKA_PMCG
Mode T3 is created with domain PD_B at

nominal condition on and power mode control
group BLOCKA_PMCG in power mode M3.
-domain_conditions {PD_B@on} \
-group_modes {BLOCKA_inst2/BLOCKA_PMCG@M3}
[Other power mode definitions for BLOCKA_inst2]

...
...
[Other power mode transitions for BLOCKA_inst2]
...
End power mode control group topPMCG2 definition.
end_design
June 2013
185

June 2013
186
8
Hierarchical Flow
In a hierarchical design flow, your design can instantiate IPs. These IP blocks can be
designed or implemented with a complex power structure, with the power intent described in
a separate CPF file.
CPF distinguishes the following categories of IP:
A hard non-custom IP is a block that has been synthesized and placed and routed,
but small modifications can still be made. It is also referred to as a hard IP.
To model a hard IP use the set_design command.
A hard custom IP is a block that is mostly implemented by hand. Custom IP users

cannot make any changes to the block. Examples are third-party memories. A hard
custom IP is also referred to as a custom IP or a macro cell.
To model a macro cell, use the set_macro_model command.
A soft IP is a design module that can be supplied by a third-party. Users have the full
capability to (re-)synthesize and place and route the design. Examples are synthesizable
CPU cores, and so on.
To model a soft IP use the set_design command.
This chapter describes how to model a hard non-custom IP or a soft IP. See Chapter 9,
Modeling a Macro Cell for information on modeling a macro cell.
Power Domain Mapping

In the hierarchical flow, you can have a CPF file for a module at the upper level (parent level)
of the hierarchy and a CPF file for a module at a lower level (block level or child level) in the
hierarchy.
When an IP block is instantiated at the upper level, the power and ground pins of the block
must be connected to the power and ground nets of the upper-level design. This is
accomplished by merging power domains of the block with power domains at the upper level
June 2013
187

Hierarchical Flow
when the block is instantiated in the upper-level design. The operation of merging a power
domain of a block with another power domain at the upper level is called power domain
mapping.
Power domain mapping involves:
1. Connecting the primary power and ground pins or nets of the block-level domain to the
primary power and ground net of the domain specified at the upper level
2. Merging the elements of the power domain of the block into the upper-level domain. See
Merging the Block-Level Elements on page 189.
3. Merging the power modes
Note: In the current release, power modes for mapped block-level domains are ignored
with a warning.
4. Resolving the precedence of the power domain attributes. See Handling Domain
Attributes after Domain Mapping on page 189.
5. Resolving the precedence of the upper-level and block-level rules. See Resolving the
Precedence of Rules on page 192.
Once a block-level power domain is mapped into a parent-level power domain, the two power
domains are considered identical and all instances of the two domains share the same power
characteristics. For example, the standard cell instances of the two power domains will have
their primary power and ground pin (follow pins) connected together to the same primary
power and ground nets.
To indicate how the domains of the IP block must be mapped to the domains of the parent
level, use the -domain_mapping option of the set_instance command. The syntax is as
follows:
set_instance instance_name \
-domain_mapping {domain_in_child_scope domain_in_parent_level_scope}
If you are mapping multiple domains, enclose each pair in curly braces, as follows:
-domain_mapping { {domain_in_child_scope domain_in_parent_level_scope} \
{domain_in_child_scope domain_in_parent_level_scope} }
For example:
set_instance inst_B -domain_mapping {PDLower PDUpper}
set_instance inst_B -domain_mapping ( {PDLower1 PDUpper1} \
{PDLower2 PDUpper2} }
June 2013
188

Hierarchical Flow
Instantiating the IP in the Top-Level CPF and Loading the

Corresponding CPF
When you instantiate a block in the design, you must indicate which CPF specification applies
to the specified instance. This is done by using the set_instance command followed by the
CPF model definition. For example:
...
create_power_domain -name PDUpper ...
...
set_instance ipInst -domain_mapping {PDLower PDUpper}
set_design IPBlock
create_power_domain -name PDLower ...
...
end_design
The CPF model definition can be in a separate file, and you can load it with an include
command. For example:
set_instance ipInst -domain_mapping {PDLower PDUpper}
include IPBlock.cpf
Note: In the current release, using the set_instance command with the -design option
is not supported.
Merging the Block-Level Elements

When a block-level domain is merged into an upper-level domain, all instance members of
the block-level domain become members of the upper-level domain. If the block-level domain
is a default domain, this includes all implicit instance members (instances not explicitly
associated with a specific power domain of the block).
Handling Domain Attributes after Domain Mapping

Options specified with either the create_power_domain or update_power_domain
command are referred to as domain attributes. This section describes how the domain
attributes that the Incisive simulator supports are handled after power domain mapping.
Once a block-level domain is mapped into an upper-level domain, the following precedence
rules determine how the block-level domain attributes are evaluated with respect to the
settings of the upper-level domain:
June 2013
189

Hierarchical Flow
Shutoff control signals

If both the upper-level domain and the block-level domain define shutoff control
conditions, the conditions must be identical or, for a simple condition, structurally
equivalent. If they are not, a warning is issued and merging continues.
Default save/restore conditions and default isolation condition

-default_save_edge/-default_restore_edge
-default_save_level/-default_restore_level
-default_isolation_condition
Block-level default conditions always overwrite the parent-level default conditions. The
parent-level default condition is used if the block-level default condition is missing.
Default save/restore Conditions for State Retention
If a create_state_retention_rule command of the block-level domain does not
define a save/restore condition:
The default save/restore conditions specified in the create_power_domain

command of the block-level domain is used.
If the block-level domain does not have a default save/restore, the default
save/restore of the parent domain is used.
If there is no default condition for this parent, and this parent is mapped one level
higher, the default save/restore of this next highest parent is used. This process
continues until a default condition is found.
If no default condition is found, a warning is issued.
Note: If the CPF version is 1.0e or higher, and a save condition is specified in the
create_state_retention_rule command, the restore condition is the shutoff
condition of the highest parent.
Default Isolation Condition
If a create_isolation_rule command of the block-level domain does not define an
isolation condition:
The default isolation condition specified in the create_power_domain command

of the block-level domain is used.
If the block-level domain does not have a default isolation condition, the default
condition of the parent domain is used.
June 2013
190

Hierarchical Flow
If there is no default condition for this parent, and this parent is mapped one level
higher, the default isolation condition of this next highest parent is used. This
process continues until a default condition is found.
If no default condition is found, a warning is issued.
Boundary ports
Boundary ports (create_power_domain -boundary_ports) are only allowed on
top-level designs, on mapped domains, and on macro models. Boundary ports specified
for the block-level domain are ignored with a warning.
Base domains
For every base domain specified for a block-level power domain
(create_power_domain -base_domains), one of the following must be true or an
error is generated:
The block-level base domain is eventually mapped to the upper-level domain. For
example:
create_power_domain -name PDUpper ... -base_domains {base_upper}
...
set_instance F1 -domain_mapping { {PDLower PDUpper} {base_lower PDUpper} }
set_design IPBlock
create_power_domain -name base_lower ...
create_power_domain -name PDLower ... -base_domains {base_lower}
The base domain of the block-level domain is mapped to a base domain of the
upper-level domain. For example:
create_power_domain -name PDUpper ... -base_domains {base_upper}
...
set_instance F1 -domain_mapping { {PDLower PDUpper} \
{base_lower base_upper} }
set_design IPBlock
create_power_domain -name base_lower ...
create_power_domain -name PDLower ... -base_domains {base_lower}
The upper-level domain does not have a base domain defined. In this case, the base
domain of the block-level domain is ignored with a warning.
Active state conditions

After domain mapping, only the active state conditions of the parent-level domain are
used. A warning is issued if all of the parent-level active states are not specified as active
states in the block-level domain.
June 2013
191

Hierarchical Flow
Transition slope
If a transition slope (update_power_domain -transition_slope) is specified for
both the block-level domain and the parent-level domain, the minimum transition slope is
used.
Transition latency
When merging a child domain to a parent domain:
If the child domain has a larger latency value than the parent, use the larger value
(with a warning).
If the parent domain has a larger latency value than the child, use the larger value
(without a warning).
If a latency is defined for the child domain, but no latency is defined for the parent
domain, use the latency from the child domain (without a warning).
Resolving the Precedence of Rules

The CPF specification states that when a block-level CPF is integrated into an upper-level
CPF using the set_instance command:
Block-level rules always overwrite the parent-level rules if both rules apply to the same
objects at the block-level after domain mapping.
Parent-level rules are only applied to block-level objects if the block-level objects have no
rule specified.
Block-level rules are never propagated to the top level.
State Retention Rules

The precedence of top-level and block-level state retention rules is resolved as follows:
1. Apply the block-level state retention rules to the selected block-level instances.
2. Merge block-level domains into parent-level domains. All instance members of the
block-level domain become members of the upper-level domain.
3. Apply the parent-level state retention rules to the selected parent-level objects and to the
selected block-level objects that have not already had state retention applied by
block-level rules.
June 2013
192

Hierarchical Flow
If the -secondary_domain option is used to specify a secondary domain at the block level,
the specified secondary domain is the secondary domain after the domains have been
merged. If a secondary domain is not specified, the secondary domain will be a base domain
of the parent domain if one exists (the parent domain and the block-level domain will have the
same base domain). If more then one base domain is specified, an error is issued.
Because state retention rules are scope-specific, it is possible to have rules with the same
name at different scopes. To avoid name collisions at the top level, unique names are
generated for the rules. The names are of the following form:
rule_name_MAP_numeral
The numeral in the name is an incremental number to ensure uniqueness. For example, after
domain mapping, the following two state retention rules:
top/dut/instA/sram/sr_rule
top/dut/instB/sram/sr_rule
are renamed as:

sr_rule_MAP_0
sr_rule_MAP_1
Examples
In the following examples, a power domain PDLower is defined at the block level. Domain
PDLower has two instances, instL1 and instL2.
At the upper level, a power domain named PDUpper is defined. This has two instances,
instU1 and instU2.
Domain PDLower is mapped to domain PDUpper. After power domain mapping, the instance
members of PDLower become members of domain PDUpper.
Example 1
In this example, a block-level state retention rule uses the -domain option to specify that
state retention should be applied to all registers in all instances of domain PDLower. This rule
applies state retention to registers in instL1 and instL2.
After domain PDLower has been mapped into domain PDUpper, the two instances in
PDLower (instL1 and instL2) now belong to domain PDUpper.
The state retention rule at the parent level uses the -domain option, which specifies that
state retention is to be applied to all registers in all instances of domain PDUpper. State
retention is applied to registers in instU1 and instU2. Because parent-level rules are only
June 2013
193

Hierarchical Flow
applied to block-level objects if the block-level objects have no rule specified, this rule does
not apply to instL1 and instL2.
create_power_domain -name PDUpper \
-instances {instU1 instU2} ...
...
create_state_retention_rule -name srU \
-domain PDUpper ...
...
set_instance I1 -domain_mapping {PDLower PDUpper}
set_design IPBlock
create_power_domain -name PDLower \
-instances {instL1 instL2} ...
...
create_state_retention_rule -name srL \
-domain PDLower ...
...
end_design
Example 2
In this example, the block-level does not have a state retention rule specified.
The state retention rule at the upper level uses the -domain option. This rule will apply state
retention to all registers in all instances of domain PDUpper. State retention is applied to all
registers in instances instU1, instU2, instL1, and instL2.
...
-domain PDUpper ...
...
set_design IPBlock
...
end_design
June 2013
194

Hierarchical Flow
Example 3
In this example, the block-level rule uses -domains. This rule applies state retention to
registers in instL1 and instL2.
The parent-level domain does not have a state retention rule specified, so state retention is
not applied to registers in instU1 and instU2.
...
...
set_design IPBlock
...
-domain PDLower ...
...
end_design
Example 4
In this example, the block-level state retention rule uses the -instances option to specify
that state retention should be applied to all registers in instance instL1.
The state retention rule at the top level uses the -domain option, which specifies that state
retention is to be applied to all registers in all instances of domain PDUpper. This rule will
apply state retention to registers in instU1 and instU2 and to registers in instance instL2
because that instance was not selected by the block-level rule.
...
-domain PDUpper ...
...
June 2013
195

Hierarchical Flow
set_design IPBlock
...
-instances {instL1} ...
...
end_design
Example 5
In a create_state_retention_rule command, the -exclude option can be used to
explicitly exclude instances. If a rule at the block level explicitly excludes an instance(s) with
the -exclude option, the excluded instance(s) are not included in a parent-level state
retention rule that uses the -domain option.
In the following example, the block-level rule explicitly excludes instance instL3. This rule
applies state retention to registers in instances instL1 and instL2. After domain mapping,
the upper-level rule applies state retention to registers in instances instU1 and instU2.
Retention is not applied to the excluded instance instL3.
...
-domain PDUpper ...
...
set_design IPBlock
-instances {instL1 instL2 instL3} ...
...
-domain PDLower \
-exclude {instL3} ...
...
end_design
June 2013
196

Hierarchical Flow
Example 6
In the following example, the block-level rule applies state retention to instance instL2.
After domain PDLower has been mapped into domain PDUpper, the three instances in
PDLower (instL1, instL2, and instL3) now belong to domain PDUpper.
The top-level rule applies retention to the instances in domain PDUpper (instU1 and
instU2). It also applies retention to the block-level objects that have no rule specified
(instance instL3). The instance I1.instL1 is explicitly excluded.
...
-domain PDUpper \
-exclude {I1.instL1} ...
...
set_design IPBlock
-instances {instL1 instL2 instL3} ...
...
-instance {instL2} ...
...
end_design
Isolation Rules
The precedence of top-level and block-level isolation rules is resolved as follows:
1. Determine the pin list(s) for the isolation rules of the lowest-level block.
2. Merge the power domains of this block into its parent-level domains.
3. Determine the pin list(s) for the isolation rules of the parent.
4. Merge the power domains of this parent block into the next upper level domains.
5. Continue this process until all merging is complete.
6. When all merging is complete, beginning with the lowest level block, perform driver/load
analysis. Place valid isolation devices using the rules for isolation priority.
June 2013
197

Hierarchical Flow
When determining the pin lists for the isolation rules of the block-level designs, if the rules do
not use the -pins option:
-from option only

Selects only all output pins of the domain.
-to option only

Select only all inputs pins of the domain.
Both -from and -to options

Normal isolation handling before domain mapping applies to determine the pins list.
Because isolation rules are scope-specific, it is possible to have rules with the same name at
different scopes. To avoid name collisions at the top level, unique names are generated for
the rules. The names are of the following form:
domain mapping, the following two isolation rules:
top/dut/instA/sram/iso_rule
top/dut/instB/sram/iso_rule
are renamed as:

iso_rule_MAP_0
iso_rule_MAP_1
June 2013
198

Hierarchical Flow
Examples
The following design is used for the examples in this section:
PDP
PDC
D1
P1
P2
DL1
DL2
C1
C2
D2
P3
C3
L1
L2
L3
In this example, the block-level CPF model defines a power domain called PDC. At the upper
level, two power domains are defined: a default domain called defaultPD, and a domain
called PDP. The block-level power domain PDC is mapped to domain PDP.
Example 1
In this example, isolation rules are specified only at the block level.
create_power_domain -name defaultPD -default ...
create_power_domain -name PDP ...
...
set_instance i1 -domain_mapping {PDC PDP}
set_design inst1
create_power_domain -name PDC ...
create_isolation_rule -name isoC -to PDC ...
...
end_design
1. Determine the pin list for isolation rule isoC.

Pins c1, c2, and c3 are selected.
2. Merge domain PDC to PDP.
June 2013
199

Hierarchical Flow
3. Perform driver/load analysis for isolation rule isoC.
Isolation at port c1 is invalid because, after domain merging, the driver DL1 and the load
L1 are in the same power domain (PDP).
Isolation at port c2 is invalid because, after domain merging, the driver DL2 and the load
L2 are in the same power domain (PDP).
Isolation at port c3 is valid because its driver D2 is in domain defaultPD and its load
L3 is in domain PDP.
PDP
PDC
D1
P1
P2
D2
P3
DL1
DL2
C1
C2
C3
L1
L2
L3
Example 2
In this example, isolation rules are specified only at the parent level.
create_isolation_rule -name isoP -to PDP ...
...
set_design inst1
...
end_design
June 2013
200

Hierarchical Flow
1. No isolation rule at lower scope.
3. Determine the pin list for isolation rule isoP.
Pins p1, p2, and p3 are selected.
4. Perform driver/load analysis for isolation rule isoP.
Isolation at port p1 is valid because, after domain merging, its driver D1 is in domain
defaultPD and its load DL1 is in domain PDP.
Isolation at port p2 is invalid because it has no valid driver.
Isolation at port p3 is valid because its driver D2 is in domain defaultPD and its load
L3 is in domain PDP.
PDP
PDC
D1
P1
P2
D2
P3
DL1
DL2
C1
C2
C3
L1
L2
L3
Example 3
In this example, isolation rules are specified at both the block level and top level.
create_isolation_rule -name isoP -to PDP ...
...
June 2013
201

Hierarchical Flow
set_design inst1
create_isolation_rule -name isoC -to PDC ...
...
end_design
1. Determine the pin list for isolation rule isoC.

Pins c1, c2, and c3 are selected.
3. Determine the pin list for isolation rule isoP.
Pins p1, p2, and p3 are selected.
4. Perform driver/load analysis for isolation rules.
a. Isolation rule isoC
Isolation at port c1 is invalid because, after domain merging, the driver DL1 and the
load L1 are in the same power domain PDP.
Isolation at port c2 is invalid because, after domain merging, the driver DL2 and the
load L2 are in the same power domain PDP.
Isolation at port c3 is valid because its driver D2 is in domain defaultPD, and its
load L3 is in domain PDP.
b. Isolation rule isoP
Isolation at port p1 is valid because its driver D1 is in domain defaultPD, and the
load DL1 is in power domain PDP.
Isolation at port p2 is invalid because it has no valid driver.
Isolation at port p3 is valid because its driver D2 is in domain defaultPD, and its
load L3 is in domain PDP.
June 2013
202

Hierarchical Flow
PDP
PDC
D1
P1
P2
D2
DL1
DL2
P3
C1
C2
C3
L1
L2
L3
create_assertion_control Rules
By default, assertions related to a power domain remain active when the power domain is
powered down. The create_assertion_control command turns off the evaluation of
selected assertion instances related to a power domain when that power domain is shut
down.
Rules defined for the block-level domain apply only to the block-level domain. Rules defined
for the top-level domain apply to both the upper and lower domains. Overlapping rules are
allowed. If more than one rule applies at the same time, a reset overrides a suspend.
create_assertion_control commands are scope-specific. It is possible to have
commands with the same name in different scopes. To avoid name collisions at the top level,
unique names are generated for the rules. The names are of the following form:
domain mapping, the following two rules:
top/dut/instA/sram/cac_rule
top/dut/instB/sram/cac_rule
are renamed as:

cac_rule_MAP_0
cac_rule_MAP_1
June 2013
203

Hierarchical Flow
June 2013
204
9
Modeling a Macro Cell
This chapter tells you how to:
Write a CPF model for a block of hard IP (a macro cell)
Integrate the macro model into a design
Writing a CPF Model for a Macro Cell

Accurate simulation, implementation, and verification of hard IP blocks, such as embedded
RAM, ROM, PLL, or other vendor IP, can be accomplished by defining the power features of
the IP using set_macro_model / end_macro_model. These commands delimit the scope
of a macro model description. All commands between set_macro_model and
end_macro_model describe the internal implementation of the macro cell.
set_macro_model macro_name
power information content
end_macro_model [macro_name]
The macro_name argument to set_macro_model identifies the library cell that represents
the macro cell.
Macro cells are treated as black boxes by synthesis and other implementation tools. Some
commands in the macro model definition are required by these tools to describe how to
connect the macro to the rest of the circuit.
For simulation, commands in the macro model definition define the power intent of the
behavioral model of the hard IP block. The independent macro model definition allows the
behavioral model of the IP block, which may not be fully power-aware, to coexist with the CPF
definition. It is not necessary to change the IP model to incorporate low-power features.
When simulating, macro models can be treated as black boxes or gray boxes.
Black box macro models

If full low-power functionality is specified within the behavioral model of the macro model,
it can be treated as a black box in simulation.
June 2013
205

For a macro model that is treated as a black box:
All corruption, isolation, and state retention outside the macro model is limited to the
boundary ports defined by the macro model. All input boundary ports of the macro
model will assume there is a load inside the macro model in the domain associated
with the input boundary port. All output boundary ports of the macro model will
assume a driver inside the macro model in the domain associated with the output
boundary port.
All corruption, isolation, and state retention defined inside the macro model (that is,
inside set_macro_model and end_macro_model) is ignored. All isolation and
state retention rules are ignored. Boundary ports are not corrupted. Registers that
are part of a switchable power domain are not corrupted. A black box macro model
will not apply any corruption to an internal domain even if it is mapped to an external
switchable domain.
Gray box macro models

If only a subset of low-power behavior is specified within the behavioral model of the
macro model, it should be simulated as a gray box model.
For a macro model that is treated as a gray box:
All corruption, isolation, and state retention outside the macro model is treated the
same as for the black box model.
All macro model corruption and state retention defined inside the macro model (that
is, inside set_macro_model and end_macro_model) is processed within the
macro model only. Corruption is limited to boundary ports and registers explicitly
defined inside the macro model as switchable power domains. State retention rules
specified in the macro model are applied.
Isolation rules defined in a gray box macro model are not currently supported and
will be ignored.
By default, the simulator treats all macro models as having a partially power-aware model,
and treats them as gray boxes.
You must use the -lps_blackboxmm option (ncelab -lps_blackboxmm or irun
-lps_blackboxmm) to treat macro models as black box models.
Gray box macro model power domains are mapped to upper-level power domains as
specified with the set_instances -domain_mapping option. In the SimVision Power
Browser, gray box macro model power domains are displayed as mapped domains for a
power domain under Mapped Domains. Black box macro model power domains are not
mapped to upper-level power domains, and do not appear as mapped domains.
June 2013
206

Macro Model CPF Commands

The following CPF commands can be used within the set_macro_model /
end_macro_model commands. Some commands are used by implementation tools only
and have no effect on simulation. Other commands are related to power modes.
create_power_domain
create_isolation_rule
create_state_retention_rule
For power modes.
create_power_mode
For power modes.
For power modes.
update_power_domain
For implementation tools and for specifying

transition slope for power mode transitions.
create_power_switch_rule
For implementation tools only
set_floating_ports
set_input_voltage_tolerance For implementation tools only

set_wire_feedthrough_ports
The following sections discuss only the commands that affect simulation.
Figure 9-1 on page 208 shows the design used in the examples.
June 2013
207

Figure 9-1 Macro Model Example
VDD
D1
Pd_AON
iso1
Always
On
Switches
ret
Pd_PSO
Internally
Switched
pwr
State
Retention
D2
Isolation
iso2
D4
Isolation
Pd_EXT
Isolation
D3
VSS
Externally
Switched
D5
VPP
Defining the Macro Model Power Domains

Within a set_macro_model / end_macro_model, you can define all types of power
domains:
Internally switchable
The macro power domain is switched internally in the macro, based on an expression of
macro input ports. The create_power_domain command includes a shutoff condition
derived from the input ports of the macro.
June 2013
208

Externally switchable
The macro power domain is connected to an externally-switched power source. Because
the shutoff condition does not exist in the context of the macro, the internal domain must
be mapped to an external power domain defined in the CPF file for the higher-level
circuit.
Always on
The macro power domain is not switchable. No shutoff condition is specified for the
domain.
All power domains in the macro model are virtual power domains. That is, the domain
definition cannot include a specification of instances using the -instances option.
According to the CPF specification, only registers (Verilog regs or VHDL signals) or boundary
ports can be used to define a power domain inside a macro model.
Specifying Verilog regs or VHDL Signals as a Power Domain
According to the CPF specification, instances referred to in a create_power_domain
command between a set_macro_model and end_macro_model pair can be registers in
the behavioral model of the macro cell.
In a CPF macro model, you can specify Verilog regs or VHDL signals as power domain
instances with the -instances option. The syntax is as follows:
create_power_domain -instances { [hierarchical_instance_list]
[register_instance_list] }
The argument to the -instances option can be:
A list of hierarchical instances. This is a list of paths to module/entity instances in the HDL
within the current CPF scope. Specifying a hierarchical instance will associate all
registers in that instance and all of its children with the power domain.
The following command associates all registers in instances A and B and all of their
children with domain PDA.
create_power_domain -name PDA -instances {A B} ...
The following command associates all registers in instances A and B/B2 and all of their
children with domain PDA.
create_power_domain -name PDA -instances {A B/B2} ...
A register can only belong to one power domain. If two commands select the same
register, the more explicit rule has precedence. For example, given the following two
commands, the registers in A/A1 will belong only to domain DMN2.
June 2013
209

create_power_domain -name DMN1 -instances {A} ...
create_power_domain -name DMN2 -instances {A/A1} ...
An error is generated if a specific hierarchical instance belongs to multiple power

domains.
A list of register instances. This is a list of Verilog registers or VHDL signals that
describes a sequential element. For example:
create_power_domain -name PDA -instances {A/A1/reg1 A/A1/reg2 \
A/A2/reg1 A/A2/reg2 \
B/B2/reg1 B/B2/reg2} \
...
You can use the * and ? wildcard characters to specify register instances. For example:
set_macro_model IPBlock
create_power_domain -name domain_mem \
-shutoff_condition {pso_en} \
-instances {A/A1/reg* \
A/A2/reg* \
B/B2/reg*}
...
end_macro_model
An error is generated if a specific register instance belongs to multiple power domains.

Note: Specifying a Verilog UDP reg as an instance in a power domain is an error.
Both of the above. You can specify both a list of instances and a list of registers.
create_power_domain -name PDA -instances {A \
B/B2/reg1 \
...
You can define a default power domain in a macro model. However, register instances that
are not explicitly assigned to a power domain are not associated with the default domain. Only
registers explicitly listed in a domain are included in that domain. This means that any
registers that are in the top level of a macro model will not be associated with any domain
unless they are explicitly specified in a create_power_domain rule.
You can specify the full register name or a bit-select or part-select as a power domain
instance. Portions of an array can be assigned to different power domains. However, the
same portion cannot be assigned to more than one domain.
For example, consider the following Verilog two-dimensional array:
June 2013
210

reg [7:0] mem[0:15][0:1];
The following -instances option selects bit 7 of memory location [14][1].

-instances { mem[14][1][7] }
The following -instances option selects bits[3:0] of memory location [14][1].

-instances { mem[14][1][3:0] }
The following -instances option selects the memory locations [14][0] and [14][1].
-instances { mem[14][0] mem[14][1] }
If the registers must be always-on, do not specify a shutoff condition. If the registers lose state
when the power is shut off, specify a shutoff condition.
Power shutoff results in corruption of registers specified as instances in a power domain.
Registers that must be saved/restored must have state retention specified with
create_state_retention_rule commands. See Defining State Retention on
page 215 for more information.
Specifying the Boundary Ports
For macro cells, the related power domain of boundary pins is critical in describing the power
structure of the cell. Use the -boundary_ports option to assign the primary input or output
pins to a specific power domain.
For a macro model, the domain association of a boundary port is as follows:
if the port is a primary output of a macro cell, the boundary port domain is the domain of
the driver(s) of the port inside the macro cell.
If the port is a primary input of a macro cell, the boundary port domain is the domain of
the loads of the port inside the macro cell.
If an input pin is assigned to a switchable domain, when the shutoff condition of the domain
becomes true, all logic within the macro model that is driven by this input pin will receive logic
value X, irrespective of the logic value that drives the input pin.
If an output pin is assigned to a switchable domain, all of the logic that connects to the pin at
the top level or testbench level will receive logic value X when the shutoff condition of the
domain becomes true.
See Declaring Boundary Ports with the -boundary_ports Option on page 71 for more
information on the -boundary_ports option.
For the example shown in Figure 9-1 on page 208, three power domains are defined:
June 2013
211

Power domain Pd_AON is the default always-on domain.

Choose an always-on domain as the default domain of the macro model so that all
unspecified ports and internal logic will be powered on. If an always-on domain does not
exist, choose an externally-switchable domain as the default domain.
Power domain Pd_PSO is an internally switchable domain. An active low input pwr turns
power off. The switch source is the always-on Pd_AON domain.The input port D2 is
associated with domain Pd_PSO using the -boundary_ports option.
Domain Pd_PSO contains registers, which are defined with the -instances option. The
value of these registers must be saved before power down, and the saved values must
be restored after power up. A subsequent create_state_retention_rule
command is used to define the save/restore operation. See Defining State Retention
on page 215.
Power domain Pd_EXT is an externally switchable domain. The input port D3 and the
output port D5 is associated with domain Pd_EXT using the -boundary_ports option.
The three power domains for the example macro model are defined in the CPF file as follows:
# macro.cpf
# CPF file for macro model
create_power_domain -name Pd_AON -default
create_power_domain -name Pd_PSO \
-shutoff_condition !pwr \
-boundary_ports {D2} \
-instances {mem*} \
-base_domains Pd_AON
create_power_domain -name Pd_EXT \
-boundary_ports {D3 D5}
...
end_macro_model
Currently, IES does not support boundary ports of type inout. Only input or output ports
are supported. A warning is issued that an inout port has been detected in the
-boundary_port option and that corruption and isolation will not be applied to this port.
One work-around is to make the tristate driver an AON port, and any devices driving that port
will be allowed to do so. IES will not corrupt the port.
June 2013
212

Modeling a Register Inside a Macro Model

Since macro models appear to the implementation tools as black boxes, use the
-boundary_ports option of the create_power_domain command to specify the macro
model ports. This directs the simulator to corrupt the output value while the domain is
powered off. To apply state retention to the register, the register must be assigned to a power
domain. This allows you to write a state retention rule for the register as described in Defining
State Retention on page 215.
For the following RTL code
module dff4(clk, rst, in1, out1);
input clk, rst;
input [3:0] in1;
output reg [3:0] out1;
always @(posedge clk, posedge rst)
if(rst)
out1 <= 4h0;
else
out1 <= in1;
endmodule
Write a create_power_domain rule using both the -boundary_ports and -instances

options.
create_power_domain -name PDout1 \
-boundary_ports out1 -instances out1
Defining Isolation
Figure 9-2 on page 214 shows the example design with the isolation rules.
June 2013
213

Figure 9-2 Isolation Rules
VDD
D1
Pd_AON
iso1
iso2
Always
On
Switches
ret
Pd_PSO
Internally
Switched
pwr
State
Retention
D2
# Port D3 belongs to
# domain Pd_EXT
create_isolation_rule \
-name IsoIn \
-to Pd_EXT -pins {D3} \
-isolation_condition iso1 \
D4
Isolation
Pd_EXT
D3
Isolation
# domain Pd_PSO
# D2 has no internal
# isolation
-name IsoInReq \
-to Pd_PSO -pins {D2} \
Isolation
#default domain Pd_AON
-name IsoOut \
-from Pd_PSO -pins {D4} \
-isolation_condition !pwr \
VSS
Externally
Switched
D5
VPP
# Isolation rule for internal
# domain crossing
-name IsoInt \
-from Pd_EXT -to Pd_PSO \
The rules shown in the figure illustrate three scenarios:
The macro input port D3 and the output port D4 are isolated inside the macro model (that
is, the isolation logic is implemented inside the macro cell). In this case, specify a
complete isolation rule to describe the isolation logic. A complete isolation rule contains:
June 2013
214

The isolation condition (-isolation_condition). The condition must be

expressed as a macro input port.
The isolation output value (-isolation_output)
Because isolation for these ports is implemented within the macro cell, the isolation rules
are not used by simulation. However, the rules are used by CLP and implementation
tools. They are also useful for documentation purposes, and they may be used in a future
release to generate automatic assertions to catch illegal power sequences.
The macro input port D2 is not isolated inside the macro model, but the port requires
isolation when the drivers are switched off in the design context. In this case, you cannot
specify the isolation condition because the isolation enable signal is not known. However,
the isolation rule defines what the clamp value should be when the driving domain is
powered down (-isolation_output). The isolation condition will be specified in a rule
for the parent block when the macro model domains are mapped to parent block power
domains.
Isolation of macro internal domain crossings (for example, from domain Pd_EXT to
domain Pd_PSO) must be defined in the behavioral model of the IP. Isolation rules for
internal domain crossings are not supported. However, these isolation rules could be
used in a future release to generate automatic assertions to catch illegal power
sequences.
Defining State Retention

If the macro cell has switchable power domains, the CPF macro model can contain state
retention rules to specify that the register values are to be saved and restored.
In the example, power domain Pd_PSO contains registers, which have been defined as
instances in the domain.
create_power_domain -name Pd_PSO -instances {...}
When the domain is powered down, the registers lose state. The following state retention rule
uses the -domain option to specify that the value of all registers in the domain are to be
saved before power shutoff. The saved values will be restored when power is restored.
June 2013
215

# macro.cpf
...
create_state_retention_rule -name PSO_RET \
-domain Pd_PSO \
-secondary_domain Pd_AON \
-save_edge {ret}
...
end_macro_model
By default, the secondary power domain of the specified state retention logic is the base
domain defined for the parent domain containing the retention logic. In the example, the
secondary domain of the state retention logic is domain Pd_AON, which was defined as the
base domain of domain Pd_PSO.
The -domain option selects all registers in the domain for state retention. Use the
-instances option if you want to select only specific instances for state retention. The
syntax is as follows:
create_state_retention_rule -instances { [hierarchical_instance_list]
[register_instance_list] }
The argument to the -instances option can be:
A list of hierarchical instances. This is a list of paths to module/entity instances in the HDL
within the current CPF scope. Specifying a hierarchical instance will select all registers
in that instance and all of its children.
The following command applies state retention to all registers in instances A and B and
all of their children.
create_state_retention_rule -name SR1 -instances {A B} ...
The following command applies state retention to all registers in instances A and B/B2
and all of their children.
create_state_retention_rule -name SR1 -instances {A B/B2} ...
A list of register instances. This is an explicit list of the registers that must have state
retention. For example:
create_state_retention_rule -name SR1 -instances {A/A1/reg1 A/A1/reg2 \
A/A2/reg1 A/A2/reg2 \
B/B2/reg1 B/B2/reg2} \
...
You can use the * and ? wildcard characters to specify register instances (for example.
A/A1/reg*).
June 2013
216

Both of the above. You can specify both a list of instances and a list of registers.
create_state_retention_rule -name SR1 -instances {A \
B/B2/reg1}
A warning is generated if a register is identified as part of two different state retention rules.
A rule with -instances has precedence over a rule with -domains. If both rules use the
same option, the last rule in the file is used.
State retention is supported for the whole register, and for bit-selects and part-selects of the
register. In the following example, two create_state_retention_rule commands are
applied to different parts of the array. Part-selects are used for some locations to be retained.
reg [7:0] mem[0:15][0:7];
...
set_macro_model top
...
# Create a power domain for mem
create_power_domain -name domain_mem \
-shutoff_condition {pso_en} \
-instances {mem}
# Create a retention rule to save and restore selected elements
create_state_retention_rule -name rtn_mem1 \
-restore_edge {!pm_inst.pge_enable} \
-instances {mem[9][0] mem[9][1] \
mem[9][2] mem[9][3] \
mem[9][4] mem[9][5]}
# Create a retention rule to save and restore specified bits of other elements
create_state_retention_rule -name rtn_mem2 \
-restore_edge {!pm_inst.pge_enable} \
-instances {mem[5][6][7:4] mem[5][7][7:3] \
mem[6][0][6:1] mem[6][1][5:0] \
mem[6][2][7:5]}
end_macro_model
Example
June 2013
217

The create_power_domain commands use the -instances option to specify

hierarchical instances. All registers in the specified instances and their children are
associated with the power domain.
The create_state_retention_rule commands also use the -instances option

to specify hierarchical instances. All registers in the specified instances and their children
are selected for state retention.
MacroM1
B
A1
A2
R1
R2
R1
R2
AR
B1
B2
R1
R2
R1
R2
BR
MR
set_macro_model MacroM1
create_power_domain name PDD default
# Domain PDA will contain all registers in instance A and its children
# {A/AR A/A1/R1 A/A1/R2 A/A2/R1 A/A2/R2). It will also include register MR.
create_power_domain name PDA instances {A MR} \
shutoff_expression {pso}
# Apply state retention to all registers in instance A and its children
# {A/AR A/A1/R1 A/A1/R2 A/A2/R1 A/A2/R2}.
create_state_retention_rule name SR1 instances {A} \
save_edge sr1
June 2013
218

# Domain PDB will contain all registers in instance B and instance B1
# {B/BR B/B1/R1 B/B1/R2}.
# Registers in instance B2 are not included because B/B2 is defined as part of PDB2.
create_power_domain name PDB instances {B} \
shutoff_expression {pso2}
# Apply state retention to all registers in instance B/B1 (B/B1/R1 B/B1/R2)
# and to register B/BR.
create_state_retention_rule name SR2 instances {B/B1 B/BR}
# Domain PDB2 will contain all registers in instance B/B2 {B/B2/R1 B/B2/R2}.
create_power_domain name PDB2 instances {B/B2} \
shutoff_expression {pso3}
end_macro_model
Explicit Code to Handle X Values

The behavioral model must include explicit behavioral code to handle X values for input
boundaries and internal domain crossings. The following shows example code that will not
propagate an X to its output:
always @(a)
if(a)
b = 1;
else if (!a)
b = 0;
In this code, if a = 1 or a = 0, then b = a. However, if a = X, then b is not set to X. If this

code fragment is synthesized, the resultant logic will behave as intended, but the original RTL
code will not pass the X through to the output.
CPF File for the Macro Cell

The following file, macro.cpf, shows the CPF file with all simulation-related commands for
the example macro cell:
# macro.cpf
######################
# Create power domains
June 2013
219

######################
create_power_domain -name Pd_AON -default
create_power_domain -name Pd_PSO \
-shutoff_condition !pwr \
-boundary_ports {D2} \
-instances {mem*} \
-base_domains Pd_AON
create_power_domain -name Pd_EXT \
-boundary_ports {D3 D5}
########################
# Define isolation rules
########################
# Port D4 belongs to default domain Pd_AON
create_isolation_rule -name IsoOut \
-from Pd_PSO -pins {D4} \
-isolation_condition !pwr \
# Port D2 belongs to domain Pd_PSO. D2 has no internal isolation
create_isolation_rule -name IsoInReq \
-to Pd_PSO -pins {D2} \
# Port D3 belongs to domain Pd_EXT
create_isolation_rule -name IsoIn \
-to Pd_EXT -pins {D3} \
# Isolation rule for internal domain crossing
create_isolation_rule -name IsoInt \
-from Pd_EXT -to Pd_PSO \
June 2013
220

##############################
# Define state retention rules
##############################
create_state_retention_rule -name PSO_RET \
-domain Pd_PSO \
-secondary_domain Pd_AON \
-save_edge {ret}
end_macro_model
Integrating the Macro Model

When you instantiate a macro cell in the design, you must specify how the domains of the
CPF macro model are mapped to the domains of the parent level. Macro model power
domains are integrated with parent block power domains using the set_instance
-domain_mapping option.
For the example design, the top-level design has two power domains: a default always-on
domain called PDBlue, and an internally switchable domain called PDRed, as shown in
Figure 9-3 on page 222.
June 2013
221

Figure 9-3 Top-Level Power Domains
VDD
VDD
D1
PDBlue
Pd_AON
iso1
iso2
Always
On
Switches
ret
Pd_PSO
Internally
Switched
pwr
State
Retention
D2
Isolation
Always
On
D4
Switches
Isolation
PDRed
Pd_EXT
D3
Isolation
Internally
Switched
State
Retention
VSS
Externally
Switched
D5
VPP
The two top-level domains are defined in the top-level CPF as follows:
# top.cpf
# Top-level CPF file
set_cpf_version 2.0
June 2013
222

set_design top
create_power_domain -name PDBlue -default
create_power_domain -name PDRed \
-shutoff_condition {pso} \
-default_isolation_condition {I1/iso1} \
-base_domains PDBlue
Use the set_instance -domain_mapping option to map the macro model power
domains to the top-level domains. The syntax is as follows:
set_instance instance -domain_mapping {child_domain parent_domain}
The specified instance must be an instantiation of the cell specified by set_macro_model.

If more than one domain is mapped, enclose the domain pairs in curly braces.
For the example, the always-on domain in the macro cell (Pd_AON) is mapped to the
always-on domain at the top level (PDBlue). Domain Pd_EXT (externally switchable) in the
macro model is mapped to domain PDRed, which has a shutoff signal.
set_instance ipInst -domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}}
Once a block-level power domain is mapped into a top-level power domain, the two power
domains are considered identical and the two domains share the same power characteristics.
When you instantiate a macro cell in the design, you must indicate which CPF macro model
applies to the specified instance. This can be done in either of the following ways:
By first including the macro model definition, and then using the set_instance
command with the -model option.
...
...
end_macro_model
set_instance ipInst -model IPBlock \
-domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}}
If the macro model definition is in a separate file, you can load it with an include
include macro.cpf
set_instance ipInst -model IPBlock \
-domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}}
June 2013
223

By using the set_instance command followed by the macro model definition.

...
...
end_macro_model
If the macro model definition is in a separate file, you can load it with an include
include macro.cpf
CPF File for the Top Level

The following file, top.cpf, shows the top-level CPF file with all simulation-related
commands:
set_design top
######################
# Create power domains
######################
create_power_domain -name PDBlue -default
create_power_domain -name PDRed \
-shutoff_condition {pso} \
-default_isolation_condition {I1/iso1} \
-base_domains PDBlue
########################################################
# Define isolation rules
# If domain PDRed can be off, while domain Pd_PSO is on,
# isolation is required on pin D2.
########################################################
-from PDRed -pins {D2} \
June 2013
224

############################################################
# Define state retention rules for registers in domain PDRed
############################################################
create_state_retention_rule -name ... \
-domain PDRed \
-secondary_domain PDBlue \
-save_edge ...
#################################################
# Map domains in macro model to top-level domains
#################################################
##################################################
# include command specifies macro model for ipInst
##################################################
include macro.cpf
end_design
June 2013
225

June 2013
226
10
You enable and control low-power simulation by using command-line options. All
command-line options related to low-power simulation begin with -lps_.
When simulating a design with CPF power information, it is recommended that you simulate
in the following three modes:
1. Simulate and debug the design without power information.
Compile your design files, elaborate the design, and simulate with no low-power
command-line options.
2. Simulate and debug the design with power information.
Compile your design files, and then elaborate with the following two command-line
options:
-lps_cpf cpf_filename
This option specifies the name of the CPF file to be used with the design or block
that is being simulated.
-lps_simctrl_on
This option enables simulation-time control over power simulation. Using this option
lets you elaborate the design and generate a snapshot with power, and then
simulate the snapshot using command-line options to control the simulation.
The -lps_off option lets you turn off power behavior without re-elaborating the
design. This option provides an easy way to switch between simulating with and
without power information.
3. Run regression tests.

Elaborate with power on, but disable run-time control of power behavior (by removing the
-lps_simctrl_on option) to increase simulation performance.
June 2013
227

Running in Multi-Step Invocation Mode

Figure 10-1 on page 228 illustrates the flow when debugging the design with power (mode 2
above) if you are running the simulator in multi-step invocation mode.
Figure 10-1 Debugging with Power in Multi-Step Mode
Source
ncvlog/ncvhdl
Compile the design.
Elaborate the design.

CPF
ncelab
ncelab -lps_cpf cpf_file
-lps_simctrl_on
[other_options]
top_level_unit
The elaborator reads the CPF file and

creates the necessary logic to model
your designs power requirements.
The -lps_simctrl_on option
enables the use of several low-power
command-line options at simulation
time.
Snapshot
ncsim
Simulate the snapshot.
ncsim [-lps_options]
[other_options]
snapshot_name
After simulating and debugging the design with power information, you can disable run-time
control of power behavior by removing the -lps_simctrl_on option from the ncelab
command line to increase simulation performance. Any -lps_* options that you want to use
must be moved from the ncsim command line to the ncelab command line. Low-power
simulation options specified on the ncsim command line will be ignored.
June 2013
228

Simulating with irun

If you are running the simulator in single-step invocation mode with irun, all command-line
options and source files are specified on the irun command.
% irun -lps_cpf cpf_filename -lps_simctrl_on \
[-lps_options] \
[other_options] \
source_files
irun uses the file extensions of the input files specified on the command line to determine
their file type, and then passes the files to the appropriate compiler. After the input files have
been compiled, irun invokes ncelab to elaborate the design and then invokes the ncsim
simulator. Command-line options are automatically passed to the compiler, the elaborator, or
the simulator, as required. In the example shown above, the -lps_cpf and
-lps_simctrl_on options are passed to the elaborator. Other -lps_* options will be
passed to the simulator.
After simulating and debugging the design with power information, you can disable run-time
control of power behavior by removing the -lps_simctrl_on option from the command line
to increase simulation performance. Any low-power simulation options on the command line
will now be passed automatically to the elaborator.
Simulating with ncverilog

Note: ncverilog has been replaced with irun. Beginning with the IUS 8.1 release, using the
ncverilog command invokes irun.
irun supports the ncverilog set of command-line options. The +nclps_* options that were
used with the ncverilog executable can still be used for a low-power simulation.
Command-Line Options for Low-Power Simulation

This section describes the command-line options that you use to enable and control
low-power simulation.
Many of the low-power command-line options can be used at either:
June 2013
229

Elaboration time
For multi-step invocation mode, the option would be included on the ncelab command
line. For single-step invocation mode with irun, the options are automatically passed to
the elaborator.
Simulation time
You can enable simulation-time control over power simulation with the elaborator
-lps_simctrl_on option. In this case, low-power command-line options are included
on the ncsim command line for multi-step invocation mode. For single-step invocation
mode with irun, the options are automatically passed to the simulator.
-lps_alt_srr
Overrides the default behavior for save and restore operations when modeling state retention
cells with save or restore preconditions.
See Modeling State Retention with Save or Restore Preconditions on page 105 for details
on this option.
ncsim
-lps_alt_srr
irun
-lps_alt_srr
-lps_assign_ft_buf
Specifies that a continuous assignment is to be treated as a buffer.
By default, a net from an always-on domain that enters and passes through a power-down
domain (a feedthrough net modeled as a continuous assignment) is treated as a wire and is
not forced to X when the domain is powered down. Use the -lps_assign_ft_buf option
to specify that a continuous assignment is to be treated as a buffer. In this case, the
feedthrough net will be corrupted.
ncelab
-lps_assign_ft_buf
irun
-lps_assign_ft_buf
June 2013
230

-lps_blackboxmm
Treat all macro models as a black box.
If full low-power functionality is specified within the behavioral model of the macro model, it
can be treated as a black box in simulation.
For a macro model that is treated as a black box:
All corruption, isolation, and state retention outside the macro model is limited to the
boundary ports defined by the macro model. All input boundary ports of the macro model
will assume there is a load inside the macro model in the domain associated with the
input boundary port. All output boundary ports of the macro model will assume a driver
inside the macro model in the domain associated with the output boundary port.
All corruption, isolation, and state retention defined inside the macro model (that is,
inside set_macro_model and end_macro_model) is ignored. All isolation and state
retention rules are ignored. Boundary ports are not corrupted. Registers that are part of
a switchable power domain are not corrupted. A black box macro model will not apply
any corruption to an internal domain even if it is mapped to an external switchable
domain.
By default, the simulator treats all macro models as having a partially power-aware model,
and treats them as gray boxes.
You must use the -lps_blackboxmm option (ncelab -lps_blackboxmm or irun
-lps_blackboxmm) to treat macro models as black box models.
See Chapter 9, Modeling a Macro Cell, for details on macro models.
ncelab
-lps_blackboxmm
irun
-lps_blackboxmm
-lps_cellrtn_off
Suppresses implicit state retention insertion from primitive cells.
In a mixed gate/RTL simulation, the implicit state retention behavior should apply to the RTL
portions of the design, but must not apply to a gate netlist or to primitive cells instantiated in
the RTL code. Use the -lps_cellrtn_off option to exclude primitive cells from the implicit
state retention behavior.
June 2013
231

See Simulating a Mixed RTL/Gate Design with Instantiated Primitive Cells on page 277 for
details on using this option.
ncelab
-lps_cellrtn_off
irun
-lps_cellrtn_off
Specifies the name of the CPF file to be used with the design or block being simulated.
Power information can be specified in multiple CPF files, each of which describes power
information for a block of the design. In most cases, there is one CPF file that specifies the
power information for the whole design by directly or indirectly sourcing other CPF files. The
CPF file specified with the -lps_cpf option is the CPF file corresponding to the design being
simulated.
ncelab
irun
-lps_dtrn_min
Treats the value specified for the transition slope or transition latency with an
update_power_domain command as the minimum transition time.
You can specify the delay for a power domain to reach its destination nominal condition. The
delay is specified by updating the power domain (update_power_domain command) with
either the -transition_slope or -transition_latency option.
-transition_slope [float:]float
-transition_latency {from_nom to_nom@[float:]float}
If you specify two numbers, the first number indicates the minimum transition time, and
the second number indicates the maximum transition time.
If you specify only one value, it is considered to be the maximum transition time.
June 2013
232

By default, the simulator uses the maximum transition time. Use the elaborator
-lps_dtrn_min option to override this default and use the minimum time. If a single number
has been specified, the number is treated as the minimum.
See Specifying the Time It Takes for Power Domain Transitions on page 165 for more
information.
ncelab
-lps_dtrn_min
irun
-lps_dtrn_min
-lps_enum_rand_corrupt [seed]
When power is shut off, corrupt objects of VHDL user-defined enumerated types with a value
that is randomly selected from the enumeration literals.
When a domain is powered down, this option randomly selects one of the enumeration literals
as the corruption value. The selected enumeration literal is not the same as the current value,
and the left-most value is selected only if there is no other choice.
Specifying a seed value is optional, but will produce repeatable results. If no seed is specified,
the default is 0.
States are not restored automatically when power is restored. A state element will remain
corrupted unless it is restored or reset.
Besides the -lps_enum_rand_corrupt option, you can specify how VHDL enumerated
types are corrupted at power down with the following options:
-lps_enum_right
-lps_implicit_pso
-lps_implicitpso_char
-lps_implicitpso_nonchar
See Corruption of VHDL User-Defined Enumerated Types for details on the corruption of
VHDL enumerated types.
ncsim
irun
June 2013
233

-lps_enum_right
When power is shut off, corrupt objects of VHDL user-defined enumerated types with the
right-most values.
When a domain is powered down, this option selects the right-most enumeration literal as the
corruption value.
Besides the -lps_enum_right option, you can specify how VHDL enumerated types are
corrupted at power down with the following options:
-lps_enum_rand_corrupt
-lps_implicit_pso
ncsim
-lps_enum_right
irun
-lps_enum_right
-lps_ft_graph
Enable preprocessing of VHDL files that is required when elaborating a design for low power
in 3-step mode with the ncvhdl command.
The simulator uses a feedthrough and driver/load analysis infrastructure that requires VHDL
files to be compiled with this option.
When elaborating VHDL code in 3-step mode, that is, when using ncvhdl, use the
-lps_ft_graph switch. The switch is not needed when compiling VHDL code with irun.
June 2013
234

Note: While some VHDL files do not require the preprocessing enabled by the
-lps_ft_graph option, Cadence recommends that the option always be used when
compiling VHDL files in 3-step mode for low-power simulation.
ncvhdl
-lps_ft_graph
-lps_implicit_pso
Enable an implicit power-down state for VHDL user-defined enumerated types.
This option adds an implicit enumeration literal as the right-most literal of the enumerated type
to represent the power off state. If the enumeration literals in the enumeration type definition
are character literals, an X enumeration literal is added. If the enumeration literals in the
enumeration type definition are identifiers, an X enumeration literal is added. Implicitly adding
an enumeration literal as the right-most literal ensures that the behavior of default
initializations is preserved.
The implicit enumeration literal is added to base types only. An implicit literal is not defined
for a subtype derived from the base enumerated type.
If the enumerated type definition includes an X or X enumeration literal, the elaborator
generates an error informing you that you must use one of the following elaborator options to
provide a value to be used as the power-down state:
-lps_implicitpso_char value
Specifies a character literal to be used as the power-down state.
-lps_implicitpso_nonchar value
Specifies a non-character literal (identifier) to be used as the power-down state.
The -lps_implicit_pso option is a compile-time (ncvhdl) option that may not apply
globally to the entire design.
If the source file that contains the enumerated type definition is compiled with
-lps_implicit_pso, objects of that type will be corrupted with the implicit X value, or
with the value specified with -lps_implicitpso_char or
-lps_implicitpso_nonchar.
If the source file that contains the enumerated type definition is not compiled with
-lps_implicit_pso, you can control the corruption value by using either
-lps_enum_right or -lps_enum_rand_corrupt.
June 2013
235

ncvhdl
-lps_implicit_pso
irun
-lps_implicit_pso
-lps_implicitpso_char value
When power is shut off, corrupt objects of VHDL user-defined enumerated types that have
character literals specified in the definition with the character literal specified by the value
argument.
-lps_implicitpso_char Y
If the source file that contains the definition of an enumeration character type has been
compiled with the -lps_implicit_pso option, an X enumeration literal is implicitly
added as the right-most literal in the enumeration type definition to represent the power-down
state. However, if the definition of the enumerated type includes an X character literal, the
elaborator generates an error telling you that there is a conflict between the existing X
enumeration literal and the implicitly-added X.
Use the elaborator -lps_implicitpso_char option (ncelab
-lps_implicitpso_char or irun -lps_implicitpso_char) to override the default
implicitly-added X value. The specified character literal will be used as the power-down
state.
Note: If the source file has not been compiled with -lps_implicit_pso, the
-lps_implicitpso_char option is ignored with a warning.
ncelab
irun
June 2013
236

-lps_implicitpso_nonchar value
When power is shut off, corrupt objects of VHDL user-defined enumerated types that have
identifiers specified in the definition with the identifier specified by the value argument.
-lps_implicitpso_char Y
If the source file that contains the definition of the enumerated type has been compiled with
the -lps_implicit_pso option, an X enumeration literal is implicitly added as the
right-most literal in the enumeration type definition to represent the power-down state.
However, if the definition of the enumerated type includes an X enumeration literal, the
elaborator generates an error telling you that there is a conflict between the existing X
enumeration literal and the implicitly-added X.
Use the elaborator -lps_implicitpso_nonchar option (ncelab
-lps_implicitpso_nonchar or irun -lps_implicitpso_nonchar) to override the
default implicitly-added X value. The specified enumeration literal will be used as the
power-down state.
Note: If the source file has not been compiled with -lps_implicit_pso, the
-lps_implicitpso_nonchar option is ignored with a warning.
ncelab
irun
-lps_int_index_nocorrupt
Disables the corruption of VHDL integers that are used as an array index.
powers off. If an integer is used as an index of an array, this could result in an index constraint
violation.
The -lps_int_index_nocorrupt option specifies that the current value of an integer
used as an array index is to be frozen when the corresponding power domain is powered
down. The integer keeps this frozen value throughout the shutdown period. The array itself is
corrupted normally.
When the domain powers back up, there may be no transition on these frozen integers. In this
case, signals will not be updated, and processes that are sensitive to the integers will not be
June 2013
237

replayed. The -lps_int_index_nocorrupt option identifies processes that are sensitive
to these integers and replays them.
See Disabling the Corruption of VHDL Integers Used as an Array Index on page 90 for more
information.
ncelab
irun
-lps_int_nocorrupt
Disables the corruption of all VHDL integers in the design.
powers off. This option disables the default corruption semantics for all VHDL integers. When
power is shut off, the value of the integers can change depending on their drivers.
Using this option can be useful when debugging initial low-power issues and getting a
low-power simulation to run. However, disabling the corruption of all integers means that the
simulator is treating the VHDL integers as if they are continuously powered objects. For
domains that include these integers that means that the simulator is being overly optimistic in
not corrupting the integer when power for the domain is switched off. In reality the synthesized
result of the integer will be powered by the switched supply for the domain. Consequently RTL
vs. gate behavior for the object will be different. Therefore, the elaborator generates the
following warning when the option is used:
ncelab: *W,INTNOC: All VHDL integer corruption is turned off. RTL vs gate results
will differ for VHDL integers within shutoff domains.
You can use the -lps_int_index_nocorrupt option to disable the corruption of VHDL
integers that are used as an index of an array. If both -lps_int_nocorrupt and
-lps_int_index_nocorrupt are included on the command line, the
-lps_int_index_nocorrupt option is ignored.
You can disable the corruption of specific integers by using the CPF set_sim_control
command.
set_sim_control -action disable_corruption -type integer -targets ...
You can run HAL to automatically generate set_sim_control commands that will disable
the corruption of integers that should not be corrupted. You can then add these commands
to your CPF file.
June 2013
238

See Disabling Corruption of Integers, Reals, or Verilog reg Variables on page 33 for details.
If you use the command in your CPF file and then include the -lps_int_nocorrupt option
on the command line, the option takes precedence, and corruption of all integers is disabled.
ncelab
-lps_int_nocorrupt
irun
-lps_int_nocorrupt
-lps_iso_off
Turns off port isolation.
By default, port isolation is enabled. When simulating an RTL design, which does not
instantiate any isolation cells, the CPF file specifies the port isolation to be provided implicitly
by the simulator. However, when simulating a gate-level netlist with isolation cells inserted,
the port isolation behavior is built into the simulation model of these cells, and there is no need
for the simulator to provide this behavior. Use the -lps_iso_off option at elaboration time
to turn off port isolation.
The -lps_iso_off option can be used as a simulation-time control option. You must
elaborate with the -lps_simctrl_on option to enable the use of this option at simulation
time.
ncelab
-lps_iso_off
ncsim
-lps_iso_off
irun
-lps_iso_off
-lps_iso_verbose
Enables reporting of isolation information.
This option logs only the isolation information. By default, the isolation information is written
to the default log file (ncelab.log or irun.log). Use the -lps_logfile option to create
a log file that contains only the isolation information. For example:
-lps_iso_verbose (Writes isolation information to the default log file)
-lps_iso_verbose -lps_logfile iso.log (Writes isolation information to iso.log)
Use the -lps_verbose option if you want to log other low-power information, not only the
isolation information.
June 2013
239

The -lps_iso_verbose option can also be used as a simulation-time control option. You
must elaborate with the -lps_simctrl_on option to enable the use of this option at
simulation time.
ncelab
-lps_iso_verbose
ncsim
-lps_iso_verbose
irun
-lps_iso_verbose
Enable reporting of isolation filtering information.
This option prints messages for pins that have not been isolated, with a leading string that
indicates why they were not isolated.
<L> indicates that the pin was not isolated due to Load filtering.
<D> indicates that the pin was not isolated due to Driver filtering.
<DUP> indicates that the pin was not isolated because placing isolation on the pin would
result in duplicate isolation.
<I> indicates that the pin was not isolated because it was invalid for the specified rule.
<EX> indicates that the pin was filtered out by an -exclude or -pins option.
Example:
In the following message, port tb.test.ISO1.B is identified as not isolated. The leading
<L> in the message indicates that it is not isolated due to Load filtering (that is, the port did
not meet load requirements).
******Isolation Filtering Information
Following pins from isolation rule at (./cpf.cpf:11) are not isolated:
<L> tb.test.ISO1.B
By default, the isolation filtering information is written to the default log file (ncelab.log or
irun.log). Use the -lps_logfile option to create a log file that contains only the
isolation filtering information. For example:
(Writes isolation filtering

information to the default log file)
-lps_isofilter_verbose -lps_logfile iso.log (Writes isolation filtering

information to iso.log)
June 2013
240

To get a log file containing all isolation information, including the isolation filtering messages,
use the following three options:
-lps_isofilter_verbose -lps_iso_verbose -lps_logfile filename.log
Include the -lps_verbose option if you want to log other low-power information, not only
the isolation information.
ncelab
irun
Prints a warning message if an isolation rule has been optimized away.
By default, no warning message is generated when a create_isolation_rule command
is ignored. Use -lps_isoruleopt_warn to enable the printing of warning messages, such
as the following example:
ncelab: *W,NOISELE: [LPS] The isolation rule (ISO1) has no element (./cpf.cpf:9)
and the rule has been optimized away.
Use the -lps_isofilter_verbose option to enable reporting of isolation filtering

information.
ncelab
irun
-lps_log_verbose filename
Writes the low-power static information generated by the -lps_verbose option to a log file
with the specified name. You must use the -lps_verbose option with
-lps_log_verbose.
This option writes only the -lps_verbose output to the specified file. If you do not include
the -lps_log_verbose option, the output of -lps_verbose is printed to the file specified
with the -lps_logfile option.
For example, the following command generates three log files:
June 2013
241

% irun -lps_cpf dut.cpf -lps_verbose 3 \
-logfile simrun.log \
;# Creates log file simrun.log (instead of irun.log)
-lps_logfile lps.log \
;# Creates lps.log for low-power information
-lps_log_verbose lps_verbose.log \
;# Creates lps_verbose.log for

-lps_verbose output
[other_options] source_files
The -lps_log_verbose option can be used as an elaborator or simulator option.
ncelab
ncsim
irun
-lps_logfile filename
Writes the low-power simulation information to a log file with the specified name.
By default, low-power simulation information is written to the default log file: ncelab.log,
ncsim.log, or irun.log. Use the -lps_logfile option to specify a different log file.
This option writes all low-power simulation information to a log file, including the low-power
static information generated by the -lps_verbose option. Include the -lps_log_verbose
filename option if you want to redirect the output of -lps_verbose to its own log file.
The -lps_logfile option can be used as an elaborator or simulator option.
ncelab
ncsim
irun
-lps_loopvar_verbose
Writes out the loop variables that are excluded from corruption. See Loop Variables
Excluded from Corruption on page 45 for more information.
ncelab
June 2013
242

ncsim
irun
-lps_modules_wildcard
Enables the use of wildcard characters in the module_list argument of the CPF
set_sim_control -modules option.
Care must be taken when using wildcards in the module_list argument to the
set_sim_control -modules option. The -modules option performs a tree search
starting at the current scope, or the scope specified with the -instances option. Every initial
block in the current scope down to the leaf scopes will be replayed. Using a wildcard to specify
the modules can result in accidentally replaying initial blocks in unintended modules. Using a
wildcard at a high-level scope will also adversely affect elaborator performance. For these
reasons, you must explicitly enable the use of wildcards with -modules with the elaborator
-lps_modules_wildcard option.
See set_sim_control on page 29 for more information and for guidelines on using wildcards
with set_sim_control -modules.
ncelab
irun
-lps_mtrn_min
Treats the value specified for the transition time with a create_mode_transition
-latency option as the minimum latency.
When you use the create_mode_transition command to define a legal transition from
one power mode to a different power mode, you can include the -latency option to specify
the time needed to complete the transition.
-name string
-from power_mode -to power_mode
-start_condition expression [-end_condition expression]
[-latency [float:]float]
If you specify two numbers, the first number indicates the minimum time needed, and the
second number indicates the maximum time needed.
June 2013
243

If you specify only one value, it is considered to be the maximum time. Use the elaborator
-lps_mtrn_min option to override this default and use the minimum time.
ncelab
-lps_mtrn_min
irun
-lps_mtrn_min
-lps_mvs
Turns on voltage scaling simulation and voltage tracking.
This option specifies that power domain nominal condition transitions are controlled by the
domain-level active state conditions (create_power_domain
-active_state_conditions). Power mode (create_power_mode) and mode
transition (create_mode_transition) commands, if present in the CPF file, are ignored.
Domain transition and voltage (nominal condition) changes are tracked. Built-in power mode
and mode transition checking is not performed.
See Controlling a Power Mode Simulation on page 157 for more information.
ncelab
-lps_mvs
irun
-lps_mvs
-lps_no_xzshutoff
Ignore an unknown value on the power domain shutoff control signal.
An unknown value (X, U, or Z) on the power shutoff control signal means that the state of the
power domain is unknown. In simulation, by default, a domain is powered down when the
shutoff control signal has an unknown value. If the -lps_stime option is used, the power
domain is shut off if the shutoff signal is true or X/U/Z at the specified time, and remains true
or X/U/Z after the specified time.
At the time that low-power simulation starts (the time specified with the -lps_stime option
or time 0 if -lps_stime is not used), the current value of all power control signals is
evaluated. The domain is corrupted if the shutoff signal is true or has an unknown value.
Control signals for isolation and state retention are also evaluated. If these control
expressions are true, isolation and state retention will be applied.
June 2013
244

Use the -lps_no_xzshutoff option to turn off the default domain corruption behavior. The
simulator will ignore all transitions to X/U/Z values on shutoff conditions.
ncelab
-lps_no_xzshutoff
irun
-lps_no_xzshutoff
-lps_notlp
Turn off special treatment for top-level ports.
Top-level ports can be explicitly defined as boundary ports using the
Top-level input ports are assumed to have a driver in the domain associated with the port.
Top-level output ports are assumed to have a load in the domain associated with the port.
domain. The default behavior for top-level ports is consistent with CLP, RC, and other tools in
the low-power CPF flow.
This treatment of top-level ports affects both corruption and isolation. See Corruption of
Top-Level Ports on page 82 for information on corruption, and Isolation of Top-Level Ports
on page 139 for information on isolation.
The -lps_notlp option turns off the default behavior for ports that are not explicitly defined
as boundary ports with -boundary_ports. These ports will not be implicitly defined as
boundary ports, and the ports will not be associated with the default domain. The
-lps_notlp option has no effect on ports that are explicitly defined as boundary ports.
-lps_off
Turns off all low-power simulation.
June 2013
245

This is a simulation-time control option. You must elaborate with the -lps_simctrl_on
option to enable the -lps_off option.
ncsim
-lps_off
irun
-lps_simctrl_on -lps_off
-lps_pmode
Turns on power mode simulation, mode tracking, and built-in mode checking, in addition to
voltage tracking.
Use -lps_pmode if you intend to drive the simulation through the power mode specification.
Power domain nominal condition transitions are controlled through the power mode
specification (create_power_mode and create_mode_transition commands).
Checks are performed to ensure consistency between domain-level and mode-level controls.
The simulator generates an error if there is a conflict between the power modes and the active
state conditions.
The -lps_pmode option implies -lps_mvs. You can include both options on the command
line, or just -lps_pmode.
% irun -lps_cpf dut.cpf -lps_mvs -lps_pmode ....
% irun -lps_cpf dut.cpf -lps_pmode ....
ncelab
-lps_pmode
irun
-lps_pmode
-lps_pmcheck_only
Specifies that domain-level controls (active state conditions specified with
create_power_domain -active_state_conditions) drive the power domain
nominal condition transitions, and the power mode/mode transition specification is used for
verification, not control.
This option specifies that power mode and mode transitions will be used for verification only.
Domain transitions are controlled through the active state conditions. Checks are performed
to ensure consistency between domain-level and mode-level controls. The simulator
June 2013
246

generates an error if there is a conflict between the power modes and the active state
conditions.
The -lps_pmcheck_only option implies -lps_mvs and -lps_pmode. You can include all
three options on the command line, or just -lps_pmcheck_only.
% irun -lps_cpf dut.cpf -lps_mvs -lps_pmode -lps_pmcheck_only ....
% irun -lps_cpf dut.cpf -lps_pmcheck_only ....
ncelab
-lps_pmcheck_only
irun
-lps_pmcheck_only
-lps_real_nocorrupt
Disables the corruption of all real variables in the design. This option does not apply to wreal
variables.
ncsim
-lps_real_nocorrupt
irun
-lps_real_nocorrupt
-lps_rtn_lock
Locks the value of state retention elements, so that the value does not change between:
The save operation and power down
Power up and state restoration
Figure 10-2 on page 248 shows the default (without -lps_rtn_lock) sequence of
operations for a design with a single Save/Restore signal. On the rising edge of the
Save/Restore signal, the value of Qm (master register) is stored in Qs (save register). When
the power is shut off, Qm is forced to X, simulating power-down behavior. The force on Qm is
released on power up, and Qm is restored with the value in Qs on the falling edge of the
Save/Restore signal.
If there is an event that causes the value of Qm to change between the save operation and
power down, or between power up and the restore operation, the value of Qm will change.
June 2013
247

Figure 10-2 Simulating without -lps_rtn_lock
Value of Qm
stored in Qs.
Qm restored with
Power up.
Force on Qm value of Qs.
released.
Power down.
Value of Qm
forced to X.
Qm
Poff
Save/Restore
Use the -lps_rtn_lock option if you want to prevent state retention elements from
changing value during these periods. If you use the -lps_rtn_lock option, the value of Qm
will be locked between the save operation and power down, and Qm will remain at X until the
falling edge of the Save/Restore signal.
The -lps_rtn_lock option can also be used as a simulation-time control option. You must
time.
ncelab
-lps_rtn_lock
ncsim
-lps_rtn_lock
irun
-lps_rtn_lock
-lps_rtn_full_lock
Locks the value of state retention elements, so that the value does not change between:
The save operation and power down
The negative edge of the save signal
Using the -lps_rtn_full_lock option, extends the retention lock to the negative edge of
the save edge signal and protects the value from reset as shown in Figure 10-3 on page 249.
June 2013
248

Figure 10-3 Simulating with -lps_rtn_full_lock
Reset
Save
Power up
Restore
Release
lock
rst
Shut off
Save edge
Without the -lps_rtn_full_lock option, when a retention rule is defined with a single
retention control save edge and without a restore edge, the save occurs at the positive edge
of the save signal and the restore occurs at power up. In this case the retention lock holds the
state retention element values between the save operation and power-up/state restoration.
The value is restored at power-up and is then reset at the positive edge of the rst signal
because the retention lock does not protect the value after power-up.
-lps_rtn_off
Turns off state retention.
By default, state retention is enabled. When simulating an RTL design, which does not
instantiate any state retention cells, the CPF file specifies the state retention behavior to be
provided implicitly by the simulator. However, when simulating a gate-level netlist with state
retention cells inserted, the state retention behavior is built into the simulation model of these
cells, and there is no need for the simulator to provide this behavior. Use the -lps_rtn_off
option at elaboration time to turn off state retention.
The -lps_rtn_off option can be used as a simulation-time control option. You must
time.
ncelab
June 2013
-lps_rtn_off
249

ncsim
-lps_rtn_off
irun
-lps_rtn_off
-lps_simctrl_on
Enables simulation-time control over the power simulation.
This option lets you elaborate the design with power and then control the power simulation
without re-elaborating the design.
In multi-step invocation mode, you include this option on the ncelab command line, and then
include the options that control the power simulation on the ncsim command line. For
example:
% ncelab -lps_cpf cpf_file -lps_simctrl_on [other_elab_options] top_level_unit
% ncsim -lps_iso_off [other_sim_options] snapshot_name
In single-step mode with irun, using -lps_simctrl_on causes the tool to pass the
low-power command-line options to the simulator (ncsim) instead of to the elaborator
(ncelab). For example:
% irun -lps_cpf cpf_file -lps_simctrl_on -lps_iso_off [other_options]
source_files
ncelab
-lps_simctrl_on
irun
-lps_simctrl_on
-lps_sim_verbose report_level
Specifies a level of information reporting during simulation.
In the current release, the only supported level is 0.
-lps_sim_verbose 0
The -lps_sim_verbose 0 option suppresses all informational messages that are

generated by default during a power mode simulation. Error messages and warning
messages, such as the warnings that are generated when a transition occurs at an input of a
power domain that is in standby mode, are not suppressed.
ncsim
June 2013
-lps_sim_verbose
250

irun
-lps_sim_verbose
-lps_srfilter_verbose
Enable reporting of state retention filtering information.
The simulator analyzes the HDL code associated with the elements specified in the
create_state_retention_rule command, identifies latches and flip flops, and applies
state retention only to these sequential elements. By default, state retention is applied to both
flops and latches. The -target_type option can be used to specify that retention is to be
applied to flops only or to latches only.
Use the -lps_srfilter_verbose option to enable reporting of state retention filtering
information. This option prints a list of elements that have been disqualified for retention,
either because the element was determined to be combinational, or because the element did
not satisfy the target type requirement.
For example, if a state retention rule specifies -target_type {latch}, the
-lps_srfilter_verbose option may print a list similar to the following:
******Disqualified retention elements:
tb.dut.m1.ddafull (Flop)
tb.dut.m1.ddaempty (Flop)
tb.dut.m1.ddfull (Flop)
tb.dut.m1.vgate_cnt (Flop)
tb.dut.m1.hgate_div_val (Non Sequential Element)
tb.dut.m1.hgate_cnt_val (Non Sequential Element)
ncelab
irun
-lps_srruleopt_warn
Prints a warning message if a state retention rule has been optimized away.
A state retention rule can be optimized away if all of the elements selected in the
create_state_retention_rule command are determined to be combinational, or if
there are no sequential elements of the type specified with -target_type (for example, if
you specify -target_type {latch} and there are no sequential elements that are latches.
June 2013
251

By default, no warning message is generated when a create_state_retention_rule
command is not applied. Use -lps_srruleopt_warn to enable the printing of warning
messages, such as the following example:
ncelab: *W,NORTELE: [LPS] The retention rule (RET_1) has no state element
(./test.cpf:34) and the rule has been optimized away.
ncelab
-lps_srruleopt_warn
irun
-lps_srruleopt_warn
-lps_stdby_nowarn
Suppresses the warning messages that are generated when a transition occurs at an input
of a power domain that is in standby mode.
When a power domain is in standby mode, the inputs to the domain should not transition. If
an input does change during standby mode, the input is corrupted, and, by default, a warning
message is generated.
In the following example, power mode pdB transitions to standby mode at time 814 ns. At time
815 ns, part of the input bus x (x[0]) changes value, and this bit is corrupted with a warning.
At time 825 ns, x[1] changes value and this bit is corrupted with a warning.
NC_STANDBY

Power domain pdB has transitioned to nominal condition
...
...
Use the -lps_stdby_nowarn option to suppress the generation of the input violation
warning messages.
The -lps_stdby_nowarn option can be used as a simulation-time control option. You must
elaborate with the -lps_simctrl_on option to enable this option at simulation time.
ncelab
June 2013
-lps_stdby_nowarn
252

ncsim
-lps_stdby_nowarn
irun
-lps_stdby_nowarn
-lps_stime start_time
Specifies the time when the simulator should start low-power simulation.
This option is useful when, at the beginning of simulation, there is a long initialization
sequence that does not include power signal activities.
The start_time argument is an integer value followed by a time unit. The unit can be ps,
ns, or s. If you do not specify a unit, the default is ps. For example, the following two options
are identical:
June 2013
253

-lps_stime 40ps
-lps_stime 40
If you do not use this option, low-power simulation begins at time 0.

The -lps_stime option can be used as a simulation-time control option. You must elaborate
with the -lps_simctrl_on option to enable this option at simulation time.
ncelab
ncsim
irun
-lps_stl_off
Turns off state loss.
By default, state loss is enabled. When simulating a gate-level netlist in which state retention
cells are represented by physical models with power and ground connections, the state loss
behavior is modeled by the cell itself. The simulator does not need to provide any implicit state
loss behavior. Use the -lps_stl_off option to turn off the CPF implicit state loss behavior.
The -lps_stl_off option can be used as a simulation-time control option. You must
time.
ncelab
-lps_stl_off
ncsim
-lps_stl_off
irun
-lps_stl_off
-lps_upcase
Converts all identifiers in the CPF file to uppercase.
This option is required if you:
Are running in multi-step mode.
Have compiled your Verilog source files with the -upcase option.
June 2013
254

% ncvlog -upcase [other_options] source_files
% ncelab -lps_cpf filename -lps_upcase [other_options] top_level_unit
The ncvlog -upcase option converts all identifiers in the Verilog source files to uppercase.
The ncelab -lps_upcase option is then required to convert indentifiers in the CPF file to
uppercase.
If you are running in single-step mode with irun, the -u (or -upcase) option converts Verilog
identifiers to uppercase. Using -u, or -upcase, with -lps_cpf will automatically convert
identifiers in the CPF file to uppercase. With irun, including -lps_upcase is not required.
% irun -u -lps_cpf filename ...
Enables reporting of low-power static information and specifies the level of information that
you want reported.
By default, the low-power static information is printed to the default log file (ncelab.log,
ncsim.log, or irun.log).
If you include the -lps_logfile filename option, the low-power static information
is printed to the specified file, along with all other low-power information.
If you also include the -lps_log_verbose filename option, the low-power static
information is printed to the specified file. Other low-power information is printed to the
file specified with the -lps_logfile option.
The argument to the -lps_verbose option can be 1, 2, or 3. Level 1 prints basic power
information, and levels 2 and 3 print more detailed information. See -lps_verbose Reporting
Levels for details.
The -lps_verbose option can be used as an elaborator or simulator option.
ncelab
ncsim
irun
-lps_verbose Reporting Levels

All -lps_verbose output, regardless of the specified level, begins with the following two
sections:
June 2013
255

LPS OPTIONS
Displays all low-power simulation command-line options used in the simulation.
LPS OPTIONS
-lps_log_verbose: verbose.log
-lps_mvs
-lps_pmcheck_only
-lps_stime: 1000
-lps_verbose: 2
CPF FILES
Displays all CPF files used in the simulation.
CPF FILES
./top.cpf
../cpf/mode.cpf
../cpf/nc.cpf
The -lps_verbose output can be divided into two sections. The first section contains
information about the power domains; the second section contains information about power
modes. The following two tables show you what information is printed to the log file with
-lps_verbose 1, and what information is added when you specify -lps_verbose 2 or
-lps_verbose 3.
June 2013
256

Table 10-1 Power Domain Information in -lps_verbose Output

-lps_verbose 1
-lps_verbose 2 adds ...
domain name and scope
CPF source/line of power

domain rule
domain instances
base domain names

mapped domain names
power mode control group
name
boundary ports
initial blocks for power replay

CPF source/line for mapped
domains
current slope, min slope,

max slope
Isolation:
rule name and scope
secondary domain
isolation output
CPF source/line of isolation

rule
isolation ports
control condition
State Retention:
rule name and scope
CPF source/line of retention

rule
secondary domain
save edge/level
target type
register names
restore edge/level
save/restore precondition
Active State Conditions:
nominal condition name
expression
Assertion Control:
rule name and scope
CPF source/line of assertion

control rule
type (reset or suspend)
disable condition
assertion names
power domain name
June 2013
257

Table 10-2 Power Mode Information in -lps_verbose Output

-lps_verbose 1
CPF source/line of nominal

condition command
For power mode

information,
-lps_verbose 3 is
the same as
-lps_verbose 2
Nominal Conditions:
name
scope
voltage
state
Power Mode Control

Group:
name
scope
CPF source/line of control

group command
power domain names

power mode names
power mode transitions
(with from and to modes)
Power Modes:
name
scope
power domain name and
nominal condition
CPF source/line of power

mode command
group modes
Power Mode
Transitions:
name
scope
CPF source/line of mode

transition command
from and to mode
start condition
min and max latency
end condition
June 2013
258

-lps_verify
Enables the following advanced low-power verification features:
Automatic generation of assertions that check properties of control signals and their
correct sequencing
Automatic generation of a SystemVerilog coverage model for low-power control signals
See Chapter 14, Advanced Low-Power Verification Features, for details.
ncelab
-lps_verify
irun
-lps_verify
-lps_vplan vplan_filename
Generates a verification plan (vPlan) for power coverage for use by vManager. The generated
vPlan provides a more organized, easier to read, and better documented view of the
automated coverage data generated by the simulator.
See Chapter 14, Advanced Low-Power Verification Features, for details.
ncelab
-lps_vplan
irun
-lps_vplan
June 2013
259

June 2013
260
11
Simulating an RTL-Level Design
At the system and RTL level, there is no explicit logic in the HDL to model the three low-power
behaviors that are pertinent to simulation during the power-down process: state loss, state
retention, and port isolation. Because the power control structures are not part of the design,
implicit logic and methods must be created by the simulator to perform these functions. The
simulator creates the virtual logic from commands contained in the CPF file.
Simulating an Example Design

This section shows how to perform a low-power simulation on a simple nano CPU design.
Note: The source files for this example are located in the following directory:
install_directory/doc/PowerForwardUG/examples/pso
The nano CPU is a 32-bit RISC processor, shown in Figure 11-1 on page 261.
Figure 11-1 The Nano CPU Processor
June 2013
261

This design has the following power domains:
PDcoreThe default power domain, which contains the I/O controller, program counter,
state sequencer, power control unit, address register, instruction register, data-in
register, and data-out register
Power to this domain is always on.
PDauThe arithmetic unit power domain

The arithmetic unit requires state retention and isolation.
PDluThe logic unit power domain

The logic unit requires isolation, but not state retention.
PDaluThe ALU power domain

The ALU requires isolation, but not state retention.
PDrfThe register file power domain

The register file requires state retention and isolation.
The Power Control Unit generates the control signals for isolation, state retention, and power
switch enable. The power control signals, along with the power domains that they control, are
defined in Table 11-1 on page 262. The PDcore power domain is not associated with any
control signals because its power is always on.
Table 11-1 Nano Design Power Specification
Signals Controlling the Power Domains

Domains
Isolation Enable
State Retention
Enable
Power Switch
Enable
PDcore
PDau
pau[0]
pau[1]
pau[2]
PDlu
plu[0]
plu[2]
PDalu
palu[0]
palu[2]
PDrf
prf[0]
prf[1]
prf[2]
June 2013
262

Specifying Power Information in the CPF File

The CPF file used in this example is called nano.cpf. This file contains only commands that
pertain to simulation. However, a CPF file can contain commands that are used by
downstream tools. These commands are ignored during simulation.
See the Common Power Format Language Reference for complete details on the
commands used in the CPF file.
The nano.cpf file is as follows:
# Specify the CPF version.
set_cpf_version 1.1
# Specify the hierarchy delimiter character to be used in object names.
# Specify the name of the module to which the power information applies.
set_design core
# Define the power domains.
# Specify the instances that belong to the domain (-instances).
# Specify the condition when the domain is shut off (-shutoff_condition).
create_power_domain -name PDcore -default
create_power_domain -name PDalu \
-instances alu_inst \
-base_domains {PDcore} \
-shutoff_condition {pcu_inst/palu[2]}
# Power domain PDalu is base power domain of domain PDau
create_power_domain -name PDau \
-instances alu_inst/aui \
-base_domains {PDalu} \
-shutoff_condition {pcu_inst/pau[2]}
# Power domain PDalu is base power domain of domain PDlu
create_power_domain -name PDlu \
-instances alu_inst/lui \
-shutoff_condition {pcu_inst/plu[2]}
June 2013
263

create_power_domain -name PDrf \
-instances rf_inst \
-base_domains {PDcore} \
-shutoff_condition {pcu_inst/prf[2]}
# Define the rules for replacing registers in a power domain with state
# retention registers.
# Specify the instances to be replaced with a state retention register (-instances).
# Specify the condition when the states of the registers need to be
# restored (-restore_edge).
# The condition when the states of the registers need to be saved is the inversion
# of the restore_edge expression.
create_state_retention_rule -name PDrf_sr \
-instances {rf_inst/rf[*]} \
-restore_edge {!pcu_inst/prf[1]}
create_state_retention_rule -name PDau_sr \
-instances {alu_inst/aui/z*} \
-restore_edge {!pcu_inst/pau[1]}
# Define the rules for adding isolation cells.
# Specify the pins that must be isolated in a power domain (-pins).
# Limit the pins to be isolated to output pins in the power domain (-from).
# Specify the condition when the pins should be isolated (-isolation_condition).
# Specify the isolation type (-isolation_output).
create_isolation_rule -name PDau_iso \
-from PDau \
-pins alu_inst/aui/z* \
-isolation_condition {pcu_inst/pau[0]} \
create_isolation_rule -name PDlu_iso \
-from PDlu \
-pins alu_inst/lui/z*
-isolation_condition {pcu_inst/plu[0]} \
create_isolation_rule -name PDalu_iso \
-from PDalu \
-pins alu_inst/z* \
-isolation_condition {pcu_inst/palu[0]} \
June 2013
264

create_isolation_rule -name PDrf_iso \

-from PDrf \
-pins {rf_inst/a[*] \
rf_inst/b[*] \
rf_inst/z[*]} \
-isolation_condition {pcu_inst/prf[0]} \
#Define assertion control rules
create_assertion_control -name AC_1 \
-domains {PDau PDlu PDalu} \
-type {reset}
create_assertion_control -name AC_4 \
-domains {PDrf} \
-type {reset}
end_design core
Running the Simulation

For this example, we assume that you have simulated and debugged the design without
power information, and that you now want to simulate and debug the design with power. The
design will be elaborated with the -lps_simctrl_on option to enable simulation-time
control over the power simulation. Using this option lets you elaborate the design and
generate a snapshot with power and then simulate the snapshot using command-line options
to control the simulation.
You can simulate the design by invoking the compiler, elaborator, and simulator in separate
steps (multi-step invocation mode), or you can run the simulation in single-step invocation
mode with irun.
Simulating in Multi-Step Mode
1. Compile the design files.
% ncvlog nano_defines.v testbench.v nano.v
2. Elaborate with power.
June 2013
265

In the following command, the -lps_cpf option specifies the name of the CPF file. The
-lps_simctrl_on option enables the use of other low-power options to control the
simulation at run time.
% ncelab -mess -access +rwc -timescale 1ns/1ps \
-lps_cpf nano.cpf -lps_simctrl_on worklib.TESTBENCH
3. Run the simulator with the SimVision analysis environment (-gui option) and include the
necessary -lps options:
% ncsim -messages -lps_stime 1ns -lps_verbose 1 -lps_logfile lps.log \
-gui -input input.tcl worklib.TESTBENCH &
For a complete list of low-power command-line options, see Command-Line Options for
Low-Power Simulation on page 229.
When SimVision starts, the simulator collects low-power simulation information. This
information is displayed in the SimVision Console window and written to the lps.log
file.
The ncsim command includes the -input option, which sources the file input.tcl.
This file contains a database command to open a database and a probe command to
probe signals of interest. It then sources a file that opens a SimVision Waveform window,
adds signals to the window, and defines a mnemonic map for the power-up/power-down
opcodes.
4. Run the simulation using either of the following methods:
Click the Run button,
Choose Simulation Run from the menu.
, on the simulation toolbar.
The simulation results are displayed in the Waveform window.

Simulating with irun
The irun utility lets you run the simulator by specifying all input files and command-line
options on a single command line. For this example, the irun command is as follows:
irun -access +rwc -timescale 1ns/1ps -gui -input input.tcl \
-lps_cpf nano.cpf -lps_simctrl_on -lps_stime 1ns \
-lps_verbose 1 -lps_logfile lps.log \
nano_defines.v testbench.v nano.v &
In the SimVision window, run the simulation using either of the following methods:
Click the Run button,
Choose Simulation Run from the menu.
June 2013
, on the simulation toolbar.
266

Examining Simulation Results in the Waveform Window

The testbench exercises the power-down and power-up sequences of several power
domains. The first is the arithmetic unit. During the arithmetic unit power-down sequence, the
simulator saves the contents of the z register. During the power-up sequence, it restores the
contents of that register.
To examine the power-down sequence:
1. If the TimeA cursor is not already at 11,401,100 ps, select the opcode signal and click
Next Edge,
, until you locate the PDAU opcode, as shown in Figure 11-2 on
page 267.
Figure 11-2 Finding the PDAU Opcode
2. Expand pau[4:0], as shown in Figure 11-3 on page 268. This is the power control bus
for the arithmetic unit.
June 2013
267

Figure 11-3 Expanding the Arithmetic Unit Power Control Bus
Isolation
enabled
State
retention
save
Power
down
Power
up
State
retention
restore
Isolation
disabled
The following signals in this bus control power:
pau[2]
Power on/off
pau[1]
Save/restore state retention cells
pau[0]
Isolation on/off
3. At 13,400,000 ps, pau[0] is set to 1. This isolates the arithmetic unit power domain. The
value of zau changes to FFFFFFFF because the CPF file specifies that isolation is high.
The slanted lines (hash marks) behind the signal provide a visual indication that the value
is due to isolation being enabled.
4. At 14,200,000 ps, pau[1] is set to 1. This stores the value of the z register.
5. At 15,800,000 ps, pau[2] is set to 1. This turns off power to the arithmetic unit. The
value of z is set to x. The cross-hatch pattern indicates that the x value is due to power
shutdown.
The power-up sequence begins at 22,600,000 ps, when the PUAU opcode is issued, as
follows:
June 2013
268

1. At 23,800,000 ps, pau[2] is set to 0. This restores power to the arithmetic unit. Notice
that the value of z is still x, but that the cross-hatch pattern no longer appears. This
indicates that the x value is not due to power shutdown.
2. At 26,200,000 ps, pau[1] is set to 0. This restores z to the value it had before the unit
was powered down.
3. At 28,600,000 ps, pau[0] is set to 0. This removes the isolation of the arithmetic unit
power domain.
The power-down and power-up sequences for the logic unit (LU) are similar, but the values
of registers are not saved, as they are for the AU.
To examine the power-down sequence of the LU:
1. Select the opcode signal and click Next Edge,
at 33,800,000 ps.
, until you locate the PDLU opcode
2. Expand plu[4:0], as shown in Figure 11-4 on page 269. This is the power control bus
for the logic unit.
Figure 11-4 Expanding the Logic Unit Power Control Bus
Isolation
enabled
June 2013
State
retention
save
Power
down
269
Power
up
State
retention
restore
Isolation
disabled

The following signals in this bus control power:
plu[2]
Power on/off
plu[1]
Store/restore state retention cells

Note: This signal is ignored because state retention
is not specified for this power domain in the CPF file.
plu[0]
Isolation on/off
3. At 35,800,000 ps, plu[0] is set to 1. This isolates the logic unit power domain.
4. At 36,600,000 ps, plu[1] is set to 1. If state retention was specified in the CPF file, this
would store the value of the z register. However, because no state retention was
specified, this signal is ignored.
5. At 38,200,000 ps, plu[2] is set to 1. This turns off power to the logic unit. The value of
the z register is set to X.
The power-up sequence begins at 45,000,000 ps, when the PULU opcode is issued, as
follows:
1. At 46,200,000 ps, plu[2] is set to 0. This restores power to the logic unit.
2. At 48,600,000 ps, plu[1] is set to 0. Because no state retention has been defined in
the CFP file for the logic unit power domain, this signal is ignored.
3. At 51,000,000 ps, plu[0] is set to 0. This removes the isolation of the logic unit.
Other power-up and power-down sequences are exercised by the testbench.
To examine the waveforms for these sequences:
Select the opcode signal and click Next Edge

Nano exampleNpower-up opcodes.
June 2013
270
until you find the power-down or
12
Simulating a Gate-Level Design
Note: Low-power gate-level simulation is supported for Verilog only.
Simulating a Gate Netlist

At the RTL level, the RTL+CPF simulation creates the virtual logic required to perform the
state loss, port isolation, and state retention functions during the power-down process, and
superimposes this low-power virtual logic on the HDL design.
After simulating and debugging the RTL power-aware design, the RTL and CPF are
synthesized to generate a gate-level netlist.
RTL Source
CPF
Encounter RTL Compiler
Library
Gate-level
netlist
Test
vectors
Incisive simulator
Testbench
The gate-level netlist includes specially designed low-power cells that implement the
low-power logic, such as isolation and state retention save and restore. The simulation model
June 2013
271

of the low-power cells provides the state retention and port isolation behavior, and the
simulator must provide only the state loss behavior.
To simulate the netlist, the special low-power simulation cells must be recognized by the
simulator to enable accurate simulation of their functionality. For example, the internals of an
always-on cell should not be corrupted by the simulator. In addition, the virtual logic implicitly
modeled by the simulator must be disabled by using the appropriate simulator command-line
options.
Defining Low-Power Cells Instantiated in the Netlist

When simulating a gate-level netlist, always-on, state retention, and isolation cells must be
identified using the CPF define_xxx_cell commands described in the following sections.
You can use the * wildcard character, which matches any number of characters, or the ?
wildcard character, which matches a single character, when you define the cells. For example:
define_isolation_cell -cells { LPH_ISHEB_* } -enable EB
define_isolation_cell -cells { LPH_ISHEB_? } -enable EB
define_isolation_cell -cells { LP*_ISHEB_1 } -enable EB
define_isolation_cell -cells { LP?_ISHEB_1 } -enable EB
define_isolation_cell -cells { LP?_ISHEB_? } -enable EB
define_isolation_cell -cells { LP?_ISHEB_* } -enable EB
Defining Always-On Cells

Use the define_always_on_cell command to identify cells in the netlist that can remain
powered on even when the power domain they are instantiated in is powered down.
Syntax:
define_always_on_cell -cells cell_list
Instances of cells that must be always on are identified using the -cells option.
All internal wires and primitives of always-on cell instances are not corrupted when the power
domain is powered down. Nets whose drivers are contained in always-on cell instances are
not corrupted.
June 2013
272

Defining Isolation Cells
Use the define_isolation_cell command to identify instances of isolation cells in the
netlist. All isolation cell instances are treated as always-on cells, regardless of where they are
located (that is, regardless of their parent power domain).
Syntax:
define_isolation_cell -cells cell_list -enable pin [-always_on_pins pin_list]
Isolation cells are identified using the -cells option. The enable pin must be specified with
the -enable option.
Correct isolation cell simulation requires the identification of a power domain always-on
circuitry. Furthermore, the isolation cell enable pin and its drivers must be recognized as
always on, so as not to be corrupted. Use the -always_on_pins option to specify pins that
must be always-on.
Note: The pin specified with the -enable option is automatically recognized as an
always-on pin.
Defining State Retention Cells
Use the define_state_retention_cell command to identify instances of state
retention cells in the netlist.
Syntax:
define_state_retention_cell -cells cell_list
[-always_on_pins pin_list]
{-restore_function expr | -save_function expr
| -restore_function expr -save_function expr}
[-always_on_components component_list]
State retention cell instances are identified using the -cells option.
To model a retention cell with only one retention control, you can specify either
-save_function or -restore_function.
If you specify -save_function, the cell saves the current value when the expression
changes to true and the power is on. The cell restores the saved value when the power
is turned on.
If you specify -restore_function, the cell saves the current value when the
expression changes to false and the power is on. The cell restores the saved value
when the expression changes to true and the power is on.
June 2013
273

To model a retention cell with both save and restore control, both -save_function and
-restore_function must be specified. In this case, the cell saves the current value when
the save expression is true and the power is on. The cell restores the saved value when the
restore expression is true and the power is on.
The argument to -save_function and -restore_function is the pin name or the
inversion of the pin name. An expression containing only the pin name indicates an active
high polarity. An expression containing the inversion of the pin name indicates an active low
polarity.
Use the -always_on_pins option to specify the cell pins that must be always on. The save
and restore pins are implicitly recognized as always-on pins.
A state retention cell contains a main (master) component and a save (slave) component. The
main component should be corrupted when the power domain is shut off, while the save
component should not be corrupted. Use the -always_on_components option to identify
the registers, UDPs, or primitives within the state retention cell that remain on when the power
domain is powered down. This option specifies a list of component names in the simulation
model that are powered by the non-switchable power and ground pins. If the
-always_on_components option is not used, the simulator will corrupt both the slave and
the master components in a state retention cell that is inside a power-off domain.
Disabling the Implicit CPF Behavior

When low-power cells are instantiated in a gate-level netlist, you must disable the
corresponding implicit CPF behavior by using the appropriate command-line options.
-lps_iso_off
Turn off implicit isolation when isolation cells are instantiated in the design.
-lps_rtn_off
Turn off implicit state retention behavior when state retention cells are instantiated in the
design.
If you do not specify these options, the implicit CPF simulation as specified by the
corresponding create_isolation_rule or create_state_retention_rule
commands will mask the cell instance behavior.
Note: The -lps_iso_off and -lps_rtn_off options must be passed to the elaborator
(ncelab), not to the simulator (ncsim). If you are simulating in single-step invocation mode
with irun, do not include the -lps_simctrl_on option on the command line, as that option
will automatically pass -lps_iso_off and -lps_rtn_off to the simulator.
June 2013
274

A post-synthesis gate-level netlist typically instantiates logical models of state retention cells.
The correct cell save and restore behavior is accurately captured by the model. However,
because the physical VDD and VSS cell connections are not available, the state loss behavior
cannot be modeled by the state retention cell itself, and the simulator must still perform the
state loss operations. If the netlist instantiates physical models with power and ground
connections, the state loss behavior is modeled by the cell itself. In that case, you must use
the -lps_stl_off option to turn off the CPF implicit state loss behavior.
Example CPF File

In the example CPF file shown below, the define_* commands required for gate-level
simulation have been added to the CPF file that was used for the RTL simulation (see
Simulating an Example Design on page 261).
This CPF file contains only commands that affect simulation. Commands required by
Encounter RTL Compiler or by other tools are not included.
# nano.cpf
# Specify the CPF version.
set_cpf_version 1.0
# Specify the hierarchy delimiter character to be used in object names.
# Specify the name of the module to which the power information applies.
set_design core
# Define the power domains.
# Specify the instances that belong to the domain (-instances).
# Specify the condition when the domain is shut off (-shutoff_condition).
create_power_domain -name PDcore -default
create_power_domain -name PDlu \
-instances alu_inst/lui \
-shutoff_condition {pcu_inst/plu[2]}
June 2013
275

create_power_domain -name PDalu \
-instances alu_inst \
-shutoff_condition {pcu_inst/palu[2]}
# Define rules for replacing registers in a power domain with state retention
# registers.
# Specify the instances to be replaced with a state retention register (-instances).
# Specify the condition when the states of the registers need to be restored
# (-restore_edge).
# The condition when the states of the registers need to be saved is the inversion
# of the restore_edge expression.
create_state_retention_rule -name PDrf_sr \
-instances {rf_inst/rf[0] rf_inst/rf[1] rf_inst/rf[2]
rf_inst/rf[3] rf_inst/rf[4] rf_inst/rf[5]
rf_inst/rf[6] rf_inst/rf[7]} \
-restore_edge {!pcu_inst/prf[1]}
-instances {alu_inst/aui/z* } \
# Define the rules for adding isolation cells.
# Specify the pins that must be isolated in a power domain (-pins).
# Limit the pins to be isolated to output pins in the power domain (-from).
# Specify the condition when the pins should be isolated (-isolation_condition).
# Specify the isolation type (-isolation_output).
-from PDau \
create_isolation_rule -name PDlu_iso \
-from PDlu \
-pins alu_inst/lui/z* \
-isolation_condition {pcu_inst/plu[0]} \
June 2013
276

create_isolation_rule -name PDalu_iso \
-from PDalu \
-pins alu_inst/z* \
-isolation_condition {pcu_inst/palu[0]} \
create_isolation_rule -name PDrf_iso \
-from PDrf \
-pins
rf_inst/z* \
-isolation_condition {pcu_inst/prf[0]} \
# Specify cells that are always on
define_always_on_cell -cells "BUFGX2M BUFGX8M INVGX2M INVGX8M"
# Identify isolation cells in the netlist. Wildcards can be used in cell names.
define_isolation_cell -cells ISOLN* \
-enable EN
define_isolation_cell -cells "LVLHLEHX* LVLLHEHX* LVLHLELX*" \
-enable EN
# Identify state retention cells in the netlist. Wildcards can be used.
# Specify cell pins that are always on (-always_on_pins)
# Specify the restore pin, which enables the cell to restore the saved value after
exiting power shutoff mode (-restore_function).
# Identify the register(s) within the state retention cell that remains on when the
power domain is powered down (-always_on_components)
define_state_retention_cell -cells *DRFF* \
-always_on_pins {clear clk enable save restore} \
-restore_function restore \
-always_on_components {ad1_1 nd1_1 nd2_1 nd4_1 nd5_1
nd6_1 nd8_1 nd3_1 nd7_1 inv1_1 inv2_1 inv3}
end_design
Simulating a Mixed RTL/Gate Design with Instantiated

Primitive Cells
In a mixed gate/RTL simulation, the implicit state retention behavior should apply to the RTL
portions of the design, but must not apply to a gate netlist or to primitive cells instantiated in
the RTL code.
June 2013
277

To exclude primitive cells from the implicit state retention behavior, use the
-lps_cellrtn_off option (ncelab -lps_cellrtn_off or irun
-lps_cellrtn_off).
The -lps_cellrtn_off option specifies that all modules that are marked as cells must be
excluded from state retention. A module is tagged as a cell if:
The module is enclosed by the `celldefine/èndcelldefine directives.

`celldefine
module ram_behave (...);
...
reg tmp1, tmp2;
//Exclude these registers from state retention
...
endmodule
èndcelldefine
The module is in a file compiled with the -libcell option (ncvlog -libcell or irun
-libcell).
Note: If you are running the simulator in multi-step invocation mode, you must use the
-libcell option to tag modules not enclosed with `celldefine/èndcelldefine
as cells. However, if you are running the simulator in single-step invocation mode using
irun, the -libcell option is turned on by default to tag modules extracted from libraries
(from -y, -v, or ùselib) as cells. You can use the irun -nolibcell option to
override this behavior. Modules surrounded with `celldefine/èndcelldefine are
still treated as cell modules.
The -lps_cellrtn_off option eliminates state retention for all primitive cells. No checking
is performed to filter out special low-power cells. If the modules that are tagged as cells
include low-power cells that provide low-power functionality, this option must be used with
caution. State retention cells are in switchable domains, and their states will be corrupted
during power off. Isolation cells with a hold latch will also be corrupted. In order to allow the
cell's simulation model to correctly simulate the state retention behavior, you must specify
these cells in the CPF file with the define_state_retention_cell and
define_isolation_cell commands to identify always-on pins and the always-on
components, such as the save or hold latch, that must not be corrupted during power off.
define_state_retention_cell \
-cells {...} \
-always_on_components {...} \
-always_on_pins {...} \
-save_function {...} -restore_function {...}
June 2013
278
13
Debugging a Low-Power Simulation
(CPF)
The following features help you debug a low-power simulation.
See the book Debugging a Low-Power Simulation for information on debugging a

low-power simulation with SimVision.
See Tcl Command Enhancements for Low Power on page 279 for information on Tcl
commands with enhancements specifically for debugging low-power features.
See Debugging Infinite Loops on page 300 for information on debugging infinite loops
in low-power simulation.
Tcl Command Enhancements for Low Power

Several Tcl commands have been enhanced to help you debug a low-power simulation. This
section describes only those commands that have been enhanced specifically for low-power
simulation.
Describing Low-Power Information for the Design

Use the describe -power command to display low-power information for the design.
Syntax:
describe -power [-verbose]
This option displays information such as:
The low-power command-line options used in the simulation
The name of the CPF file(s) used in the simulation
The name and scope of each power domain
The name and scope of each isolation and state retention rule
June 2013
279

Debugging a Low-Power Simulation (CPF)
The names of control signals for power shutoff, state retention, and port isolation
Information on power modes and mode transitions
The information displayed with a describe -power command is the same as that printed
to the log file if you use the -lps_verbose 1 option when you invoke the elaborator or
simulator.
Include the -verbose option to display additional information. The information displayed with
a describe -power -verbose command is the same as that printed to the log file if you
use the -lps_verbose 3 option when you invoke the elaborator or simulator.
See the description of the -lps_verbose option for details on the information reported with
the different -lps_verbose levels
Displaying and Listing Low-Power Information

The power command can be used to display:
Information about a specified power domain (power -show -pdname)
Information about the power domain that contains a specified HDL object (power -show
-object)
A list of power domains within a specified power mode, along with their corresponding
nominal condition names and voltage values (power -show -pwr_mode).
A list of static and dynamic information about low power objects in the current scope
(power -find). See Finding and Listing Information About Low-Power Objects on
page 285 for more information.
Displaying Information about Power Domains and Power Modes

Syntax:
power [-show] {-object hdl_object [hdl_object ...]
| -pdname power_domain_name [power_domain_name ...]}
[-instances]
[-isolation_ports]
[-sr_variables]
[-state]
[-verbose]
power [-show] -pwr_mode power_mode_name [power_mode_name ...]
June 2013
280

The power command has two modifiers: -show and -find. Use power -show to display
Information about power domains and power modes.
You must specify:
A power mode name with the -pwr_mode option
A power domain name with the -pdname option.
An HDL object with the -object option. If you specify -object, information for the
parent power domain containing the object is displayed.
If you specify a power domain name or an HDL object, you can use the following options,
which provide additional details on the power domain:
-instancesDisplays the name of the power domain and the top instances in the
power domain. This is the default if no other option is specified.
-isolation_portsDisplays the isolation ports in the power domain, the isolation

status (enabled or not enabled), and the line number of the corresponding
create_isolation_rule command in the CPF file.
-sr_variablesDisplays the state retention registers and variables in the power

domain, their retention status (retained or not retained), and the line number of the
corresponding create_state_retention_rule command in the CPF file.
-stateDisplays the current state information of the power domain. This includes:
June 2013
The current state of the power domain. The state of the power domain is:
ON if the domain is in a nominal condition specified as on (create_nominal

condition -name name -voltage voltage -state on).
UNINITIALIZED when the simulation is being controlled by active state

conditions, and when the power domain is on but there are no active state
conditions enabled to specify the nominal condition to which the domain should
transition.
OFF if the domain is in a nominal condition specified as off

(create_nominal condition -name name -voltage voltage -state
off).
STANDBY if the domain is in a nominal condition specified as standby

(create_nominal condition -name name -voltage voltage -state
standby).
TRANSITIONING if the domain is currently in transition from one nominal

condition to another nominal condition.
281

The current nominal condition of the domain. The nominal condition of the power
domain can be:
The name of the nominal condition if the domain is in one of the nominal
conditions defined as on.
SHUTOFF if the power domain is in the OFF state.
UNINITIALIZED if the nominal condition is undefined. This can occur when the
simulation is being controlled by active state conditions, and when the power
domain is on but there are no active state conditions enabled to specify the
nominal condition to which the domain should transition.
The saved values of any retained variables of associated state retention rules.
-verboseAdds the following information to the output:
The CPF file and line number of the create_power_domain command for the
power domain
The names of any mapped domains for the specified power domain, and the CPF
files and line numbers where the mapped domains are defined
The names of any base domains of the specified power domain, and the CPF files
and line numbers where the base domains are defined
The name of the power mode control group for the specified power domain, and the
CPF file and line number where the control group is defined
The slope defined for the power domain. The slope is displayed as volts per time
unit, where the time unit is the time resolution of the simulation.
If both a minimum and maximum slope are defined, the output shows the
current, minimum, and maximum slope.
If only the maximum slope is defined, only the current slope is displayed.
If no slope is defined, the current slope is shown as infinite.
Examples
ncsim> scope dut
ncsim> run 502 ns
Ran until 502 NS + 0
ncsim> power -pdname PD_compress
;# Specify a power domain name. With no

;# options, -instances is the default.
Power Domain tb.dut.PD_compress

Top instances:
June 2013
282

tb.dut.inst_compress
ncsim>
ncsim> power -pdname PD_compress -verbose
;# -verbose option adds information

;# about base domains, power mode
;# control group, current slope

Power domain rule: file ./test_mvs.cpf line 31
Base Domains:
tb.dut.PD_default
Power domain rule: file ./test_mvs.cpf line 27
Control Group:
tb.dut (default)
Control group rule : file ./test_mvs.cpf line 9
Current Slope: 0.200000 volt/ns
Top instances:
ncsim>
ncsim> power -pdname PD_compress -instances -isolation_ports
Top instances:
Isolation ports:
tb.dut.inst_compress.out4
Status is: not enabled
Isolation rule: file ./test_mvs.cpf line 63
ncsim>
ncsim> power -pdname PD_compress -sr_variables -state
;#
;#
;#
;#
;#
-state option displays

current state of the
power domain, and saved
values of retention
variables.
Power Domain tb.dut.PD_compress is ON, nominal condition is NC_08, voltage =

0.800000
State Retention variables and registers:
June 2013
283

tb.dut.inst_compress.out4 (saved value = 1h0)
State Retention rule: file ./test_mvs.cpf line 69
Status is: retained
Status is: retained
Status is: retained
Status is: retained
ncsim>
ncsim> power -object TESTBENCH.inst.alu_inst.aui.br \
;# Specify an object name
> -sr_variables -isolation_ports -state

Power Domain TESTBENCH.inst.PDau is OFF
Isolation ports:
TESTBENCH.inst.alu_inst.aui.z
Status is: enabled
Isolation rule: file ./nano.cpf line 54
TESTBENCH.inst.alu_inst.aui.z (saved value = 32h0000124e)
State Retention rule: file ./nano.cpf line 44
Status is: retained
In the following example, the CPF file includes a create_power_mode command that
defines a power mode called M3. This power mode consists of power domain pdT at nominal
condition NC_12 (1.2 V), power domain pdA at nominal condition NC_12 (1.2 V), and power
domain pdB at nominal condition NC_08 (.8 V).
-default \
ncsim> power -pwr_mode M3
Power mode top.M3
Domains:
pdT
Nominal condition is (NC_12): voltage = 1.200000
pdA
pdB
June 2013
284

Finding and Listing Information About Low-Power Objects

Use power -find to locate and list all low-power objects of the specified type in the current
scope of the low-power design.
Syntax:
power -find [
[-domain |
-aon_domain |
-switchable_domain |
-default_domain |
-supply_net |
-supply_set |
-power_switch] |
[-object object_name
[-domain |
-isolation_control |
-sr_save_control |
-sr_restore_control]]]
[-pdname domain_name
[-in_port |
-out_port |
-isolation_rule]]
[-recursive]
[-newline]
[-quiet]
Objects found are listed on one line with object names separated by spaces. Each object
name returned is the full pathname for the object. Only one type option is allowed except for
in_port and out_port. Using both in_port and out_port returns all ports of all the
isolation rules associated with the domain.
-domainList all power domains.
-aon_domainList all always on domains. That is, domains without an explicit control
condition.
-switchable_domainList all switchable domains. That is, domains with an explicit

control condition.
June 2013
285

-default_domainList all default domains. That is, domains specified with the
-default option.
-power_switchList all power switches in the design.
-object object_nameList the low-power information associated with the HDL

object. Specify only one HDL object. Do not use wildcards.
-domainList the domain associated with the HDL object.
-isolation_controlList the isolation control expression associated with the

HDL object.
-sr_save_controlList the state retention save control expression associated

with the HDL object.
-sr_restore_controlList the state retention restore control expression

associated with the HDL object.
-pdname domain_name List isolation information associated with the power

domain.
-in_portList the isolated input ports in the specified power domain.
-out_portList the isolated output ports in the specified power domain.
-isolation_ruleList all isolation rules associated with the power domain.
-recursiveList all low power objects in the current scope and in the child scopes.
-newlineList each object on a separate line.
-quietDo not print warning messages when no low power objects are found for the
command.
Setting Breakpoints
You can set a breakpoint on:
A power domain (stop -pdname)
An isolation rule (stop -iso_rule)
A state retention rule (stop -sr_rule)
A power mode transition (stop -pwr_mode_transition)
June 2013
286

Setting a Breakpoint on a Power Domain
Use the stop -pdname option to set a breakpoint on a power domain.
ncsim> stop -pdname power_domain_name [power_domain_name ...]
If no options are specified, simulation stops when the power domain is powered down or
powered up.
You can specify multiple power domain names.
The -pdname option has several suboptions that let you create power domain breakpoints
that trigger under specific conditions:
-pd_offStop when the power domain turns off.
-pd_onStop when the power domain turns on.

This option stops the simulation when the specified power domain has transitioned to the
ON state or to the UNINITIALIZED state. The state of the power domain is
UNINITIALIZED when the simulation is being controlled by active state conditions, and
when the power domain is on but there are no active state conditions enabled to specify
the nominal condition to which the domain should transition.
-pd_standbyStop when the power enters standby mode.
-pd_transStop when the power domain transitions. The breakpoint triggers when the
specified power domain starts transitioning from one nominal condition to a different
nominal condition.
-isolationStop when any isolation rule associated with the power domain is enabled
or disabled.
-iso_disableStop when any isolation rule associated with the power domain is
disabled.
-iso_enableStop when any isolation rule associated with the power domain is
enabled.
-iso_corruptStop when the isolation device becomes corrupt. The isolation

device becomes corrupt when the isolation secondary domain goes down or when
the control signal goes to X or Z.
-retentionStop when any state retention rule associated with the power domain
saves or restores its variables.
June 2013
-sr_restoreStop when any state retention rule associated with the power
domain restores its variables.
287

-sr_saveStop when any state retention rule associated with the power domain
saves its variables.
-sr_corruptStop when the shadow register becomes corrupt. The shadow

register becomes corrupt when the state retention secondary domain goes down.
The shadow register also becomes corrupt when the simulation option
-lps_alt_srr is specified and a precondition violation occurs. See Modeling
State Retention with Save or Restore Preconditions on page 105 for more
information.
Example
In this example, the CPF file includes the following CPF commands. The
-shutoff_condition option in the create_power_domain command specifies the
power switch enable signal.
June 2013
288

-from PDau \
The following command sets a breakpoint on power domain PDau. Simulation stops when the
power switch enable signal is asserted and the power domain is powered down, or when it is
deasserted and power is restored to the domain.
ncsim> scope TESTBENCH.inst
ncsim> stop -pdname PDau
Created stop 1
ncsim> stop -show
1
Enabled
Power Domain TESTBENCH.inst.PDau
ncsim> run
15800 NS + 6 (stop 1: Power Domain TESTBENCH.inst.PDau is OFF)
TESTBENCH.inst.PDau ./nano.cpf line 21
ncsim> value pcu_inst.pau[2]
1h1
ncsim> run
23800 NS + 6 (stop 1: Power Domain TESTBENCH.inst.PDau is ON)
1h0
ncsim>
The following command creates a breakpoint on power domain PDau. The -pd_off option
specifies that simulation will stop when the domain powers down.
ncsim> stop -pdname PDau -pd_off
Created stop 1
ncsim> run
ncsim> run
June 2013
289

The following command creates a breakpoint on power domain PDau. The -isolation
-iso_enable option specifies that simulation will stop when the isolation rule associated
with the domain PDau (PDau_iso) is enabled.
ncsim> stop -pdname PDau -isolation -iso_enable
Created stop 1
ncsim> stop -show
1
Enabled
Power Domain Isolation TESTBENCH.inst.PDau_iso (enable)
ncsim> run
13400 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso: is ENABLED)
TESTBENCH.inst.PDau_iso ./nano.cpf line 56
The following stop command creates a breakpoint on power domain PDau. The
-retention option specifies that simulation will stop when the state retention rule
associated with the domain PDau (PDau_sr) either saves or restores its variables. A
subsequent stop command includes the -retention -sr_save option to specify that
simulation will stop only when the state retention rule saves its variables.
ncsim> scope inst
ncsim> stop -name PDau_ret -pdname PDau -retention
Created stop PDau_ret
ncsim> run
14200 NS + 6 (stop PDau_ret: State Retention Rule TESTBENCH.inst.PDau_sr)
TESTBENCH.inst.PDau_sr ./nano.cpf line 46
1h1
ncsim> run
26200 NS + 6 (stop PDau_ret: State Retention Rule TESTBENCH.inst.PDau_sr)
1h0
ncsim> stop -disable PDau_ret
ncsim> stop -name PDau_ret_save -pdname PDau -retention -sr_save
Created stop PDau_ret_save
ncsim> run
59 US + 6 (stop PDau_ret_save: State Retention Rule TESTBENCH.inst.PDau_sr)
1h1
In a power mode simulation, you can use the -pd_trans option to stop the simulation when
the specified power domain starts to transition from one nominal condition to a different
nominal condition. For example:
June 2013
290

ncsim> stop -pdname pdA -pd_trans
Created stop 1
ncsim> stop -show
1
Enabled
Power Domain top.pdA (transitional)
ncsim> run
0 clk=0 data=000000 ndata=111111
...
95 clk=1 data=001010 ndata=110101
At simulation time 99 NS: Power domain pdT has transitioned to nominal condition
NC_08
condition NC_08
Power domain pdA has started transitioning to nominal
99 NS + 1 (stop 1: Power Mode Transition top.mt1)

top.mt1 ./dut.cpf line 62
ncsim>
The following command includes the -pd_standby option, which stops the simulation when
power domain pdB enters standby mode
ncsim> stop -pdname pdB -pd_standby
Created stop 1
ncsim> run
...
...
NC_STANDBY

814 NS + 1 (stop 1: Power Domain top.pdB is in STANDBY)

top.pdB ./dut.cpf line 32
ncsim>
Setting a Breakpoint on an Isolation Rule

Use the stop -iso_rule command to stop the simulation when the specified isolation rule
becomes enabled or disabled.
You can specify multiple isolation rule names.
The -iso_rule option has three suboptions:
-iso_disableStop only when the isolation rule becomes disabled.
June 2013
291

-iso_enableStop only when the isolation rule becomes enabled.
-iso_corruptStop when the isolation device becomes corrupt. The isolation device
becomes corrupt when the isolation secondary domain goes down or when the control
signal goes to X or Z.
The following command creates a breakpoint on the isolation rule called PDau_iso.
Simulation stops when isolation is either enabled or disabled.
ncsim> scope inst
ncsim> stop -iso_rule PDau_iso
Created stop 1
ncsim> stop -show
1
Enabled
Isolation Rule TESTBENCH.inst.PDau_iso
ncsim> run
13400 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso is ENABLED)
ncsim> run
28600 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso is DISABLED)
Setting a Breakpoint on a State Retention Rule

Use the stop -sr_rule command to stop the simulation when the specified state retention
rule saves or restores its variables.
You can specify multiple state retention rule names.
The -sr_rule option has three suboptions:
-sr_restoreStop only when the state retention rule restores its variables.
-sr_saveStop only when the state retention rule saves its variables.
-sr_corruptStop when the shadow register becomes corrupt. The shadow register
becomes corrupt when the state retention secondary domain goes down. The shadow
register also becomes corrupt when the simulation option -lps_alt_srr is specified
and a precondition violation occurs. See Modeling State Retention with Save or Restore
Preconditions on page 105 for more information.
The following command creates a breakpoint on the state retention rule PDau_sr. The
-sr_save option is included to specify that simulation should stop when the rule saves its
variables.
ncsim> scope inst
ncsim> stop -sr_rule PDau_sr -sr_save
June 2013
292

Created stop 1
ncsim> stop -show
1
Enabled
State Retention Rule TESTBENCH.inst.PDau_sr (save)
ncsim> run
14200 NS + 6 (stop 1: State Retention Rule TESTBENCH.inst.PDau_sr)
TESTBENCH.inst.PDau_sr (saved) ./nano.cpf line 44
Setting a Breakpoint on a Power Mode Transition

Use the stop -pwr_mode_transition command to stop the simulation when the
specified power mode transition starts and ends.
stop -pwr_mode_transition mode_transition_name [mode_transition_name ...]
Example
In this example, the CPF file defines a power mode transition called mt1 with the following
create_mode_transition command:
-from M3 -to M1 \
-start_condition pmc.mte[1]
Power modes M3 and M1 are defined with the following two create_power_mode
commands:
-default \
-domain_conditions {pdT@NC_08 pdA@NC_08}
The following stop command creates a breakpoint that stops the simulation when power
mode transition mt1 starts and ends.
ncsim> stop -pwr_mode_transition mt1
Created stop 1
ncsim> stop -show
1
Enabled
Power Mode Transition top.mt1
ncsim> run
0 clk=0 data=000000 ndata=111111
5 clk=1 data=000001 ndata=111110
...
...
June 2013
293

95 clk=1 data=001010 ndata=110101

ncsim> run

condition NC_08

NC_08
Power domain pdT has transitioned to nominal condition

condition NC_08
Power domain pdA has finished transitioning to nominal


ncsim>
Displaying the Saved Value of a State Retention Variable

You can display the saved value of a state retention variable:
By using the Tcl value -saved command.

For example, if SR1 is a state retention register in the current scope, the following
command prints the current value of the variable, which will be x if the domain is powered
down:
ncsim> value SR1
The following command returns the saved value.

ncsim> value -saved SR1
By using a probe -sr_save command. This option probes both the value of the state
retention variables and the saved value of the variables.
You can specify a scope or variable names.
probe -create scope_name -shm -sr_save
probe -create variable_name -shm -sr_save
June 2013
294

If you specify a scope, you can use -all -memories (for Verilog) or -all
-variables (for VHDL).
Note: In the current release, using the -depth option with -sr_save is not supported.
For example, the following command is not supported:
probe -create -depth all -all -sr_save
The name of the saved variable is variable_name_sr. The value of this variable can
be viewed in SimVision.
Example
In this example, the CPF create_power_domain command creates a power domain called
PDau, which contains instance alu_inst/aui. The create_state_retention_rule
command specifies that register alu_inst.aui.z is to be replaced with a state retention
cell. The current value of the register is saved when the save_edge expression changes from
false to true. The saved value is restored when the restore_edge condition changes from
false to true.
-save_edge {pcu_inst/pau[1]} \
ncsim>
;# Set break on state retention save enable
ncsim> stop -object inst.pcu_inst.pau[1]
Created stop 1
ncsim> stop -pdname PDau
;# Set break on power domain PDau
Created stop 2
ncsim> run
;# Run until save enable is active
100 PS + 3 (stop 1: TESTBENCH.inst.pcu_inst.pau[1] = 0)

ncsim> run
14200 NS + 4 (stop 1: TESTBENCH.inst.pcu_inst.pau[1] = 1)
ncsim> run 1 ps
Ran until 14200001 PS + 0
ncsim> power -pdname PDau -sr_variables
;# See if variable is retained
Power domain is (PDau)

June 2013
295

TESTBENCH.inst.alu_inst.aui.z
State Retention rule: file ./nano.cpf line 44
Status is: retained
ncsim> value inst.alu_inst.aui.z
;# Display current value
32h0000124e
ncsim> run
;# Run until power domain is shut off
15800 NS + 6 (stop 2: Power Domain PDau)

ncsim> value inst.alu_inst.aui.z
;# Display current value
32hxxxxxxxx
ncsim> value -saved inst.alu_inst.aui.z
;# Display saved value
32h0000124e
ncsim>
Probing Control Expressions

Use the -power option on the probe command to probe all low-power simulation control
expressions to the SHM database.
Only SHM probes are supported. VCD, EVCD, and screen probes (using -screen) are not
supported. Including the -shm option is not required.
Example
In the following example, the probe -power command probes all of the control expressions
shown in Table 11-1 on page 262.
ncsim> database -open -shm -into waves.shm waves -default
Created default SHM database waves
ncsim> probe -power -database waves
Created probe 1
ncsim> probe -show 1
1
Enabled
TESTBENCH.inst.pcu_inst.pau[2] (database: waves) -shm

TESTBENCH.inst.pcu_inst.plu[2]
TESTBENCH.inst.pcu_inst.palu[2]
TESTBENCH.inst.pcu_inst.prf[2]
TESTBENCH.inst.pcu_inst.pau[1]
TESTBENCH.inst.pcu_inst.pau[0]
TESTBENCH.inst.pcu_inst.plu[0]
TESTBENCH.inst.pcu_inst.palu[0]
June 2013
296

Number of objects probed : 10
ncsim>
Probing Power Mode Information

Use the -pwr_mode option on the probe command to enable the probing of power mode
information for all power domains.
Only SHM probes are supported. VCD, EVCD, and screen probes (using -screen) are not
supported. Including the -shm option is not required.
Note: The only other probe command option that can be used with -pwr_mode is the
-name option. You cannot specify other objects with the probe -pwr_mode command.
The following information is saved in the SHM database for each power domain:
The power domain name
The name of the power mode the domain is currently in
The state of the power domain (ON, OFF, TRANSITIONING, STANDBY,

UNINITIALIZED)
The nominal condition name and current voltage of the power domain
Example
In the following example, the probe -pwr_mode command probes power mode information
for the three power domains in the design.
ncsim> database -open -shm -into waves.shm waves -default
Created default SHM database waves
ncsim> probe -create -pwr_mode -database waves
Created probe 1
ncsim> probe -show
1
Enabled
top.pdT (database: waves) -shm

top.pdA
top.pdB
Number of objects probed : 3
ncsim>
June 2013
297

Displaying the Drivers of an Object

The drivers command shows the power drivers, with the corresponding CPF file and line
number of the associated CPF command.
In the example design, there are two power domains, defined as follows:
The following create_isolation_rule command is used to illustrate the output of the

drivers command:
-to PDrf \
ncsim> ;# Run until isolation is enabled and power is on

Created stop 1
ncsim> run
100 PS + 3 (stop 1: TESTBENCH.inst.pcu_inst.pau[0] = 0)
ncsim> run
13400 NS + 4 (stop 1: TESTBENCH.inst.pcu_inst.pau[0] = 1)
;# Isolation enabled
ncsim> run 1 ps
Ran until 13400001 PS + 0
ncsim> value inst.alu_inst.aui.a
;# Display value of input a
32h00000dfe
ncsim> drivers inst.alu_inst.aui.a
;# Display drivers of input a
inst.alu_inst.aui.a...input net logic [31:0]

a[31] (wire/tri) = St0
St0 <- low power driver, power domain rule (power domain is on)
[File:./nano.cpf, Line:16]
St0 <- (TESTBENCH.inst.rf_inst) assign a = rf[ra]
...
...
a[0] (wire/tri) = St0
June 2013
298

St0 <- low power driver, power domain rule (power domain is on)
[File:./nano.cpf, Line:16]
St0 <- (TESTBENCH.inst.rf_inst) assign a = rf[ra]
ncsim> value inst.rf_inst.result
;# Display value of input result of rf_inst
32h00000000
;# Value is 0 because of isolation rule.
June 2013
299

ncsim> drivers inst.rf_inst.result
;# Display drivers of input result
inst.rf_inst.result...input net logic [31:0]

result[31] (wire/tri) = St0
St0 <- low power driver, isolation rule (is enabled) [File:./nano.cpf,
Line:60]
St0 <- (TESTBENCH.inst) assign result = (opcode == LOAD) ? dinr : alu
...
...
result[0] (wire/tri) = St0
St0 <- low power driver, isolation rule (is enabled) [File:./nano.cpf,
Line:60]
St0 <- (TESTBENCH.inst) assign result = (opcode == LOAD) ? dinr : alu
ncsim> ;# Run until PDau powers down
Created stop 2
ncsim> run
Debugging Infinite Loops

Debugging of an infinite loop in a low-power simulation can sometimes be difficult. There are
a number of reasons why a simulation can run forever in low power, including the following
common cases:
You have the following clock generator (or PLL):

always #(DELAY) clk = !clk;
If this code is in a switchable domain, and the domain powers down, DELAY gets set to
0. This causes an infinite loop.
You can use the CPF set_sim_control -action disable_corruption
command to disable the corruption of integers or reals. If you have defined DELAY to be
a real or integer data type, it will never be corrupted, and the clock generator will not get
into an infinite loop. However, clk will still be corrupted (since it will be defined to be a
reg data type). If you don't want the clock to be corrupted, put this code in an always-on
domain.
The shutoff signal of a domain is corrupted by logic in that domain. Obviously, this is a
real design error, but the simulator might hang because the signal goes from 1 - X - 1 X, and so on. If you use the -lps_verify option, the simulator will automatically fire an
assertion to detect that the shutoff condition is undefined.
A signal going to another block is part of a request/acknowledge handshake, and the

signal has not been isolated correctly. Check all isolations on signals leaving this domain,
June 2013
300

and going to this domain, to make sure that they are both the correct polarity, and are
actually enabled before shutting off the domain.
June 2013
301

June 2013
302
14
Advanced Low-Power Verification
Features
The simulator includes the following advanced low-power verification features:
Automatic generation of assertions that check properties of control signals and their
correct sequencing. See Generating Assertions to Verify Power Control Signals on
page 303.
Automatic generation of a SystemVerilog coverage model. See Generating a Coverage

Model on page 312.
Both features are enabled by the elaborator -lps_verify option (ncelab -lps_verify
or irun -lps_verify).
In the current release, the automatic generation of assertions and a coverage model is
supported for pure Verilog, pure VHDL, and mixed Verilog/VHDL designs.
Note: In the current release, the -lps_verify option turns on both features. You cannot
enable the automatic assertions or the coverage model separately.
You can also use the elaborator -lps_vplan option (ncelab -lps_vplan or irun
-lps_vplan) to generate a verification plan (vPlan) for power coverage for use by
vManager. See Generating a Verification Plan for Power Coverage on page 314.
Generating Assertions to Verify Power Control Signals

Accurate low-power simulation behavior depends on the correct transition sequence of the
power control signals. While a design may not require port isolation or state retention, and
can impose specific requirements for control signals, there are some general rules that are
essential for correct operation.
Figure 14-1 on page 304 shows the correct transition sequence of control signals when one
state retention control signal is specified.
June 2013
303

Advanced Low-Power Verification Features
Figure 14-1 Transition Sequence with One Retain Control Signal
Isolation enabled
State retention
enabled. Values
are saved.
State retention
disabled. Values
are restored.
Isolation disabled
Isolation
State retain
Power switch
enable
Power up
Power down
Figure 14-2 on page 304 shows the correct transition sequence of control signals when
separate state retain and state restore control signals are specified.
Figure 14-2 Transition Sequence with Separate Save and Restore Control Signals
Isolation disabled
Isolation enabled
Restore state
Save state
Isolation
Save
Restore
Power switch
enable
Power down
June 2013
Power up
304

Use the elaborator -lps_verify command-line option to automatically generate assertions
that verify the power control signals associated with power shutoff, isolation, and state
retention save and restore conditions. When you include -lps_verify, the simulator
generates assertions that check properties of the control signals and correct sequencing of
the signals.
Note: If isolation or state retention cells are instantiated in the design, the cells implement
the low-power isolation and state retention save and restore behavior. In these situations, the
virtual isolation and state retention behavior specified by rules in the CPF file must be
disabled with the -lps_iso_off or -lps_rtn_off options. These options will disable the
automatic generation of assertions related to isolation and state retention unless the
-lps_simctrl_on option is used during elaboration. If you are running the simulation in
single-step mode with irun, include the -lps_simctrl_on option on the command line with
-lps_iso_off/-lps_rtn_off. If you are running in multi-step mode, run ncelab with
-lps_simctrl_on, and then run ncsim with -lps_iso_off/-lps_rtn_off.
Assertion checking begins when the low-power simulation begins: at time 0 (the default) or at
the time specified with the -lps_stime command-line option. Because events generated
during initialization may cause invalid assertion failures, use -lps_stime with
-lps_verify to filter out events generated during initialization.
The assertions are derived from the CPF file. Assertions are generated for each defined
switchable power domain, and the assertions generated for each domain depends on the
corresponding CPF file content. For example, if no state retention rules are specified for a
domain, no assertions involving save and restore signals are generated for that domain.
Note: Assertions are generated only for power control signals in the power domain. They are
not generated for signals that are associated with the create_assertion_control
command.
All assertion names begin with the following:
LPV_DMN_domain_name_
For example, the CPF file for the example used in Chapter 11, Simulating an RTL-Level
Design, defines a power domain called PDau with a state retention rule and isolation rule as
follows:
-base_domains {PDalu}
June 2013
305


-from PDau \
The assertions generated for domain PDau check the control signals in the CPF file for this
domain:
Power shutoff control pau[2]
State retention restore control !pau[1]
State retention save control !(!pau[1])
Isolation control pau[0]
All assertion names generated for power domain PDau begin with:
LPV_DMN_PDau_
For example:
LPV_DMN_PDau_SHUTOFF_SIGNAL_NOT_X
Automatically-Generated Assertions
The following properties and sequence checks on the low-power control expressions are
performed automatically during simulation:
Assertions to Verify That Control Signals Are Not Undefined
A control signal cannot be undefined.
Note: Initial X values at the start of simulation do not result in assertion failures.
The following assertions are generated to verify that control signals are never X:
LPV_DMN_DomainName_SHUTOFF_SIGNAL_NOT_X
Power shutoff control signal cannot be X.
LPV_DMN_DomainName_ISOLATION_SIGNAL_NOT_X
Isolation control signal cannot be X.
June 2013
306

LPV_DMN_DomainName_SAVE_SIGNAL_NOT_X
State retention save control signal cannot be X.
LPV_DMN_DomainName_RESTORE_SIGNAL_NOT_X
State retention restore control signal cannot be X.
Assertions to Verify Correct Sequence of Isolation and Power Shutoff Controls

Assertions are generated to verify the correct sequence of isolation enable/disable and power
shutdown controls.
To determine the correct sequencing of the control signals, the simulator uses the value of
the create_isolation_rule -isolation_target option to associate the isolation
rule with a power domain.
-isolation_target from indicates that the rule applies when the power domain of
the drivers of the specified pins is switched off. This option associates the isolation rule
with the domain of the drivers. This is the default.
-isolation_target to indicates that the rule applies when the power domain of the
loads of the specified pins is switched off. This option associates the isolation rule with
the domain of the loads.
In most cases, the isolation rule should be associated with the driving domain. For example,
consider the following two power domains, both of which are switchable:
PD1
PD2
The following rule specifies that the inputs to domain PD2 are to be isolated when PD1 is shut
off:
-to PD2 \
-isolation_condition {iso_en}
This rule is associated with domain PD1. The generated assertions will check the sequencing
of iso_en and the shutdown condition for PD1.
If isolation must be enabled when the domain of the loads is powered off, you must include
the -isolation_target to option.
June 2013
307

-to PD2 \
-isolation_condition {iso_en}
In this case, the generated assertions will check the sequencing of iso_en and the shutdown
condition for PD2.
The following assertions are generated to verify the correct sequence of isolation
enable/disable and power shutdown controls:
LPV_DMN_DomainName_ALWAYS_ISOLATED_WHEN_SHUTOFF
Isolation must be enabled before power shutoff.
If a power domain has multiple isolation rules, any isolation enable must be followed by
all other isolation enables. Isolation enable is calculated as the logical and of all isolation
rule enable conditions.
LPV_DMN_DomainName_SHUTOFF_FOLLOWS_ISOLATE
Isolation enable must be followed by power down.
LPV_DMN_DomainName_ISOLATE_OFF_FOLLOWS_PWR_UP
Isolation disable must follow power up.
LPV_DMN_DomainName_NO_ISOLATION_TOGGLE_number
Isolation cannot remain enabled for multiple shutoffs. This assertion fires in the following
situation:
Isolation
Shutoff
This assertion is generated for each isolation rule that has an isolation control specified
using -isolation_condition. The assertion is not generated for rules using the
-no_condition option.
If a power domain has multiple isolation rules, multiple assertions are generated. To
uniquely identify each assertion, a number is appended to the assertion name. For
example:
June 2013
308

LPV_DMN_DomainName_NO_ISOLATION_TOGGLE_1
LPV_DMN_DomainName_NO_ISOLATION_TOGGLE_2
Note: A power domain is shut down and corrupted if its shutdown control is enabled. A power
domain is also corrupted if its shutdown condition is X/U/Z. While a transition to 1 or 0 shuts
down (or powers up) a domain, an X/U/Z value on the shutdown control signal means that the
state of the domain is unknown. A transition to X/U/Z is not always treated the same as a
transition to 1 or 0. In some cases, assertions may be fired if the shutoff control is X/U/Z that
would not be fired when the shutoff control transitions to 1 or 0.
Limitations
In the current release, assertions are not generated:
When a domain gets powered off because its base domain has been powered off.
If driver/load analysis fails to identify any port for isolation, but isolation placement has
been forced (using the -force option).
Assertions to Verify Correct Sequence of State Retention Save and Restore and Power
Shutoff Controls
The following assertions are generated to verify the correct sequence of save, restore, and
power shutdown controls:
LPV_DMN_DomainName_NO_SAVE_WHILE_SHUTOFF
State retention save cannot occur during power shutoff. The save edge or save level
must occur when the corresponding domain is powered up. If a power domain has
multiple state retention rules, all save edges or pulses must occur before power down.
LPV_DMN_DomainName_NO_RESTORE_WHILE_SHUTOFF
State retention restore cannot occur during power shutoff. The restore edge or restore
level must occur when the corresponding domain is powered up. If a power domain has
multiple state retention rules, all restore edges or pulses must occur after power up.
LPV_DMN_DomainName_SHUTOFF_FOLLOWS_SAVE
State retention save edge/pulse must be followed by a power shutoff.
LPV_DMN_DomainName_ALWAYS_SAVE_BEFORE_RESTORE
State retention restore must follow a state retention save. This assertion is applicable
when state retention is modeled with separate save and restore signals.
June 2013
309

LPV_DMN_DomainName_NO_RESTORE_TOGGLE_number
The restore signal cannot remain high for multiple saves. This assertion fires in the
following situation:
Assertion
fails here.
Restore
Save
This assertion is generated for each state retention rule.

If a power domain has multiple state retention rules, multiple assertions are generated.
To uniquely identify each assertion, a number is appended to the assertion name. For
example:
LPV_DMN_DomainName_NO_RESTORE_TOGGLE_1
LPV_DMN_DomainName_NO_RESTORE_TOGGLE_2
LPV_DMN_DomainName_NO_MULTIPLE_SAVE
Multiple state retention saves are not allowed before power shutoff or before state
retention restore.
LPV_DMN_DomainName_SAVE_AND_RESTORE_NOT_ACTIVE_number
Save and restore levels cannot be true at the same time.
This assertion is generated for state retention rules that have level-sensitive control using
-save_level and -restore_level.
If there are multiple state retention rules in this category within a power domain, multiple
assertions are generated. To uniquely identify each assertion, a number is appended to
the assertion name. For example:
LPV_DMN_DomainName_SAVE_AND_RESTORE_NOT_ACTIVE_1
LPV_DMN_DomainName_SAVE_AND_RESTORE_NOT_ACTIVE_2
The assertion failure message displays the CPF file name and the line number of the
corresponding state retention rule.
LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_number
Save precondition cannot become false in the save region.
This assertion is generated for state retention rules that have a save precondition
specified. The assertion fires if the save precondition becomes false within a save region.
June 2013
For an edge-sensitive retention rule, the save region is the region from when the
save edge expression becomes true until the power shutdown.
310

For a level-sensitive retention rule, the save region is the region between when the
save level expression becomes true until it becomes false.
LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_1
LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_2
LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_number
Restore precondition cannot become false in the restore region.
This assertion is generated for state retention rules that have a restore precondition
specified. The assertion fires if the restore precondition becomes false within a restore
region.
For an edge-sensitive retention rule, the restore region is the region between power
up and the restore edge expression becoming true.
For a level-sensitive retention rule, the restore region is the region between when
the restore level expression becomes true until it becomes false.
LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_1
LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_2
Assertions to Verify Power Mode and Mode Transition Behavior
The following assertions are generated to verify the correct behavior of power modes and
power mode transitions:
LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_number
Active state condition signal cannot be X.
This assertion is generated for each active state condition defined for a power domain.
June 2013
311

If a power domain has multiple active state conditions defined, multiple assertions are
generated. To uniquely identify each assertion, a number is appended to the assertion
name. For example:
LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_1
LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_2
LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_number
Active state control conditions must be one-hot. This assertion fires when the one-hot
property is violated.
This assertion is generated for active state conditions defined for a power domain. A
single assertion is generated for each power domain.
To uniquely identify each assertion for power domains with the same name, a number is
appended to the assertion label. For example:
LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_1
LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_2
LPV_PMODE_ModeName_START_SIGNAL_NOT_X
A power mode transition start condition expression cannot be undefined.
This assertion is fired when the start condition expression of a power mode transition
goes to a value of X.
This assertion is generated for each power mode transition rule with a
-start_condition option specified, and when the -lps_mvs and -lps_pmode
options are used.
LPV_PMODE_ModeName_END_SIGNAL_NOT_X
A power mode transition end condition expression cannot be undefined.
This assertion is fired when the end condition expression of a power mode transition
goes to a value of X.
This assertion is generated for each power mode transition rule with a
-end_condition option specified, and when the -lps_mvs and -lps_pmode options
are used.
Generating a Coverage Model

CPF specifies detailed information about the signals used to control each power domain, and
it is important, as part of a planning-driven verification solution, to analyze coverage data of
June 2013
312

the control signals and power mode transitions to ensure that they have been fully exercised
and to detect any illegal conditions.
Using the -lps_verify command-line option automatically generates a SystemVerilog
coverage model for the following low-power data:
Power domain shutoff conditions from create_power_domain commands
Isolation conditions from create_isolation_rule commands
Save/Restore conditions and pre-conditions from create_state_retention_rule

commands
Active state conditions specified in create_power_domain commands
Power modes specified with create_power_mode commands
Power mode transitions specified with create_mode_transition commands
Power domain states

Coverage is generated for the possible states of the power domain. The possible states
of the power domain are:
ON - will always be in the coverage bin.
OFF - will be in the coverage bin only if the domain has a shutoff control signal or if
the domain can be in a nominal condition that has the state off.
STANDBY - will be in the coverage bin only if one of the power domains active states
has a standby state. If the power domain does not have active states defined,
STANDBY will only be in the coverage bin if at least one of the nominal conditions
has a standby state.
TRANSITION - will be in the coverage bin only if the power domain has a transition
slope defined.
Power domain nominal conditions

Coverage is generated for the possible nominal conditions of the power domain. The
possible nominal condition values are:
Nominal condition names that the power domain can be in.
SHUTOFF. This will be used only if the power domain can transition to a nominal
condition with state specified as off.
Note: If you use the -lps_pmcheck_only option to specify that domain-level controls
(active state conditions specified with create_power_domain
-active_state_conditions) drive the power domain nominal condition transitions,
June 2013
313

only nominal conditions defined in the create_power_domain
-active_state_conditions command are used.
The control expressions are sampled whenever they change value from 1 -> 0 or 0 -> 1. Use
the -lps_stime command-line option with -lps_verify to disable the collection of
low-power coverage data until the specified time has been reached.
You can generate additional coverage using the Incisive Comprehensive Coverage (ICC)
flow. ICC instruments the coverage and writes a coverage database that includes the
generated coverage for the low-power control expressions. See the ICC User Guide for
details.
The coverage data, including the low-power data, is stored to a database which, by default,
is written to the directory cov_work/design/test. You can then analyze the data using
the coverage reporting tool, ICCR. See the ICC Analysis User Guide for details on using
ICCR.
The low-power coverage is stored in the ICC database as a top-level module,
ALPV_TOP_COVERAGE_MODEL.
The generated coverage model has a structure similar to the following:
ALPV_TOP_COVERAGE_MODEL
domains
DOMAIN_<domain_name>
active_states
shutoff
state_retention
<rule_name>_restore_condition
<rule_name>_restore_pre_condition
<rule_name>_save_condition
<rule_name>_save_pre_condition
isolation
<rule_name>_isolation_condition
power_mode_control_group
<power_mode_control_group_name>
pwr_mode
pmode_trans
Generating a Verification Plan for Power Coverage

You can generate a verification plan (vPlan) for power coverage for use by vManager with the
elaborator -lps_vplan option (ncelab -lps_vplan or irun -lps_vplan). The
June 2013
314

generated vPlan provides a more organized, easier to read, and better documented view of
the automated coverage data generated by the simulator. The vPlan can be included in the
overall verification plan.
vPlan generation is supported for both Verilog and VHDL.
The -lps_vplan option generates the vPlan. The coverage data is generated by the
-lps_verify option. The -lps_vplan option implies -lps_verify, or you can include
both options on the command line. The following examples include only -lps_vplan.
% ncelab -lps_cpf top.cpf -lps_vplan vplan_filename [other_options] top_module
% irun -lps_cpf top.cpf -lps_vplan vplan_filename [other_options] source_files
The vPlan is generated in the current directory. Include an absolute or relative path with the
vplan_filename to write the vPlan to a different location. For example:
-lps_vplan ./power_vplan/generated.vplan
Note: If the simulation run is not launched from vManager, you must use the
-write_metrics option when you invoke the simulator (ncsim -write_metrics or
irun -write_metrics). This option enables the simulator to dump information from each
run into a separate, single-run verification session output file (VSOF) that can be loaded into
Enterprise Manager for analysis. For example:
% irun -lps_cpf top.cpf -write_metrics -lps_vplan generated.vplan \
[other_options] source_files
Or:
% ncvlog [options] verilog_source_files
% ncvhdl [options] vhdl_source_files
% ncelab -lps_cpf top.cpf -lps_vplan generated.vplan [other_options] top_module
% ncsim -write_metrics [other_options] snapshot_name
vPlan Content
The vPlan for power coverage is displayed in two sections:
Power Mode Groups

Expanding this section displays the top-level scope in the design, and expanding this
scope displays the power mode control groups in that scope and subscopes. Expanding
a power mode control group displays two sections:
Power Modes
Power Mode Transitions
June 2013
315

For example:
1.1 - Power Mode Groups
1.1.1 - Scope: top
1.1.1.1 - pmcg1
1.1.1.1.1 - Power Modes
1.1.1.1.2 - Power Mode Transitions
1.1.1.2 - Scope: f1
1.1.1.2.1 - pmcg2
1.1.1.2.1.1 - Power Modes
1.1.1.2.1.2 - Power Mode Transitions
...
...
Power Domains
Expanding this section displays the top-level scope in the design, and expanding this
scope displays the power domains in that scope and subscopes. Expanding a power
domain displays the following sections if they have been defined for that power domain:
Shutoff Condition
States
Nominal Conditions
Active State Conditions
Isolation Rules
State Retention Rules
Low-Power Control Checks
For example:
1.2 Power Domains
1.2.1 - Scope: top
1.2.1.1 - default_pd
1.2.1.2 - fifo0_pd
1.2.1.2.1 - Shutoff Condition
1.2.1.2.2 - States
1.2.1.2.3 - Nominal Conditions
1.2.1.2.3.1 - Error Condition
1.2.1.2.4 - Active State Conditions
1.2.1.2.5 - Low Power Control Checks
1.2.1.3 - fifo_pd
1.2.1.3.1 - Shutoff Condition
1.2.1.3.2 - States
1.2.1.3.3 - Nominal Conditions
June 2013
316

1.2.1.3.3.1 - Error Condition
1.2.1.3.4 - Active State Conditions
1.2.1.3.5 - Isolation Rules
1.2.1.3.6 - State Retention Rules
1.2.1.3.7 - Low Power Control Checks
1.2.1.4 - Scope: f1
1.2.1.4.1 - fifo1_pd
...
...
vPlan Parameters
The following parameters are included in the generated vPlan. The parameters control which
sections are displayed in the Verification Plan Tree window.
Power_Mode_Coverage: TRUE | FALSE

If this parameter is set to FALSE, the Power Mode Groups section will not be displayed.
Power_Control_Signal_Coverage: TRUE | FALSE

If this parameter is set to FALSE, the Shutoff Condition, Active State Conditions, Isolation
Rules, and State Retention Rules sections will not be displayed under the power
domains in the Power Domains section. Only the Low Power Control Checks section will
be visible.
Power_Assertion_Coverage: TRUE | FALSE

If this parameter is set to FALSE, the Low Power Control Checks section will not be
displayed under the power domains in the Power Domains section.
Power_State_Coverage: TRUE | FALSE

If this parameter is set to FALSE, the States and Nominal Conditions sections will not be
displayed under the power domains in the Power Domains section.
Power_NC_Uninitialized_Coverage: TRUE | FALSE

When using the -lps_pmcheck_only option, the vPlan includes a section called Error
Condition below the Nominal Conditions section for a power domain. The
UNINITIALIZED state is reported in this covergroup bin. If this parameter is set to FALSE,
the Error Condition section will not be displayed.
June 2013
317

June 2013
318
15
Power-Aware Modeling
This chapter describes a set of built-in Verilog tasks and VHDL procedures that you can use
in your Verilog or VHDL code to get information about the low-power simulation. Most of the
tasks/procedures link a Verilog register or a VHDL signal to some low-power information,
such as the power-down state of a power domain, the name of the power mode that a domain
has just entered, the voltage that a power domain is at after a nominal condition transition,
and so on. You can then use the link register or signal to trigger the execution of code.
For both Verilog and VHDL, all link registers/signals can be linked to only one low-power
object. An error is generated if the same link register/signal is linked to more than one object.
See Verilog System Tasks and Functions on page 320.
See VHDL Procedures on page 359.
A Verilog example of using the power-aware modeling tasks is included with the
documentation at the following location:
install_directory/doc/PowerForwardUG/examples/power_aware_modeling
June 2013
319

Verilog System Tasks and Functions

The Verilog system tasks and functions are:
$lps_get_power_domain(<power_domain_register>[, <instance>]);
$lps_link_power_domain_powerdown(<link_register> [,<power_domain>);
$lps_link_power_domain_standby(<link_register>[, <power_domain>]);
$lps_link_power_domain_state(<link_register> [,<power_domain>]);
$lps_link_power_domain_voltage(<link_variable>[, <power_domain>]);
$lps_link_power_domain_gnd_voltage(<link_variable> [, <power_domain>]);
$lps_link_power_domain_nmos_voltage(<link_variable> [, <power_domain>]);
$lps_link_power_domain_pmos_voltage(<link_variable> [, <power_domain>]);
$lps_link_power_domain_nominal_condition(<link_register> [, <power_domain>]);
$lps_link_power_domain_power_mode(<link_register> [, <power_domain>]);
$lps_link_power_domain_trans_latency(<link_variable> [, <power_domain>]);
$lps_link_power_domain_trans_voltage(<link_variable> [, <power_domain>]);
$lps_enabled();
$lps_get_stime();
Note: For the $lps_get_power_domain task, the second argument is an instance. Do not
enclose this argument in double quotation marks. For example:
$lps_get_power_domain(pd_reg, top.dut1);
Note: For the $lps_link_* tasks, the second argument is a power domain. This argument
is a string constant or a register. It can be:
The full path of the power domain
The path of the power domain relative to the scope from which the task is called
If you use a string constant, the string must be enclosed in double quotation marks. For
example:
June 2013
320

module top;
reg link_pwrdown;
// Declare link_register
dut dut1();
initial
begin
link_pwrdown = 0;
/* Link register link_pwrdown to power-down state of domain top.dut1.PD1.
Specify absolute path of power domain using a string constant. */
$lps_link_power_domain_powerdown(link_pwrdown, top.dut1.PD1);
end
June 2013
321

$lps_get_power_domain(<power_domain_register>[, <instance>]);
Gets the power domain of interest and places its full path name in the
power_domain_register. The power_domain_register can then be used as an
input argument to subsequent task calls.
Note: The value stored in the power_domain_register is lost when the power domain
is powered down. Because the string representing the path to the power domain is no longer
available, the register cannot be used as an argument to other system tasks. It is
recommended that the $lps_get_power_domain task be always used in an always-on
power domain. If the task is used in a switchable domain, the domain must be on when the
task is invoked.
Arguments
power_domain_register
The register that will contain the full path to the power
domain of interest.
The register must be large enough to contain the full
path of the power domain. Because each character is 8
bits, a register of 512 characters is defined as:
reg [1:512 * 8] pd;
An error is generated if the register is too small for the full

path.
June 2013
322

[instance]
This argument can be:
The instance that the power domain of interest

controls. This can be:
The full path of the instance

$lps_get_power_domain(pd, top.t1.d1);
The path of the instance relative to the scope

from which the task is called
$lps_get_power_domain(pd, t1.d1);
You can also specify the instance as a string literal.

For example:
$lps_get_power_domain(pd, top.t1.d1);
$lps_get_power_domain(pd, t1.d1);
Note: The instance can be a register that has been

declared as an instance in a macro model.
The full or relative path to a signal or port that has

been declared as a boundary port with the
create_power_domain -boundary_ports
option.
$lps_get_power_domain(pd2, "t1.d2.clk");
If the instance argument is not used, the power

domain that is returned is the one that controls the
instance from where the task is called.
Example 1
CPF commands:
set_design top
create_power_domain -name PD1 -instances dut1 ....
Verilog code:
reg [1:50 * 8] pd_reg;
$lps_get_power_domain(pd_reg);
/* In module dut */
$lps_get_power_domain(pd_reg, dut1);
/* In module top */
$lps_get_power_domain(pd_reg, top.dut1); /* Anywhere */

June 2013
323

Example 2
In this example:
Three $lps_get_power_domain tasks get the power domains for instance

tb.t1.d1, signal tb.t1.d2.clk (defined as a boundary port in a macro model), and
reg tb.t1.d2.ff1 (declared as an instance in the macro model). The procedures
place the full path of the power domains into power domain registers pd1, pd2, and pd3.
The register pd1 is then used as an input argument to the

lps_link_power_domain_powerdown procedure.
CPF commands:
set_cpf_version 1.1
set_macro_model dff4
create_power_domain -name PDMD -default
# Port clk is declared as a boundary port
create_power_domain -name PDM1 \
-boundary_ports {clk rst in1 out1}
# Reg ff1 is declared as an instance in domain PDM2
-instances ff1
end_macro_model
set_design top
-instances d1 \
-shutoff_condition p1.pso \
-base_domains PDD
set_instance d2 -model dff4
create_isolation_rule -name ISO1 ...
end_design
June 2013
324

Verilog code:
module tb;
// Declare power domain registers pd1, pd2, pd3
reg [1:512 * 8] pd1;
reg [1:512 * 8] pd2;
reg [1:512 * 8] pd3;
// Declare link register for power down state
reg link_pwrdown;
...
top t1 (clk, rst, in1, in2, out1);
initial
begin
link_pwrdown = 0;
// Put full path of power domain for instance d1 into register pd1
$lps_get_power_domain(pd1, "t1.d1");
// Put full path of power domain of boundary port clk into register pd2
$lps_get_power_domain(pd2, "t1.d2.clk");
// Put full path of power domain for instance ff1 (reg declared as instance in
// macro model) into register pd3
$lps_get_power_domain(pd3, "t1.d2.ff1");
$display("Power domain register pd1 = %0s\n", pd1);
// Domain tb.t1.PD1
// Domain tb.t1.d2.PDM1
// Domain tb.t1.d2.PDM2
// Use power domain register pd1 as input argument to specify the domain
// in $lps_link_power_domain_powerdown task
$lps_link_power_domain_powerdown(link_pwrdown, pd1);
end
// Execute some code when domain tb.t1.PD1 is about to be shut down.
always @(posedge link_pwrdown)
begin
DO_SOMETHING;
end
endmodule
June 2013
325

module top (clk, rst, in1, in2, out1);
...
dff4 d1 (clk, rst, in1, out1);
dff4 d2 (clk, rst, in1, out1);
add4 a1 (in1, in2, out1);
pcm3 p1 (iso, ret, pso);
...
endmodule
module dff4 (clk, rst, in1, out1);
// Ports are specified as boundary ports in the CPF macro model
...
// Reg ff1 is specified as an instance in power domain PDM2 in the CPF macro model
reg [3:0] ff1;
endmodule
June 2013
326

$lps_link_power_domain_powerdown(<link_register>
[,<power_domain>);
Links the link_register to the power-down state of the power domain of interest.
The link_register becomes 1 when the power domain is about to be powered down.
You can then execute commands before corruption occurs. You cannot use any delays
between the time the link_register becomes 1 and when corruption occurs.
The link_register becomes 0 when the power domain is powered up.
If the link_register exists in a switchable power domain, it is corrupted when the
domain is powered down.
Arguments
link_register
A register of width 1. The register will be linked to the powerdown state of the power domain of interest.
[power_domain]
The name of the power domain of interest.

This argument is a string constant or a register. It can be:
The path of the power domain relative to the scope from

which the task is called
If the power_domain argument is not used, the power domain

of interest is the power domain that controls the instance from
where the task is called.
Example 1
In this example, the link_register is linked to the power down state of a power domain.
The full path of the power domain is specified as an argument. In this example, the power
domain of interest is top.dut1.PD1.
CPF commands:
set_design top
create_power_domain -name PD1 -instances dut1 ....
June 2013
327

Verilog code:
module top;
reg link_pwrdown;
dut dut1();
initial
begin
link_pwrdown = 0;
// Link register link_pwrdown to power-down state of domain top.dut1.PD1.
// Specify absolute path of power domain using a string constant.
$lps_link_power_domain_powerdown(link_pwrdown, top.dut1.PD1);
end
// Execute some code when top.dut1.PD1 is about to be shut down.
begin
DO_SOMETHING;
end
endmodule
Or:
module top;
reg link_pwrdown;
// Declare a register to be used as the power domain name
reg [1:32 * 8] str1 = top.dut1.PD1;
dut dut1();
initial
begin
link_pwrdown = 0;
// Specify absolute path of power domain using register str1.
$lps_link_power_domain_powerdown(link_pwrdown, str1);
end
June 2013
328

DO_SOMETHING;
endmodule
Example 2
In this example, the power domain of interest is specified using a relative path. The path is
specified relative to the scope from which the task is called.
module top;
reg link_pwrdown;
dut dut1();
initial
begin
link_pwrdown = 0;
// Specify relative path of power domain using a string constant.
$lps_link_power_domain_powerdown(link_pwrdown, dut1.PD1);
end
DO_SOMETHING;
endmodule
Or:
module top;
reg link_pwrdown;
reg [1:32 * 8] str1 = dut1.PD1;
...
// Specify relative path of power domain using register str1.
$lps_link_power_domain_powerdown(link_pwrdown, str1);
June 2013
329

Example 3
In this example, the power_domain argument is not used. The power domain of interest is
the one that controls instance dut1.
module dut(output reg out, input wire in);
// Declare link register
reg link_pwrdown;
initial
begin
link_pwrdown = 0;
$lps_link_power_domain_powerdown(link_pwrdown);
end
DO_SOMETHING;
endmodule
Example 4
In this example:
The $lps_get_power_domain task gets the power domain for instance

top.dut1.inst1, and places the full path of this power domain (top.dut1.PD1) into
register pd.
The register pd is then used as an input argument to the

$lps_link_power_domain_powerdown task.
module testbench;
// Declare link register
reg link_pwrdown;
// Declare power domain register for $lps_get_power_domain
reg [1:512 * 8] pd;
initial
begin
link_pwrdown = 0;
// Place full path of power domain for instance top.dut1.inst1 into register pd.
$lps_get_power_domain(pd, top.dut1.inst1);
June 2013
330

// Link register link_pwrdown to the power down state of the power domain.
// Use register pd as input argument to specify the domain.
$lps_link_power_domain_powerdown(link_pwrdown, pd);
end
DO_SOMETHING;
endmodule
June 2013
331

$lps_link_power_domain_standby(<link_register>[, <power_domain>]);
Links the link_register to the standby state of the power domain of interest.
The link_register becomes 1 when the power domain is about to go into the standby
state. You can then execute commands before the power domain is in standby. You cannot
use any delays between the time the link_register becomes 1 and when the state
change occurs.
The link_register becomes 0 when the power domain changes into another state.
Arguments
link_register
A register of width 1. The register will be linked to the standby

state of the power domain of interest.
[power_domain]

The path of the power domain relative to the scope from which
the task is called

Example
module top;
// Declare 1-bit reg for link_register
reg link_standby;
topA t1();
June 2013
332

initial begin
// Link register to standby state of power domain of interest.
$lps_link_power_domain_standby(link_standby, top.t1.pdA);
/*
Or declare a register big enough to hold the name of the power domain of
interest. Then use the register to specify the name of the power domain.
reg [1:250*8] pdReg;
pdReg = top.t1.pdA;
$lps_link_power_domain_standby(link_standby, pdReg);
*/
end
// Do something when the power domain is about to enter standby mode.
always @(posedge link_standby)
begin
$display($stime, Standby register link_standby = %d. Domain PDA about to
enter standby.\n, link_standby);
DO_SOMETHING;
end
endmodule
June 2013
333

$lps_link_power_domain_state(<link_register> [,<power_domain>]);
Links the link_register to the current state of the power domain of interest.
The link_register changes when the power domain changes to a different state. The
valid states are:
ON
OFF
TRANSITION
STANDBY
UNINITIALIZED

Arguments
link_register
The register that will be linked to the current state of the power
domain of interest.
Because state UNINITIALIZED is 13 characters, the minimum
register size is 13*8 = 104. Declare the link_register as
follows:
reg [1:13*8] link_register
[power_domain]

the task is called

June 2013
334

Example 1
CPF commands:
set_design top.t1
create_power_domain -name pdA -instances instA ....
Verilog code:
module top;
// Declare link_register to hold state of domain pdA.
reg [1:13*8] link_pdA_state;
topA t1();
initial
begin
// Link register link_pdA_state to state of domain top.t1.pdA.
// Specify absolute path of power domain using a string constant.
$lps_link_power_domain_state(link_pdA_state, "top.t1.pdA");
$display($stime, " initial pdA top state = %0s\n", link_pdA_state);
end
// Execute some code when link register link_pdA_state changes value.
always @(link_pdA_state)
begin
$display($stime, " change pdA top state = %0s\n", link_pdA_state);
DO_SOMETHING;
end
endmodule
Or:
module top;
reg [1:32*8] str1 = top.t1.pdA;
topA t1();
June 2013
335

initial
begin
// Specify absolute path of power domain using register str1.
$lps_link_power_domain_state(link_pdA_state, str1);
end
DO_SOMETHING;
endmodule
Example 2
specified relative to the scope from which the task is called.
module top;
// Declare link_register to hold state of domain pdA.
topA t1();
initial
begin
// Specify relative path of power domain using a string constant.
$lps_link_power_domain_state(link_pdA_state, "t1.pdA");
end
string linkStr;
begin
$swrite(linkStr, "%0s", link_pdA_state);
if (linkStr == "TRANSITION")
DO_SOMETHING;
end
endmodule
June 2013
336

Or:
module top;
reg link_pdA_state;
reg [1:32 * 8] str1 = t1.pdA;
...
// Link register link_pdA_state to state of domain t1.pdA.
// Specify relative path of power domain using register str1.
$lps_link_power_domain_state(link_pdA_state, str1);
Example 3
In this example:
The $lps_get_power_domain task gets the power domain for instance top.t1, and
places the full path of this power domain (top.t1.pdA) into register pdReg.
The register pdReg is then used as an input argument to the

$lps_link_power_domain_state task.
module top;
// Declare link_register.
// Declare power domain register for $lps_get_power_domain
topA t1();
initial
begin
// Place full path of power domain for instance top.t1 into register pdReg.
$lps_get_power_domain(pdReg, top.t1);
// Link register link_pdA_state to state of the power domain.
// Use register pdReg as input argument to specify the domain.
$lps_link_power_domain_state(link_pdA_state, pdReg);
end
June 2013
337

string linkStr;
begin
$swrite(linkStr, "%0s", link_pdA_state);
if (linkStr == "TRANSITION")
DO_SOMETHING;
end
endmodule
June 2013
338

$lps_link_power_domain_voltage(<link_variable>[, <power_domain>]);
Links the link_variable to the voltage of the power domain of interest.
The link_variable changes when the transition to the new voltage value is complete.
If the link_variable exists in a switchable power domain, it is corrupted when the
Arguments
link_variable
A real variable. The variable will be linked to the voltage of the

power domain of interest.
[power_domain]

the task is called

Example
module top;
// Declare a real variable for the link_register
real link_volt;
topA t1();
initial begin
// Link variable link_volt to the voltage of power domain
// of interest (domain top.t1.pdA).
$lps_link_power_domain_voltage(link_volt, t1.pdA);
June 2013
339

/* Or declare a register big enough to hold the name of the power domain of
interest.
Then use the register to specify the name of the power domain.
pdReg = t1.pdA;
$lps_link_power_domain_voltage(link_volt, pdReg); */
$display($stime, initial pdA top voltage = %f\n, link_volt);
end
// Do something when the power domain has completed a voltage transition.
always @(link_volt)
$display($stime, change pdA top voltage = %f\n, link_volt);
DO_SOMETHING;
endmodule
June 2013
340

$lps_link_power_domain_gnd_voltage(<link_variable>
[, <power_domain>]);
Links the link_variable to the ground voltage of the power domain of interest.
The link_variable changes when the transition to the new ground voltage value is
complete.
Arguments
link_variable
A real variable. The variable will be linked to the ground voltage of

the power domain of interest.
[power_domain]

the task is called

Example
See the example in the description of the $lps_link_power_domain_pmos_voltage
task.
June 2013
341

$lps_link_power_domain_nmos_voltage(<link_variable>
Links the link_variable to the nmos bias voltage of the power domain of interest.
The link_variable changes when the transition to the new nmos bias voltage value is
complete.
Arguments
link_variable
A real variable. The variable will be linked to the nmos bias

voltage of the power domain of interest.
[power_domain]

the task is called

Example
See the example in the description of the $lps_link_power_domain_pmos_voltage
task.
June 2013
342

$lps_link_power_domain_pmos_voltage(<link_variable>
Links the link_variable to the pmos bias voltage of the power domain of interest.
The link_variable changes when the transition to the new pmos bias voltage value is
complete.
Arguments
link_variable
A real variable. The variable will be linked to the pmos bias

voltage of the power domain of interest.
[power_domain]

the task is called

Example
module top;
...
...
// Declare a real variable for the pmos bias voltage link_variable
real linkPMOS;
// Declare a real variable for the nmos bias voltage link_variable
real linkNMOS;
// Declare a real variable for the ground voltage link_variable
real linkGND;
June 2013
343

// Declare a real variable for voltage link_variable
real link_volt;
// Declare a power domain register that will store the full path
// name of a power domain
topA t1();
initial begin
// Link variable linkPMOS to the pmos bias voltage of power domain top.t1.pdA.
$lps_link_power_domain_pmos_voltage(linkPMOS, top.t1.pdA);
// Link variable linkNMOS to the nmos bias voltage of power domain top.t1.pdA.
$lps_link_power_domain_nmos_voltage(linkNMOS, top.t1.pdA);
// Link variable linkGND to the ground voltage of power domain top.t1.pdA.
$lps_link_power_domain_gnd_voltage(linkGND, top.t1.pdA);
// Assign power domain name to reg pdReg
pdReg = top.t1.pdT;
// Link variable link_volt to the voltage of power domain top.t1.pdT.
// Use pdReg to specify the name of the power domain.
$lps_link_power_domain_voltage(link_volt, pdReg);
$display($stime, initial pdA top pmos voltage = %f\n, linkPMOS);
$display($stime, initial pdA top nmos voltage = %f\n, linkNMOS);
$display($stime, initial pdA top gnd voltage = %f\n, linkGND);
$display($stime, initial pdT top voltage = %f\n, link_volt);
end
// Do something when the power domain has completed a voltage transition.
always @(linkPMOS)
$display($stime, change pdA top pmos voltage = %f\n, linkPMOS);
always @(linkNMOS)
$display($stime, change pdA top nmos voltage = %f\n, linkNMOS);
always @(linkGND)
$display($stime, change pdA top gnd voltage = %f\n, linkGND);
June 2013
344

always @(link_volt)
$display($stime, change pdT top voltage = %f\n, link_volt);
endmodule
module topA;
wire [5:0] data, ndata;
reg clk;
...
...
endmodule
June 2013
345

$lps_link_power_domain_nominal_condition(<link_register>
Links the link_register to the current nominal condition of the power domain of interest.
The link_register changes when the power domain transitions to a new nominal
condition. If the power domain transitions to the off state, the register will have a value of
SHUTOFF. The register will have a value of UNINITIALIZED when the simulation is being
controlled by active state conditions, and when the power domain is on but there are no active
state conditions enabled to specify the nominal condition to which the domain should
transition.
If the link_register exists in a switchable power domain, the register is corrupted when
the domain is powered down.
Arguments
link_register
The register to be linked to the nominal condition name of the

power domain of interest.
The register must be large enough to hold any nominal condition
name of the power domain. To hold 50 characters, the register
must be defined as:
reg [1:50 * 8] link_register
An error is generated if the register is too small for the nominal

condition name.
Note: Registers larger than 256 characters may cause problems.
If the nominal condition link register is greater than 256 characters,
a warning is generated telling you to decrease the size of the
register to 256 or less.
June 2013
346

[power_domain]

the task is called
If the power_domain argument is not used, the power domain of

interest is the power domain that controls the instance from where
the task is called.
Example 1
In this example, the $lps_link_power_domain_nominal_condition task links the
register arrays link_ncA, link_ncB, and link_ncT to the current nominal condition of
power domains top.pdA, top.pdB, and top.pdT, respectively.
module top;
...
...
// Declare three registers large enough to hold the name of any nominal condition.
reg [1:16*8] link_ncA;
reg [1:16*8] link_ncB;
reg [1:16*8] link_ncT;
string ncA, ncB, ncT;
...
initial
begin
// Link the register link_ncA to the nominal condition of power domain pdA.
$lps_link_power_domain_nominal_condition(link_ncA, "top.pdA");
$swrite(ncA, "%0s", link_ncA);
$display($stime, " NomCond A = %s", ncA);
// Link the register link_ncB to the nominal condition of power domain pdB.
$lps_link_power_domain_nominal_condition(link_ncB, "top.pdB");
$swrite(ncB, "%0s", link_ncB);
$display($stime, " NomCond B = %s", ncB);
June 2013
347

// Link the register link_ncT to the nominal condition of power domain pdT.
$lps_link_power_domain_nominal_condition(link_ncT, "top.pdT");
$swrite(ncT, "%0s", link_ncT);
$display($stime, " NomCond T = %s", ncT);
...
end
// Display nominal condition of top.pdA when it changes and values of
// active state conditions for pdA.
always @(link_ncA)
begin
$swrite(ncA, "%0s", link_ncA);
$display($stime, " Active state conditions for pdA: aseA08 = %d aseA12 = %d",
pmc.aseA08, pmc.aseA12);
$display($stime, " NomCond A = %s", ncA);
end
// Display nominal condition of top.pdB when it changes and values of
// active state conditions for pdB.
always @(link_ncB)
begin
$swrite(ncB, "%0s", link_ncB);
$display($stime, " Active state conditions for pdB: aseB08 = %d aseB12 = %d",
pmc.aseB08, pmc.aseB12);
$display($stime, " NomCond B = %s", ncB);
end
// Display nominal condition of top.pdT when it changes and values of
// active state conditions for pdT.
always @(link_ncT)
begin
$swrite(ncT, "%0s", link_ncT);
$display($stime, " Active state conditions for pdT: aseT08 = %d aseT12 = %d",
pmc.aseT08, pmc.aseT12);
$display($stime, " NomCond T = %s", ncT);
end
...
...
At simulation time 10 ns, power domain pdA starts transitioning to the power off state. The
transition is finished at time 12 ns, and the nominal condition is SHUTOFF.
June 2013
348

At simulation time 20 ns, power domain pdA transitions to the power on state because the
domain shutoff expression is false. At this time, no active state conditions for the domain are
enabled, and the nominal condition is UNINITIALIZED.
% irun -lps_cpf dut.cpf -lps_pmcheck_only -lps_sim_verbose 1 \
-sv -access rwc \
pmc.v dut.v
...
...
ncsim> run
0 NomCond A = UNINITIALIZED
0 NomCond B = UNINITIALIZED
0 NomCond T = UNINITIALIZED
At simulation time 0 FS:
condition NC_08

NC_12

NC_12
Power domain pdT has transitioned to nominal condition
0 Active state conditions for pdB: aseB08 = 0 aseB12 = 1

0 NomCond B = NC_12
0 Active state conditions for pdT: aseT08 = 0 aseT12 = 1
0 NomCond T = NC_12
condition NC_08
2 Active state conditions for pdA: aseA08 = 1 aseA12 = 0

2 NomCond A = NC_08
Power domain pdA is being powered off

off state
Power domain pdA has started transitioning to power

off state
Power domain pdA has finished transitioning to power

12 NomCond A = SHUTOFF
June 2013
349

Power domain pdA has transitioned to power on state

20 NomCond A = UNINITIALIZED

20 NomCond B = SHUTOFF
Power domain pdB is being powered up
Power domain pdB has transitioned to power on state

30 NomCond B = UNINITIALIZED
condition NC_12

condition NC_12

33 NomCond A = NC_12
...
...
Example 2
In this example, the $lps_get_power_domain task is used to get the power domain of an
instance (top.t1.instA) and place its full path name in the power_domain_register
pd. The power domain is top.t1.pdA.
$lps_get_power_domain(pd, t1.instA);
The $lps_link_power_domain_nominal_condition task then links the register array

NomCond to the current nominal condition of the power domain. The power domain is
specified using the value returned by $lps_get_power_domain.
$lps_link_power_domain_nominal_condition(NomCond, pd);
June 2013
350

module top;
// Declare a register large enough to hold the full path of any power domain.
reg [1:56 * 8] pd;
// Declare a register large enough to hold the name of any nominal condition.
reg [1:25*8] NomCond;
topA t1();
initial
begin
// Get power domain of top.t1.instA
$lps_get_power_domain(pd, t1.instA);
$display(Power domain is: %0s, pd);
/* Link the register NomCond to the nominal condition of the power
domain of interest.
In this example, the power domain is specified using the value returned by
$lps_get_power_domain. The power domain is top.t1.pdA. */
$lps_link_power_domain_nominal_condition(NomCond, pd);
$display($stime, Initial nominal condition of %0s is: %0s\n, pd, NomCond);
end
// Do something when the nominal condition of top.t1.pdA changes.
always @(NomCond)
begin
$display($stime, Current nominal condition of %0s is: %0s\n, pd, NomCond);
DO_SOMETHING;
end
endmodule
module topA;
...
modA instA(clk, data);
modB instB(data, ndata);
...
endmodule
module modA (clock, num);
...
endmodule
June 2013
351

module modB (x, y);
...
endmodule
June 2013
352

$lps_link_power_domain_power_mode(<link_register>
Links the link_register to the current power mode of the power domain of interest.
The link_register changes when the power domain transitions to a new power mode.
If a power mode does not exist for the power domain, the register will have a value of
UNDEFINED.
If the link_register exists in a switchable power domain, the register is corrupted when
the domain is powered down.
Arguments
link_register
The register to be linked to the power mode name of the power

domain of interest.
The register must be large enough to hold any power mode name
of the power domain. To hold 32 characters, the register must be
defined as:
reg [1:32 * 8] link_register
An error is generated if the register is too small for the power mode
name.
Note: Registers larger than 256 characters may cause problems.
If the power mode link register is greater than 256 characters, a
warning is generated telling you to decrease the size of the register
to 256 or less.
[power_domain]

the task is called

the task is called.
June 2013
353

Example
module top;
// Declare link register large enough to hold any power mode name
reg [1:25*8] link_pm;
topA t1();
initial
begin
// Link link register to domain top.t1.pdA
$lps_link_power_domain_power_mode(link_pm, t1.pdA);
$display($stime, Initial pdA power mode = %0s\n, link_pm);
end
always @(link_pm)
$display($stime, Change pdA power mode = %0s\n, link_pm);
endmodule
module topA;
...
modA instA(clk, data);
modB instB(data, ndata);
...
endmodule
module modA (clock, num);
...
endmodule
module modB (x, y);
...
endmodule
June 2013
354

$lps_link_power_domain_trans_latency(<link_variable>
Links the link_variable to the time it will take the power domain of interest to finish its
transition to a different nominal condition.
The link_variable is updated at the start of the transition for the power domain of
interest.
Arguments
link_variable
A variable of type realtime. The variable will be linked to the time

(in the timescale precision of the simulation) needed by the power
domain of interest to transition to a new nominal condition. The
variable changes at the start of the transition for the power domain
of interest.
[power_domain]

the task is called

June 2013
355

$lps_link_power_domain_trans_voltage(<link_variable>
Links the link_variable to the value of the voltage of the power domain of interest when
the transition to a new nominal condition has completed.
The link_variable changes at the start of a transition to a new nominal condition. The
value of the variable is the value at the end of the transition.
Arguments
link_variable
A real variable. The variable will be linked to the voltage of the

power domain of interest, and its value will be the voltage of the
power domain at the end of the transition. This variable will
change when the power domain of interest starts to transition.
[power_domain]

the task is called

June 2013
356

$lps_enabled();
This function returns 1 if low-power simulation has been enabled in the design with the
elaborator -lps_cpf option, and if the simulation option -lps_off is not used.
The function returns 0 if the design is not elaborated with low-power simulation enabled, or if
the simulator option -lps_off is used.
Example
module top;
wire sc1, sc2;
test1 t1();
initial
begin
$display(\n);
if ($lps_enabled())
begin
$display(LPS enabled.\n);
[DO SOMETHING;]
[DO SOMETHING ELSE;]
end
else
$display(LPS not enabled.\n);
end
endmodule
June 2013
357

$lps_get_stime();
This function returns the simulation time (a time variable) for the start of low-power simulation.
Example
module top;
integer i;
time LPS_stime;
wire sc1, sc2;
reg [1:4] in;
test1 t1(in[1]);
...
initial
begin
$display(\n);
if ($lps_enabled())
begin
$display(LPS enabled.\n);
end
else
$display(LPS not enabled.\n);
LPS_stime = $lps_get_stime();
$display(LPS_stime = %0d\n, LPS_stime);
end
endmodule
June 2013
358

VHDL Procedures
For VHDL, the power-aware modeling procedures are contained in package LPSUTILITIES,
which is part of the NCUTILS library. To access the procedures in the package, you must
reference the package in a use clause by adding the following lines to your VHDL code:
library NCUTILS;
use NCUTILS.LPSUTILITIES.all;
The VHDL procedures are:

lps_get_power_domain (power_domain_signal[, instance_path]);
lps_link_power_domain_powerdown(link_signal[, power_domain]);
lps_link_power_domain_standby(link_signal[, power_domain]);
lps_link_power_domain_state(link_signal[, power_domain]);
lps_link_power_domain_voltage(link_signal[, power_domain]);
lps_link_power_domain_gnd_voltage(link_signal[, power_domain]);
lps_link_power_domain_nmos_voltage(link_signal[, power_domain]);
lps_link_power_domain_pmos_voltage(link_signal[, power_domain]);
lps_link_power_domain_nominal_condition(link_signal [, power_domain]);
lps_link_power_domain_power_mode(link_signal[, power_domain]);
lps_link_power_domain_trans_latency(link_signal[, power_domain]);
lps_link_power_domain_trans_voltage(link_signal[, power_domain]);
lps_enabled(signal_name);
lps_get_stime(signal_name);
Note: The first argument to the VHDL procedures must be passed in by reference. This
argument must be enclosed in double quotes.
For the lps_link_* procedures, the second argument is the power domain of interest.
This argument is a string constant or the value of a signal of type string that holds the path
name of the power domain. If you use a string constant, the argument must be enclosed in
double quotes. For example:
June 2013
359

-- Declare link signal
signal link_pwrdown : std_logic := 0;
...
-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx.
-- Specify absolute path of power domain using a string constant.
lps_link_power_domain_powerdown(link_pwrdown, :adder1:PDEx);
Or:
signal link_pwrdown : std_logic := '0';
-- Declare a signal of type string for the path of the power domain
signal str1 : string (512 down to 1) := ":adder1:PDEx;
-- Link signal link_pwrdown to power-down state of power domain.
-- Specify path of power domain using signal str1.
lps_link_power_domain_powerdown ("link_pwrdown", str1);
June 2013
360

lps_get_power_domain (power_domain_signal[, instance_path]);

Gets the power domain of interest and places its full path name in the
power_domain_signal. The power_domain_signal can then be used as an input
argument to subsequent procedure calls.
Note: The value stored in the power_domain_signal is lost when the power domain is
powered down. Because the string representing the path to the power domain is no longer
available, the signal cannot be used as an argument to other procedures. It is recommended
that the lps_get_power_domain procedure be always used in an always-on power
domain. If the procedure is used in a switchable domain, the domain must be on when the
procedure is invoked.
Arguments
power_domain_signal
A signal of type string that will contain the full path

of the power domain of interest.
The signal must be large enough to contain the full
path of the power domain. For example:
signal pwrDA : string (10 downto 1);
An error is generated if the signal is too small for the

full path.
June 2013
361

[instance_path]
This argument can be:
The instance that the power domain of interest

controls. This can be:
The full path of the instance

lps_get_power_domain(pd, :t1.d1);
The path of the instance relative to the scope

from which the procedure is called
lps_get_power_domain(pd, d1);
Note: The instance can be a register that has

been declared as an instance in a macro model.
The full or relative path to a signal or port that has

been declared as a boundary port with the
create_power_domain -boundary_ports
option.
lps_get_power_domain(pd2, ":t1.d2.clk");
If the instance argument is not used, the power

domain that is returned is the one that controls the
instance from where the procedure is called.
Example 1
CPF commands:
set_design :
create_power_domain -name pdA -instances instA....
VHDL code:
lps_get_power_domain(pwrDA);
-- In instance instA
lps_get_power_domain(pwrDA, instA);
-- In design unit top
lps_get_power_domain(pwrDA, :instA);
-- Anywhere
June 2013
362

Example 2
In this example:
Three lps_get_power_domain procedures get the power domains for instance

:t1:d1, signal :t1:d2:clk (defined as a boundary port in a macro model), and
:t1:d2:ff1 (declared as an instance in the macro model). The procedures place the
full path of the power domains into signals pd1, pd2, and pd3.
The power domain signal pd1 is then used as an input argument to the
CPF commands:
set_cpf_version 1.1
set_macro_model dff4
create_power_domain -name PDMD -default
# Port clk is declared as a boundary port
-boundary_ports {clk rst in1 out1}
# Reg ff1 is declared as an instance in domain PDM2
-instances ff1
end_macro_model
set_design top
-instances d1 \
-shutoff_condition p1.pso \
-base_domains PDD
set_instance d2 -model dff4
end_design
June 2013
363

VHDL code:
-- File: tb.vhd
library ieee;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_textio.all;
library ncutils;
use ncutils.lpsutilities.all;
library std;
use std.textio.all;
entity tb is
end tb;
architecture sim of tb is
component top
port (...);
end component;
signal clk, rst : std_logic;
signal in1, in2, out1 : std_logic_vector (3 downto 0);
-- Declare power domain signals for lps_get_power_domain procedures
signal pd1, pd2, pd3 : string (29 downto 1);
-- Declare link signal for power down state
procedure pd is
variable vline : line;
begin
write(vline, string'("Power domain signal pd1 = " ));
write(vline, pd1);
write(vline, string'("
Power domain signal pd2 = " ));
write(vline, pd2);
Power domain signal pd3 = " ));
write(vline, pd3);
writeline (output, vline);
end pd;
June 2013
364

procedure pwrdown is
begin
write(vline, string'("Power domain is powering down
= " ));
write(vline, pd1);
--DO_SOMETHING;
end pwrdown;
begin
t1 : top port map (clk, rst, in1, in2, out1);
-- Use power domain signal pd1 as an input argument to specify the power domain
-- in lps_link_power_domain_powerdown procedure.
-- This links signal link_pwrdown to the power-down state of domain :t1:PD1
lps_link_power_domain_powerdown("link_pwrdown", pd1);
-- Execute procedure pd when link signals change value.
process (pd1, pd2, pd3)
begin
pd;
end process;
-- Execute procedure pwrdown when domain :t1.PD1 is about to be shut down.
process (link_pwrdown)
begin
if link_pwrdown = '1' then
pwrdown;
end if;
end process;
process begin
clk <= '0';
...
end process;
-- Put full path of power domain for instance d1 into power domain signal pd1
lps_get_power_domain("pd1", ":t1:d1");
-- Put full path of power domain for port clk into power domain signal pd2
lps_get_power_domain("pd2", ":t1:d2:clk");
June 2013
365

-- Put full path of power domain for register instance ff1 into power
-- domain signal pd3
lps_get_power_domain("pd3", ":t1:d2:ff1");
rst <= '1',
'0' after 5 ns;
...
process begin
in2 <= "0000";
...
end process;
process begin
wait for 1200 ns;
...
end process;
end sim;
-- File: top.vhd
library ieee;
entity top is
port (...);
end top;
architecture rtl of top is
component dff4
port (clk, rst : in std_logic;
in1
: in std_logic_vector (3 downto 0);
out1
: out std_logic_vector (3 downto 0)
);
end component;
component add4
port (...);
end component;
June 2013
366

component pcm3
port (...);
end component;
signal tmp1, tmp2 : std_logic_vector (3 downto 0);
signal iso, ret, pso : std_logic;
begin
d1 : dff4 port map (clk, rst, in1, tmp1);
d2 : dff4 port map (clk, rst, in1, tmp2);
a1 : add4 port map (tmp1, tmp2, out1);
p1 : pcm3 port map (iso, ret, pso);
end rtl;
-- File dff4.vhd
library ieee;
entity dff4 is
-- These ports are declared as boundary ports in the CPF macro model
port (clk, rst : in std_logic;
in1
out1
: in std_logic_vector (3 downto 0);

: out std_logic_vector (3 downto 0)
);
end dff4;
architecture rtl of dff4 is
-- ff1 is declared as an instance in power domain PDM2 in the CPF macro model.
signal ff1 : std_logic_vector (3 downto 0);
begin
...
...
end rtl;
June 2013
367

lps_link_power_domain_powerdown(link_signal[, power_domain]);
Links the link_signal to the power-down state of the power domain of interest.
The link_signal becomes 1 when the power domain is about to be powered down. You
can then execute commands before corruption occurs. You cannot use any delays between
the time the link_signal becomes 1 and when corruption occurs.
The link_signal becomes 0 when the power domain is powered up.
If the link_signal exists in a switchable power domain, it is corrupted when the domain
is powered down.
Arguments
link_signal
A signal of type std_logic or std_ulogic of width 1. The

signal will be linked to the power-down state of the power domain
of interest.
[power_domain]

This argument is a string constant or the value of a signal of type
string that holds the path name of the power domain. It can be:
The path of the power domain relative to the scope from

which the procedure is called

where the procedure is called.
June 2013
368

Example 1
In this example, the link_signal is linked to the power-down state of a power domain.
The full path of the power domain is specified as an argument, so the procedure can be in the
architecture for any entity.
In this example, the power domain of interest is :adder1:PDEx.
CPF commands:
set design :adder1
create_power_domain -name PDEx -instances Add0 ...
VHDL code:
library NCUTILS;
library ieee;
use ieee.std_logic_textio.all;
library std;
use std.textio.all;
entity TOP is
end entity TOP;
architecture RTL of TOP is
..
begin
DO_SOMETHING;
end pwrdown;
begin
adder1 : entity WORK.MID port map (clk);
-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx.
-- Specify absolute path of power domain using a string constant.
lps_link_power_domain_powerdown(link_pwrdown, :adder1:PDEx);
June 2013
369

begin
if link_pwrdown = 1 then
pwrdown;
end if;
end process;
...
Or:
-- Declare a signal of type string for the path of the power domain
signal str1 : string (512 down to 1) := ":adder1:PDEx;
-- Link signal link_pwrdown to power-down state of power domain.
-- Specify path of power domain using signal str1.
lps_link_power_domain_powerdown ("link_pwrdown", str1);
Example 2
specified relative to the scope from which the procedure is called.
-- Current scope is :adder1
entity MID is
port(clk : std_logic := 0);
end entity MID;
architecture RTL of MID is
-- Declare link_signal
begin
DO_SOMETHING;
end pwrdown;
June 2013
370

begin
-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx
-- Specify relative path name of power domain.
lps_link_power_domain_powerdown(link_pwrdown, PDEx);
begin
pwrdown;
end if;
end process;
Add0 : entity WORK.BOT port map (clk);
Example 3
In this example:
The lps_get_power_domain procedure gets the power domain for instance

:blk_inst1, and places the full path of this power domain (:dut1:PD1) into signal pd.
The signal pd is then used as an input argument to the

CPF commands:
set_cpf_version 1.1
set_design :
create_power_domain -name pdA instances blk_inst1 .....
VHDL code:
-- Declare power domain signal for lps_get_power_domain
signal pd : string (512 downto 1);
-- Get full path of domain that controls :blk_inst1
lps_get_power_domain (pd, :blk_inst1);
-- Use power domain signal in lps_link_power_domain_powerdown procedure
lps_link_power_domain_powerdown(link_pwrdown, pd);
...
June 2013
371

begin
DO_SOMETHING;
end pwrdown;
begin
pwrdown;
end if;
end process;
June 2013
372

lps_link_power_domain_standby(link_signal[, power_domain]);
Links the link_signal to the standby state of the power domain of interest.
The link_signal becomes 1 when the power domain is about to go into the standby state.
You can then execute commands before the power domain is in standby. You cannot use any
delays between the time the link_register becomes 1 and when the state change
occurs.
The link_signal becomes 0 when the power domain changes into another state.
is powered down.
Arguments
link_signal
A signal of type std_logic or std_ulogic of width 1. The

signal will be linked to the standby state of the power domain of
interest.
[power_domain]

string that holds the path of the power domain. It can be:
the task is called

Example
library NCUTILS;
...
entity top is
end top;
June 2013
373

architecture top_rtl of top is
...
signal clk
: std_logic;
signal data : std_logic_vector (5 downto 0);

...
-- Declare link signal of type std_logic
signal link_standby : std_logic := 0;
procedure standby is
begin
DO_SOMETHING;
end standby;
begin
process (link_standby)
begin
-- Execute procedure standby when link_standby is 1 (i.e., when domain
-- :pdA is about to enter standby mode)
if link_standby = 1 then
standby;
end if;
end process;
instA : modA port map(...);
instB : modB port map(...);
PowerDown : process
begin
-- Link link signal to standby state of power domain :pdA
lps_link_power_domain_standby(link_standby, :pdA);
mte
<= 00000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
wait for 99 ns;
mte
<= 00001;
...
end Process;
end top_rtl;
June 2013
374

lps_link_power_domain_state(link_signal[, power_domain]);
Links the link_signal to the current state of the power domain of interest.
The link_signal changes when the power domain changes to a different state. The valid
states are:
ON
OFF
TRANSITION
STANDBY
UNINITIALIZED
is powered down.
Arguments
link_signal
A signal of type string that will be linked to the current state of

the power domain of interest.
Because state UNINITIALIZED is 13 characters, the minimum
width of the link_signal is 13. Declare the link_signal
as follows:
signal link_sig : string (13 downto 1);
[power_domain]

the procedure is called

June 2013
375

Example
library NCUTILS;
...
entity top is
end top;
component modA is
port (...);
end component;
component modB is
port (...);
end component;
signal clk
: std_logic;
signal data
: std_logic_vector (5 downto 0);
...
-- Declare link signals for current state of power domains :pdA and :pdB
signal link_pdA_state : string (13 downto 1):="1111111111111";
signal link_pdB_state : string (13 downto 1):="1111111111111";
procedure expect is
begin
write(vline, string'("State of domain pdA = " ));
write(vline, link_pdA_state);
State of domain pdB = " ));
write(vline, link_pdB_state);
end expect;
June 2013
376

begin
-- Execute procedure expect when a link signal changes value.
process (link_pdA_state, link_pdB_state)
begin
expect;
end process;
instA : modA port map(...);
instB : modB port map(...);
process
begin
clk <= 0;
wait for 5 ns;
clk <= 1;
wait for 5 ns;
end process;
PowerDown : process
begin
-- Link link signal link_pdA_state to the current state of power domain :pdA
lps_link_power_domain_state("link_pdA_state", ":pdA");
-- Link link signal link_pdB_state to the current state of power domain :pdB
lps_link_power_domain_state("link_pdB_state", ":pdB");
mte
<= 00000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
wait for 99 ns;
mte
<= 00001;
wait;
end Process;
end top_rtl;
June 2013
377

lps_link_power_domain_voltage(link_signal[, power_domain]);
Links the link_signal to the voltage of the power domain of interest.
The link_signal changes when the transition to the new voltage value is complete.
is powered down.
Arguments
link_signal
The name or full path name of a signal of type real. The signal
will be linked to the voltage of the power domain of interest.
[power_domain]


Example
library NCUTILS;
...
entity top is
end top;
...
signal clk
: std_logic;

June 2013
378

...
-- Declare link signal of type real
signal link_volt_pdA : real := -1.0;
procedure volt is
begin
DO_SOMETHING;
end volt;
begin
process (link_volt_pdA)
-- Execute procedure volt when link_volt_pdA changes value (i.e., when
-- domain :pdA has transitioned to a new voltage value)
begin
volt;
end process;
instA : modA port map(clock => clk, num
=> data);
instB : modB port map(x => data, y => ndata);

PowerDown : process
begin
-- Link link signal to voltage of power domain :pdA
lps_link_power_domain_voltage(link_volt_pdA, :pdA);
mte
<= 00000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
wait for 99 ns;
mte
<= 00001;
...
wait;
end Process;
end top_rtl;
June 2013
379

lps_link_power_domain_gnd_voltage(link_signal[, power_domain]);
Links the link_signal to the ground voltage of the power domain of interest.
The link_signal changes when the transition to the new ground voltage value is
complete.
is powered down.
Arguments
link_signal
will be linked to the ground voltage of the power domain of
interest.
[power_domain]


Example
See the example in the description of the lps_link_power_domain_pmos_voltage
procedure.
June 2013
380

lps_link_power_domain_nmos_voltage(link_signal[, power_domain]);
Links the link_signal to the nmos bias voltage of the power domain of interest.
The link_signal changes when the transition to the new nmos bias voltage value is
complete.
is powered down.
Arguments
link_signal
will be linked to the nmos bias voltage of the power domain of
interest.
[power_domain]


Example
See the example in the description of the lps_link_power_domain_pmos_voltage
procedure.
June 2013
381

lps_link_power_domain_pmos_voltage(link_signal[, power_domain]);
Links the link_signal to the pmos bias voltage of the power domain of interest.
The link_signal changes when the transition to the new pmos bias voltage value is
complete.
is powered down.
Arguments
link_signal
will be linked to the pmos bias voltage of the power domain of
interest.
[power_domain]


Example
library NCUTILS;
...
entity top is
end top;
June 2013
382

component modA is
port (clock : in std_logic;
num
: out std_logic_vector (5 downto 0));
end component;
component modB is
port (x : in std_logic_vector (5 downto 0);
y : out std_logic_vector (5 downto 0));
end component;
signal clk
: std_logic;
signal data
: std_logic_vector (5 downto 0);
...
-- Declare link signals of type real
signal link_volt_pdA : real := -1.0;
signal linkPMOS
: real := -1.0;
signal linkNMOS
: real := -1.0;
signal linkGND
: real := -1.0;
signal link_volt_pdB : real := -1.0;

procedure expect is
begin
write(vline, string(link_volt_pdA = ));
write(vline, link_volt_pdA);
write(vline, string( linkPMOS = ));
write(vline, linkPMOS);
write(vline, string( linkNMOS = ));
write(vline, linkNMOS);
write(vline, string( linkGND = ));
write(vline, linkGND);
write(vline, string(
link_volt_pdB = ));
write(vline, link_volt_pdB);
end expect;
begin
June 2013
383

process (link_volt_pdA, linkPMOS, linkNMOS, linkGND, link_volt_pdB)
-- Execute procedure expect when a link signal changes value.
begin
expect;
end process;
instA : modA port map(clock => clk, num => data);
process
begin
clk <= 0;
wait for 5 ns;
clk <= 1;
wait for 5 ns;
end process;
PowerDown : process
begin
-- Link link signal link_volt_pdA to the voltage of power domain :pdA
lps_link_power_domain_voltage(link_volt_pdA, :pdA);
-- Link link signal linkPMOS to the pmos bias voltage of power domain :pdA
lps_link_power_domain_pmos_voltage(linkPMOS, :pdA);
-- Link link signal linkNMOS to the nmos bias voltage of power domain :pdA
lps_link_power_domain_nmos_voltage(linkNMOS, :pdA);
-- Link link signal linkGND to the ground voltage of power domain :pdA
lps_link_power_domain_gnd_voltage(linkGND, :pdA);
-- Link link signal link_volt_pdB to the voltage of power domain :pdB
lps_link_power_domain_voltage(link_volt_pdB, :pdB);
mte
<= 00000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
wait for 99 ns;
mte
<= 00001;
wait;
end Process;
end top_rtl;
June 2013
384

lps_link_power_domain_nominal_condition(link_signal
[, power_domain]);
Links the link_signal to the current nominal condition of the power domain of interest.
The link_signal changes when the power domain transitions to a new nominal condition.
If the power domain transitions to the off state, the register will have a value of SHUTOFF.
If the link_signal exists in a switchable power domain, the signal is corrupted when the
Arguments
link_signal
A signal of type string. The signal will be linked to the nominal

condition of the power domain of interest.
The signal must be large enough to hold any nominal condition
name of the power domain. To hold 512 characters, the register
must be defined as:
An error is generated if the signal is too small for the nominal

condition name.
[power_domain]


the procedure is called.
June 2013
385

Example
library NCUTILS;
...
entity top is
end top;
...
signal clk
: std_logic;

...
-- Declare link signal of type string
signal link_nc_pdA : string (20 downto 1);
procedure nc is
begin
DO_SOMETHING;
end nc;
begin
process (link_nc_pdA)
-- Execute procedure nc when link_nc_pdA changes value (i.e., when domain
-- :pdA has transitioned to a new nominal condition)
begin
nc;
end process;
instA : modA port map(clock => clk, num => data);
PowerDown : process
begin
-- Link link signal to nominal condition of power domain :pdA
lps_link_power_domain_nominal_condition(link_nc_pdA, :pdA);
mte
<= 00000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
June 2013
386

wait for 99 ns;
...
end Process;
end top_rtl;
June 2013
387

lps_link_power_domain_power_mode(link_signal[, power_domain]);
Links the link_signal to the current power mode of the power domain of interest.
The link_signal changes when the power domain transitions to a new power mode. If a
power mode does not exist for the power domain, the register will have a value of
UNDEFINED.
If the link_signal exists in a switchable power domain, the signal is corrupted when the
Arguments
link_signal
A signal of type string. The signal will be linked to the power

mode of the power domain of interest.
The signal must be large enough to hold any power mode name of
the power domain. To hold 512 characters, the signal must be
defined as:
An error is generated if the signal is too small for the power mode
name.
[power_domain]


Example
library NCUTILS;
...
June 2013
388

entity top is
end top;
...
signal clk
: std_logic;

...
-- Declare link signal of type string
signal link_pmA : string (20 downto 1):=11111111111111111111;
procedure pmode is
begin
DO_SOMETHING;
end pmode;
begin
process (link_pmA)
-- Execute procedure pmode when link_pmA changes value (i.e., when domain
-- :pdA has transitioned to a new power mode)
begin
pmode;
end process;
instA : modA port map(clock => clk, num
=> data);

PowerDown : process
begin
-- Link link signal to power mode of power domain :pdA
lps_link_power_domain_power_mode(link_pmA, :pdA);
mte
June 2013
<= 00000;
389

pseA <= 0; pseB <= 0;
aseA12 <= 1; aseB12 <= 1; aseT12 <= 1;
wait for 99 ns;
...
end Process;
end top_rtl;
June 2013
390

lps_link_power_domain_trans_latency(link_signal[, power_domain]);
Links the link_signal to the time it will take the power domain of interest to finish its
transition to a different nominal condition.
The link_signal is updated at the start of the transition for the power domain of interest.
is powered down.
The VHDL signal pointed to by the path in the link_signal must be of string type and
static.
Arguments
link_signal
Name or full path name of a VHDL signal of type real. The signal
will be linked to the time (in the timescale precision of the
simulation) needed by the power domain of interest to transition to
a new nominal condition.
[power_domain]


June 2013
391

lps_link_power_domain_trans_voltage(link_signal[, power_domain]);
Links the link_signal to the value of the voltage of the power domain of interest when
the transition to a new nominal condition has completed.
The link_signal changes at the start of a transition to a new nominal condition. The value
of the signal is the value at the end of the transition.
is powered down.
The VHDL signal pointed to by the path in the link_signal must be of string type and
static.
Arguments
link_signal
Name or full path name of a VHDL signal of type real. The signal
will be linked to the voltage of the power domain of interest, and its
value will be the voltage of the power domain at the end of the
transition. This signal will change when the power domain of
interest starts to transition.
[power_domain]


June 2013
392

lps_enabled(signal_name);
Assigns a value of 1 to the signal if low-power simulation has been enabled in the design with
the elaborator -lps_cpf option, and if the simulation option -lps_off is not used.
The procedure assigns a 0 to the signal if the design is not elaborated with low-power
simulation enabled, or if the simulator option -lps_off is used.
Arguments
signal_name
A signal of type integer.
Example
library NCUTILS;
...
entity tb is end;
architecture testtb of tb is
...
signal tclk : std_logic;
signal in1 : std_logic_vector(3 downto 0);
...
-- Signal to hold full path of power domain pdA
-- Signal to hold full path of power domain pdB
signal pwrDB : string (10 downto 1);
-- Signal to hold power-down state of domain pdA
signal link_pwrdownA : std_logic := 0;
-- Signal to hold power-down state of domain pdB
signal link_pwrdownB : std_logic := 0;
-- Signal for lps_enabled procedure
signal enabled : integer := 0;
begin
DO_SOMETHING;
end pwrdown;
June 2013
393

-- Link the power-down states of domains pdA and pdB to link signals
procedure enable_pd is
begin
-- Get full path of power domain that controls instance blk_inst1
lps_get_power_domain(pwrDA, blk_inst1);
--
-- Link signal link_pwrdownA to power-down state of power domain.

-- Use output of lps_get_power_domain as argument to
-- lps_link_power_domain_powerdown procedure
lps_link_power_domain_powerdown(link_pwrdownA, pwrDA);
-- Get full path of power domain that controls instance blk_inst2.
lps_get_power_domain(pwrDB, blk_inst2);
-- Link signal link_pwrdownB to power-down state of power domain.
-- Use output of lps_get_power_domain as argument to
-- lps_link_power_domain_powerdown procedure
lps_link_power_domain_powerdown(link_pwrdownB, pwrDB);
end enable_pd;
begin
-- If low-power simulation is enabled, execute procedure enable_pd
process (enabled)
begin
if enabled <= 1 then
enable_pd;
end if;
end process;
-- If signal link_pwrdownA is 1 or link_pwrdownB is 1 (i.e., if domain pdA or
-- domain pdB is about to be powered down), execute procedure pwrdown
process (link_pwrdownA, link_pwrdownB)
begin
if link_pwrdownA = 1 OR link_pwrdownB = 1 then
pwrdown;
end if;
end process;
blk_inst1 : blk port map (...);
blk_inst2 : blk port map (...);
...
June 2013
394

PowerDown : process
begin
-- Check to see if low-power simulation is enabled
lps_enabled(enabled);
mte
<= 000000;
pseA <= 0; pseB <= 0;

aseA12 <= 1; aseB12 <= 1; aseT12 <= 1; aseB05 <= 0;
wait for 99 ns;
...
end Process;
...
end testtb;
June 2013
395

lps_get_stime(signal_name);
Assigns the low-power simulation start time to the signal.
Arguments
signal_name
A signal of type time.
Example
entity TOP is
end entity TOP;
architecture RTL of TOP is
-- Declare signal of type time
signal lp_start_time : time := 0 ns;
...
procedure print_stime is
begin
write(vline, string(lp_start_time = )); write(vline, lp_start_time);
wrieline(output, vline);
end print_stime;
begin
-- Assign low-power simulation start time to signal lp_start_time
lps_get_stime(lp_start_time);
print_stime;
June 2013
396
Index
Symbols
Control signals
generating a coverage model for 312
verifying correct sequence 259
Corruption
disabling with set_sim_control 33
of top-level ports 82
of VHDL user-defined enumerated
types 83
Corruption of VHDL integers 90
Coverage model
automatic generation of 312
CPF file
specifying with -lps_cpf 232
$lps_enabled 357
$lps_get_power_domain 322
$lps_get_stime 358
$lps_link_power_domain_gnd_voltage 34
1
$lps_link_power_domain_nmos_voltage 3
42
$lps_link_power_domain_nominal_conditio
n 346
$lps_link_power_domain_pmos_voltage 3
43
$lps_link_power_domain_power_mode 35
3
$lps_link_power_domain_powerdown 327
$lps_link_power_domain_standby 332
$lps_link_power_domain_state 334
$lps_link_power_domain_trans_latency 3
55
$lps_link_power_domain_trans_voltage 3
56
$lps_link_power_domain_voltage 339
D
Debugging
infinite loops 300
Tcl commands 279
F
Feedthrough wires
48
A
Assertions
automatic generation of
I
259
Identifiers in CPF
converting to upper case 254
Infinite loops
debugging 300
Initial blocks
replaying on powerup 30
Isolation
back-to-back 142
Isolation information
logging 239
B
Back-to-back isolation 142
Boundary ports
specifying with -boundary_ports
-boundary_ports 71
71
C
L
Cells
excluding from state retention 231
Constants in shutoff control expression 78
Continuous assignments
treating as buffers 230
June 2013
Log file
specifying a name for
Logging 255
397
242
isolation information 239

output of -lps_verbose 241
-lps_alt_srr 230, 247
-lps_assign_ft_buf 230
-lps_blackboxmm 231
-lps_cellrtn_off 231
-lps_cpf 232
-lps_dtrn_min 232
lps_enabled 393
-lps_enum_rand_corrupt 233
-lps_enum_right 234
-lps_ft_graph 234
lps_get_power_domain 361
lps_get_stime 396
-lps_implicit_pso 235
-lps_implicitpso_char 236
-lps_implicitpso_nonchar 237
-lps_int_index_nocorrupt 237
-lps_int_nocorrupt 238
-lps_iso_off 239
-lps_iso_verbose 239
-lps_isofilter_verbose 240
-lps_isoruleopt_warn 241
lps_link_power_domain_gnd_voltage 380
lps_link_power_domain_nmos_voltage 38
1
lps_link_power_domain_nominal_condition
385
lps_link_power_domain_pmos_voltage 38
2
lps_link_power_domain_power_mode 388
lps_link_power_domain_powerdown 368
lps_link_power_domain_standby 373
lps_link_power_domain_state 375
lps_link_power_domain_trans_latency 39
1
lps_link_power_domain_trans_voltage 39
2
lps_link_power_domain_voltage 378
-lps_log_verbose 241
-lps_logfile 242
-lps_modules_wildcard 243
-lps_mtrn_min 243
-lps_mvs 244
-lps_no_xzshutoff 244
-lps_notlp 245
-lps_off 245
-lps_pmcheck_only 246
-lps_pmode 246
-lps_rtn_lock 247
-lps_rtn_off 249
June 2013
-lps_sim_verbose 250
-lps_simctrl_on 250
-lps_srfilter_verbose 251
-lps_srruleopt_warn 251
-lps_stdby_nowarn 252
-lps_stime 253
-lps_stl_off 254
-lps_upcase 254
-lps_verbose 255
-lps_verify 259
-lps_vplan 259
M
Macro models 205
black box and gray box 205
treating as black box 231
N
Non-volatile memory
modeling 33
P
Port isolation
turning off 239
Power mode simulation
controlling 246
suppressing informational
messages 250
Power-aware modeling 319
Verilog system tasks 320
$lps_enabled 357
$lps_get_power_domain 322
$lps_get_stime 358
$lps_link_power_domain_gnd_voltag
e 341
$lps_link_power_domain_nmos_volt
age 342
$lps_link_power_domain_nominal_c
ondition 346
$lps_link_power_domain_pmos_volt
age 343
$lps_link_power_domain_power_mo
de 353
$lps_link_power_domain_powerdow
n 327
398
$lps_link_power_domain_standby
332
$lps_link_power_domain_state 334
$lps_link_power_domain_trans_laten
cy 355
$lps_link_power_domain_trans_volta
ge 356
$lps_link_power_domain_voltage 3
39
VHDL procedures 359
lps_enabled 393
lps_get_power_domain 361
lps_get_stime 396
lps_link_power_domain_gnd_voltage
380
lps_link_power_domain_nmos_volta
ge 381
lps_link_power_domain_nominal_co
ndition 385
lps_link_power_domain_pmos_volta
ge 382
lps_link_power_domain_power_mod
e 388
lps_link_power_domain_powerdown
368
lps_link_power_domain_standby 3
73
lps_link_power_domain_state 375
lps_link_power_domain_trans_latenc
y 391
lps_link_power_domain_trans_voltag
e 392
lps_link_power_domain_voltage 37
8
State loss
and forced signals 94
turning off 254
State retention
excluding cells from 231
selecting targeted registers or
instances 97
specifying control conditions 101
turning off 249
with save or restore preconditions 105
with separate save and restore
controls 104
with single retention control 102
T
Tcl commands
for low power 279
-testbench option 27
Top-level ports
corruption of 82
V
VHDL enumerated types
corruption of 83
VHDL integers
corruption of 90
VPlan
automatic generation of
259
S
set_design command
-testbench option 27
set_sim_control command 29
disabling corruption 33
replaying initial blocks 30
Shutoff control expression
specifying a constant 78
Simulation-time control
enabling 250
Standby mode
input violation messages 252
Start time
specifying with -lps_stime 253
June 2013
399
June 2013
400

PowerForwardUG PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PowerForwardUG PDF

Uploaded by

Copyright:

Available Formats

Low-Power Simulation Guide (CPF)

Product Version 13.10

20062013 Cadence Design Systems, Inc. All rights reserved.

Low-Power Simulation Guide (CPF)

CPF Support in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 13.10

Low-Power Simulation Guide (CPF)

Specifying a Constant for a Shutoff Control Expression . . . . . . . . . . . . . . . . . . . . . . . . .

Selecting the Targeted Registers or Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Selecting Nets for Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 13.10

Low-Power Simulation Guide (CPF)

Controlling a Power Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Power Domain Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 13.10

Low-Power Simulation Guide (CPF)

Isolation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Writing a CPF Model for a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Running in Multi-Step Invocation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 13.10

Low-Power Simulation Guide (CPF)

Simulating an Example Design

Product Version 13.10

Low-Power Simulation Guide (CPF)

Specifying Power Information in the CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Simulating a Gate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tcl Command Enhancements for Low Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generating Assertions to Verify Power Control Signals . . . . . . . . . . . . . . . . . . . . . . . . .

Product Version 13.10

Low-Power Simulation Guide (CPF)

Product Version 13.10

Low-Power Simulation Guide (CPF)

Product Version 13.10

Low-Power Simulation Guide (CPF)

Encounter Conformal Low Power

Encounter Digital Implementation System

Encounter Power System

Encounter RTL Compiler

Encounter Test Architect

Encounter Timing System

Incisive Enterprise Manager

Incisive Enterprise Simulator

Product Version 13.10

Low-Power Simulation Guide (CPF)

How CPF is used in the tool

The tool command(s) related to CPF

When to read the CPF file in the tool flow

The CPF commands supported by the tool

For More Information

Common Power Format Language Reference

Common Power Format User Guide

Product Version 13.10

Low-Power Simulation Guide (CPF)

See Expressions in CPF Commands on page 42 for information on expressions in CPF

Product Version 13.10

Low-Power Simulation Guide (CPF)

CPF Support in Simulation

General CPF Command Support on page 14

Library Cell-Related CPF Command Support on page 24

General CPF Command Support

NA: not applicable to simulation

Product Version 13.10

Low-Power Simulation Guide (CPF)

Use one of the following forms: abc, abc, abc*def.