0% found this document useful (0 votes)

855 views348 pages

Power Forward Ug

Cadence Design Systems, Inc. (Cadence), 2655 seely avenue, San Jose, CA 95134, USA. Product NC-SIM contains technology licensed from, and copyrighted by: Free Software Foundation, Inc., Scriptics Corporation, and other parties. This publication is protected by copyright law and international treaties. Unauthorized reproduction or distribution of this publication, or any portion of it, may result in civil and criminal penalties.

Uploaded by

Santosh Nanduri

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

855 views348 pages

Power Forward Ug

Uploaded by

Santosh Nanduri

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 348

Low-Power Simulation Guide

Product Version 10.2 September 2011

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

Low-Power Simulation

Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
For More Information 11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 CPF Support

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14 14 23 25 26 28 29 35 37 40 41 47 49

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Expressions in CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feedthrough Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SystemVerilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VHDL Coding Style Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Using CPF for Designs Using Power Shutoff. . . . . . . . . . . . . . . . . .

Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Base and Derived Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Declaring Boundary Ports with the -boundary_ports Option . . . . . . . . . . . . . . . . . . . State Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying a Constant for a Shutoff Control Expression . . . . . . . . . . . . . . . . . . . . . . . Corruption of Top-Level Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55 58 59 63 69 70 70 70 73

September 2011

Product Version 10.2

Low-Power Simulation

Corruption of VHDL User-Defined Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . 75 State Loss and Forced Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Disabling Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 State Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Selecting the Targeted Registers or Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Identification of Sequential Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Specifying the Control Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Incomplete State Retention Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Selecting the Targeted Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Ignoring Isolation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Isolation Rule Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Controlling Isolation Enable and Disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Specifying Isolation Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Back-to-Back Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Specifying a Secondary Domain for an Isolation Rule . . . . . . . . . . . . . . . . . . . . . . . 121 Viewing Isolation Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Logging Isolation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4 Using CPF for Designs with DVFS

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Controlling a Power Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Power Mode Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Controlling Power Domain Transitions with Power Mode and Mode Transition Controls 129 Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Specifying the Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Describing the Power Mode Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Controlling Power Domain Transitions with Domain-Level Controls . . . . . . . . . . . . . . . 139 Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Specifying the Conditions for the Power Domains to Transition to Specific Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Specifying the Delay for a Power Domain to Reach its Destination Nominal Condition . 140 Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Power Mode Control Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
September 2011 4 Product Version 10.2

Low-Power Simulation

Default Power Mode Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 User-Created Power Mode Control Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5 Modeling a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Writing a CPF Model for a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Macro Model CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining the Macro Model Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

151 151 153 154 159 161 162 162 164 167

6 Running a Low-Power Simulation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 170 171 171 171 172 172 173 173 174 174 175 176 176 177 178 179 179 180

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_implicit_pso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_implicitpso_char value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_implicitpso_nonchar value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_iso_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_iso_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_isofilter_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
September 2011 5

Product Version 10.2

Low-Power Simulation

-lps_isoruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_log_verbose filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_logfile filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_modules_wildcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_mtrn_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_mvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_no_xzshutoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_notlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_pmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_pmcheck_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_rtn_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_rtn_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_simctrl_on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_srruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_sim_verbose report_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_stdby_nowarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_stime start_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_stl_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_upcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_verbose {1 | 2 | 3} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . -lps_vplan vplan_filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

181 181 182 182 183 183 184 184 185 185 186 187 188 188 189 189 190 190 191 191 192 196 196

7 Simulating an RTL-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Simulating an Example Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Power Information in the CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examining Simulation Results in the Waveform Window . . . . . . . . . . . . . . . . . . . . .

197 197 199 201 203

8 Simulating a Gate-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

207

Simulating a Gate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Defining Low-Power Cells Instantiated in the Netlist . . . . . . . . . . . . . . . . . . . . . . . . 208
September 2011 6 Product Version 10.2

Low-Power Simulation

Disabling the Implicit CPF Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Example CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Simulating a Mixed RTL/Gate Design with Instantiated Primitive Cells . . . . . . . . . . . . . 213

9 Debugging a Low-Power Simulation

. . . . . . . . . . . . . . . . . . . . . . . . . . 215 215 215 215 219 220 220 223 225 229 231 231 233 238 239 239 244 251 253 254 254 256

Debugging with SimVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking SimVision for Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opening the Power Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Power Sidebar in the Design Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Power Sidebar in the Source Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Power Sidebar in the Waveform Window . . . . . . . . . . . . . . . . . . . . . . . . . Using the Power Sidebar in the Schematic Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . Tracing Signals in a Power Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Assertion States during a Power Shutdown . . . . . . . . . . . . . . . . . . . . . . . . Debugging Power Modes with SimVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Power Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Power Mode Information in the Waveform Window . . . . . . . . . . . . . . . . . . Tcl Command Enhancements for Low Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Describing Low-Power Information for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Information about Power Domains and Power Modes . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 Advanced Low-Power Verification Features . . . . . . . . . . . . . . . . . .

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:

September 2011

Product Version 10.2

Low-Power Simulation 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

September 2011

Product Version 10.2

Low-Power Simulation

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 37 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_*} create_power_domain -name PD1 \ -instances {mcore0/ahb0 \ mcore?/*/dsu0 \ mcore*/?/dcom0 \ mcore0/as*/asm \ mcore0/uart?} \ -shutoff_condition {...}

September 2011

Product Version 10.2

Low-Power Simulation 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 40.

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 23

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

September 2011

Product Version 10.2

Low-Power Simulation 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
assert_illegal_domain_configurations create_analysis_view create_assertion_control -assertions -domains -exclude -name -shutoff_condition -type create_bias_net create_global_connection create_ground_nets create_isolation_rule -exclude -from -isolation_condition -isolation_output -isolation_target -name -no_condition -pins -secondary_domain -to

Valid in Comment CPF Version

-1.0 -------1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 -1.0 -1.0 -1.1

Support Status
U U

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 -1.1 See create_assertion_control

S S S U S S S NA NA NA

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 -isolation_output tristate is not supported. See Back-to-Back Isolation See Isolation

S S S S S S S S S S S

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Command Options
create_level_shifter_rule create_mode_transition -clock_pin -end_condition -cycles -from -from_mode -latency -name -start_condition -to -to_mode create_nominal_condition -ground_voltage -nmos_bias_voltage -name -pmos_bias_voltage -state -voltage

Valid in Comment CPF Version

1.0 1.0 1.0 1.0 1.0 -1.0 1.0 1.0 1.0 -1.0 1.0 -1.0 1.0 1.0 -1.0 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 --Replaced with -from in CPF 1.0e See Describing the Power Mode Transitions

Support Status
U S U S U S U S S S S

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 --Replaced with -to in CPF 1.0e See Defining the Nominal Conditions

U S U U S U S S

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Command Options
create_operating_corner create_power_domain -active_state_conditions -base_domains -boundary_ports -default -default_isolation_condition -default_restore_edge -default_restore_level -default_save_edge -default_save_level -external_controlled_shutoff -instances -name -power_up_states -secondary_domains -shutoff_condition create_power_mode -default -domain_conditions -group_modes -name

Valid in Comment CPF Version

1.0 1.0 --1.0 1.0 -1.0 -1.0 --1.0 1.0 1.0 -1.0 1.0 1.0 1.0 -1.0 1.0e 1.1 1.0e 1.1 1.0e 1.1 -1.1 See Power Domains

Support Status
U S S S S S S S S S S S S S U

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e -1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 See Specifying the Power Modes Replaced with -base_domains in CPF 1.1

S S S S S S S

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Command Options
create_power_nets create_power_switch_rule create_state_retention_rule

Valid in Comment CPF Version

1.0 1.0 1.0 1.0e 1.1 1.0e 1.1 1.0e 1.1

1.0 1.0 1.0 -1.0e 1.1 1.0e 1.1 1.0e 1.1 --This command has been proposed for CPF 2.0. It is not included in the CPF 1.1 specification. No documentation is available in the CPF Language Reference. See set_sim_control.

Support Status
U U U S

-action power_up_replay -action disable_corruption -action disable_isolation -action disable_retention -controlling_domain -domains -exclude -instances -lib_cells -modules -targets

------------

-----------Note: In CPF 1.1, the option is -target. In CPF 2.0, the option is -targets.

S S U U S U S S U S S

-type set_switching_activity set_time_unit {ms | ns | us}

-1.0 1.0 1.0

S U S S

1.0e 1.1 1.0e 1.1 1.0e 1.1

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Command Options
set_wire_feedthrough_ports update_isolation_rules update_level_shifter_rules update_nominal_condition update_power_domain

Valid in Comment CPF Version

-1.0 1.0 1.0 1.0 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1

Support Status
U U U U

See Specifying the Delay for a S Power Domain to Reach its Destination Nominal Condition U U Replaced with -primary_ground_net in CPF 1.0e Replaced with -primary_power_net in CPF 1.0e No replacement Replaced with -transition_latency and -transition_cycles in CPF 1.0e U

-equivalent_ground_nets -equivalent_power_nets -internal_ground_net

--1.0

----

1.1 1.1 --

-internal_power_net

1.0

-library_set -max_power_up_time -min_power_up_time -name -nmos_bias_net -pmos_bias_net -primary_ground_net -primary_power_net -rail_mapping -transition_cycles -transition_latency -transition_slope -user_attributes update_power_mode update_power_switch_rule update_state_retention_rules

1.0 1.0 1.0 1.0 1.0 1.0 --1.0 ---1.0 1.0 1.0 1.0

----

U U U S U U U U

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 --No replacement

U U U S U U U U

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Library Cell-Related CPF Command Support

1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1 1.0e 1.1

set_hierarchy_separator
The set_hierarchy_separator command specifies the hierarchy delimiter character used in the CPF file. The default hierarchy separator is the period ( . ). Other supported characters are:

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

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, and no documentation is available yet in the CPF Language Reference. 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.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

# File top.cpf set_cpf_version 1.0e set_hierarchy_separator / set_design tb_top -testbench [CPF commands for testbench. Does not include the definition of a default power domain.] set_instance dut_inst set_design dut [CPF commands for DUT. end_design end_design # File dut.cpf set_cpf_version 1.0e set_hierarchy_separator / set_design dut [CPF commands for DUT] end_design # File top.cpf set_cpf_version 1.0e set_hierarchy_separator / set_design tb_top -testbench [CPF commands for testbench. Does not include the definition of a default power domain.] set_instance dut_inst source dut.cpf end_design

See Example 2: Carving out Different Power Domains from a Single Behavioral Model on page 65 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)

September 2011

Product Version 10.2

Low-Power Simulation 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. The following table shows the current simulator support for the -domain_mapping option:

Mapping Type Macro model blocks

IES Support Can map power domains in the macro cell to domains in the parent level scope. When you instantiate a macro cell, such as a RAM, in the design, you must specify how the domains of the CPF macro model are mapped to the domains of the parent level. Use the following format to specify a domain mapping:
-domain_mapping {domain_in_child_scope domain_in_parent_level_scope}

See Integrating the Macro Model on page 164 for an example.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

Mapping Type Other blocks (non-macro cell blocks)

IES Support Can map power domains in the block only to domains at the top-level testbench.
-domain_mapping {domain_in_child_scope domain_in_top_level_testbench}

Mapping a block-level domain to a domain in a scope other than the testbench is not supported. In a hierarchical CPF file, general domain mapping, in which a (non-macro cell) block-level domain is mapped to a domain in a scope other than the testbench, is not supported. For these situations, you must run the Conformal Low Power CPF Integrator. This tool reads in a hierarchical CPF file and creates a flat CPF file in which the power domains have been merged. See the chapter Low Power Diagnosis in the Encounter Conformal Low Power User Guide for details on the CPF Integrator.

set_sim_control
Note: This is a new CPF command that has been proposed for CPF 2.0. No documentation is available in the CPF Language Reference. 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 is available with CPF 1.1 or later.

Disable the default simulation corruption semantics for specified Verilog reg type variables so that you can model non-volatile memory. The option to enable this feature is -action disable_corruption. See Disabling Corruption of Verilog reg Variables on page 33. Note: The set_sim_control -action disable_corruption feature is available is available with CPF 2.0.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support 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 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*}

September 2011

Product Version 10.2

Low-Power Simulation CPF Support 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.

For example:
# Disable the corruption of all regs in instances tb_top.dut and dut2 only set_sim_control -action disable_corruption -type reg \ -instances {tb_top.dut dut2} # Disable the corruption of regs q1 and q2 in instances tb_top.dut and dut2 only set_sim_control -action disable_corruption -type reg \ -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 regs are selected only from the instances of the specified modules. Module names can contain wildcards. When -modules is specified, -targets is optional.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

If -targets is not specified, all regs in all instances of the specified modules are selected. If -targets is specified, the target regs in all instances of the specified modules are selected.

For example:
# Disable corruption of all regs in all instances of modules mod1 and mod2 set_sim_control -action disable_corruption -type reg \ -modules {mod1 mod2} # Disable corruption of regs q1 and q2 in all instances of modules mod1 and mod2 set_sim_control -action disable_corruption -type reg \ -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 set_sim_control -action disable_corruption -type reg \ -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. set_sim_control -action disable_corruption -type reg \ -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. set_sim_control -action disable_corruption -type reg \ -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.
35 Product Version 10.2

September 2011

Low-Power Simulation CPF Support

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. 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]} ... ... create_assertion_control -name ac1 \ -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] }

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

create_power_domain -name PD_mux \ -instances {mux} \ -shutoff_condition {u_pmc/pso_en[3] & u_pmc/cond_3[3]} create_assertion_control -name ac1 \ -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:
-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 end else temp <= a + b; <= b00000000; resetchk: assert (reset) $display("Reset is now active"); //Immediate assertion

Product Version 10.2

Low-Power Simulation CPF Support

top dut1 D 1 Q1 D1 Q1

dout1

Q2 Q3

dout2 dout3

D 3

dout4

Consider the following assignment statements: Verilog

assign Q1 = !D1;

VHDL
Q1 <= NOT D1; /* Because of the load that drives to Q1, D1 is corrupted inside dut1 when the power domain is powered down. */

assign Q2 = D2;

Q2 <= D2;

/* 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. */ /* 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. */

assign Q3 = !D3;

Q3 <= NOT D3;

assign Q4 = D3;

Q4 <= D3;

/* 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. */

September 2011

Product Version 10.2

Low-Power Simulation CPF Support 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

assign outp = inp;

VHDL
outp <= inp;

Bit-selects Verilog
assign outp[1] = inp; assign outp = inp[1]; assign outp[1] = inp[2];

VHDL
outp(1) <= inp; outp <= inp(1); outp(1) <= inp(2);

Part-selects Verilog
assign outp[1:2] = inp; assign outp = inp[5:4]; assign outp[1:2] = inp[5:4];

VHDL
outp(1 to 2) <= inp; outp <= inp(5 downto 4); outp(1 to 2) <= inp(5 downto 4);

Assignments with a delay Verilog

assign out = #1 in;

VHDL
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. Verilog
assign outp = {inp, inp, inp, inp}; assign outp = {inp1, inp2, inp3, inp4 assign out = {in[0], in[1]}; assign out = {in1[0], in1[2], in1[3:0]; assign out[7:4] = {in[3:1], in[0]}; assign {out1, out2} = in1; assign {out1, out2} = {in1, in2};

VHDL
outp <= inp & inp & inp & inp; outp <= inp1 & inp2 & inp3 & inp4; out <= in(0) & in(1); out <= in1(0) & in1(2) & in1(3 downto 0); out(7 downto 4) <= a(3 downto 1) & a(0);

Note: The following assignment using the Verilog replication operator is not supported in the current release:
assign outp = { 4{inp} };

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

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

sig2

sig4[3:1]

sig3

Verilog
assign sig1_tmp = sig1; assign sig2_tmp = sig2; assign sig3_tmp = !sig3;

VHDL
sig1_tmp <= sig1; sig2_tmp <= sig2; sig3_tmp <= NOT sig3; sig_concat <= sig3_tmp & sig2_tmp & sig1_tmp;

assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp};

assign sig4[3:1] = sig_concat;

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. The path from sig1 to sig6 is not a feedthrough.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

The path from sig2 to sig4[2] is not a feedthrough.

sig6

sig5

sig1

sig2

sig4[3:1]

sig3

Verilog
assign sig6 = !sig1; assign sig5 = sig1; assign sig1_tmp = sig1; assign sig2_tmp = !sig2; assign sig3_tmp = sig3;

VHDL
sig6 <= NOT sig1; sig5 <= sig1; sig1_tmp <= sig1; sig2_tmp <= NOT sig2; sig3_tmp <= sig3; sig_concat <= sig3_tmp & sig2_tmp & sig1_tmp;

assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp};

assign sig4[3:1] = sig_concat;

sig4(3 downto 1) <= sig_concat;

Hierarchical connections from upper to lower modules are supported, as illustrated in the following figure.

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

PD1 PD2 PD3

I N P U T S

O U T 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

September 2011

Product Version 10.2

Low-Power Simulation 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

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
SystemVerilog interfaces and modports are supported at the power domain boundary or within a power domain. Note: While SystemVerilog interfaces are supported, SystemVerilog constructs used in the interface (for example, program blocks, clocking blocks, data types such as logic, bit, byte, int, and so on) are not supported. 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:
tbench dut intf_inst inst1(intf_inst) inst2(intf_inst) u_pmc // Interface instance // Module instance (in power domain PD1) // Module instance (in power domain PD2)

The Verilog code is as follows:

September 2011

Product Version 10.2

Low-Power Simulation 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 create_power_domain -name PD1 \ -instances inst1 \ -shutoff_condition {u_pmc.pso_en[0]} create_power_domain -name PD2 \ -instances inst2 \ -shutoff_condition {u_pmc.pso_en[1]} end_design

Interfaces within a Power Shut Off Domain In this case, the interface is within a power domain. For example:

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

tbench dut intf_inst inst1(intf_inst) inst2(intf_inst) u_pmc // Power domain PD1 // Interface instance // Module instance // Module instance

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 \ -shutoff_condition {u_pmc.pso_en[0]} 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
September 2011 49 Product Version 10.2

Low-Power Simulation 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.

September 2011

Product Version 10.2

Low-Power Simulation 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'; out2 <= 2; out3 <= "1100"; -- Scalar constant -- Integer -- Vector -- Aggregate onstant definition -- Part-select / Bit-select

out4 <= (others => '1'); out5(4 downto 2) <= "010"; out6 <= G1; end architecture RTL;

-- Assignment from generics

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
September 2011 51 Product Version 10.2

Low-Power Simulation 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 Q := 0; -- Asynchronous reset

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

elsif rising_edge(Clk) then if Load = '1' then Q := to_uint(Data); elsif Q = 15 then Q := 0; else Q := Q + 1; end if; end if; Count <= to_vector(4,Q); end process; end architecture count16a; -- Convert integer to vector -- for use outside the process -- Convert vector to integer

September 2011

Product Version 10.2

Low-Power Simulation CPF Support

September 2011

Product Version 10.2

Low-Power Simulation

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Figure 3-1 Example of Design with PSO
top PD1 PD2 inst_A inst_B

inst_C

PD3

inst_D

pm_inst
ice_enable pge_enable pse_enable

See Power Domains on page 58 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. See State Loss on page 69 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 State Retention on page 82 for information on specifying state retention rules in the CPF file.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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 Isolation on page 100 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.

Power Domain
power switch

Control Signals
isolation state retention

PD1 PD2 PD3

no control signal ps_enable[0] ps_enable[1]

no control signal ice_enable[0] ice_enable[1]

no control signal pge_enable[0] 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 257 for details on the correct transition sequence of the power control signals, and for information on the
September 2011 57 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff -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 56.
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 154 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.
September 2011 58 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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 59 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 63 for details on this option.

Base and Derived Power Domains

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Figure 3-3 Derived Power Domain with a Base Power Domain - Example 2

create_power_domain -name PD_ON \ -instances ...

create_power_domain -name PD \ -default \ -shutoff_condition A \ -instances ...

create_power_domain -name PD1 \ -shutoff_condition B \ -instances ... \ -base_domains PD

create_isolation_rule -name ISO1 \ -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 63, power domain PD3 has two base power domains, PD1 and PD2. Domain PD2 is specified as the secondary domain for the state retention logic.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Figure 3-4 Derived Power Domain with Multiple Base Power Domains
VDD1 VDD2

SW SW SW

PD1 C SW VDDSW

PD2

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:

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Example 1: Signal Driven from PD1 to PD2, with a Load Inside PD2

PD4 PD1 A PD2 B

pd1_inst PD3

pd2_inst

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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_TB addr data_in A testbench we ce RAM (IP block) PD_SW B B PD_CORE PD_ON

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

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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 75 for details.

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.
#IP.cpf ... ... set_design IP -ports {top_pwr} -default -shutoff_condition {top_pwr} ... ... # Create a virtual port

create_power_domain -name {PD_default} \

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:

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

# 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 ... ... 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:
September 2011 71 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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, 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 set_time_unit 1.1 "ns" # Create two virtual ports set_hierarchy_separator "/"

set_design IP -ports {pso1 pso2} -default create_power_domain -name {PD_1} \

create_power_domain -name {PD_default} \

-instances {inst_level_2_1} \ -shutoff_condition {pso1} \ -base_domains {PD_default}

September 2011 72 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

create_power_domain -name {PD_2} \ -instances {inst_level_2_2} \ -shutoff_condition {pso2} \ -base_domains {PD_1} end_design

#top.cpf set_cpf_version set_time_unit 1.1 "ns" set_hierarchy_separator "/"

set_design top -testbench set_instance ip_inst -port_mapping {{pso1 pso1} {pso2 0}} source IP.cpf end_design

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

TB PDD A B C D 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.
create_power_domain -name PDD -default create_power_domain -name 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. 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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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:

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

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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:

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 78 for more information.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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). -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;

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using 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> => when STATE_0 => ... when STATE_1 => ... ... other choices ... end case; -- Implicitly-added choice with no statements

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 TRIGHT THIGH TIMAGE(X)

Behavior with Implicit Literal Simulator ignores the implicitly-added literal, and returns the literal that lies just to the left of the right-most (implicit) literal. Simulator ignores the implicitly-added literal, and returns the literal that is one less than the highest (implicit) position number. 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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Attribute TVALUE(X)

Behavior with Implicit Literal 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.

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Attribute TRIGHTOF(X)

Behavior with Implicit Literal 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.

State Loss and Forced Signals

When a power domain is powered down, all signals, wires, sequential elements, and variables are forced to X. 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. 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 Verilog reg type variables so that you can model non-volatile memory. By default, 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. For example, the following command disables corruption for target objects q1, q2, and q3, which are of type reg.
set_sim_control -action disable_corruption -type reg \ -targets {q1 q2 q3}

See Disabling Corruption of Verilog reg Variables for details.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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.

-domain power_domain Selects all registers in the specified power domain.

create_state_retention_rule -name SR_rule1 \ -domain {PD1} \ ...

-instances instance_list Selects all registers in the specified instances.

create_state_retention_rule -name SR_rule1 \ -instances {A/B/I1} \ ...

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

create_state_retention_rule -name SR_rule1 \ -instances {A/B/a_reg A/B/b_reg} \ ...

Use the -exclude instance_list option to exclude specific instances from the list selected with -domain or -instances. Note: 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:
create_state_retention_rule -name SR_rule1 \ -domain PD1 \ -exclude {test/u1/reg3 test/u1/reg4 test/u1/reg5} \ ... create_state_retention_rule -name SR_rule2 \ -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.

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. In many cases, however, a more general rule using -domains or wildcards is written, and 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

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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. If all of the elements specified in a create_state_retention_rule command are determined to be combinational, 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. 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. 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:
create_state_retention_rule -name SR_rule1 \ -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:
create_state_retention_rule -name SR_rule1 \ -instances {A/B/*_reg} \ ...

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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'

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'

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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:

A single retention control. See Modeling State Retention with a Single Retention Control on page 86. Separate save and restore controls. See Modeling State Retention with Separate Save and Restore Controls on page 88. 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 89.

A state retention rule can be specified without a save or restore condition. See Incomplete State Retention Rules on page 99 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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff In the following figure, the retention control signal is called pg.
Retention control becomes active and power is on Retention control becomes inactive

Power off

Power on

Region 1

Region 2

Region 3

Retention mode with power on

Retention mode with power off

Retention mode with power on

Using -restore_edge In the example shown in Figure 3-1 on page 56, 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]} create_state_retention_rule -name st2 -domain PD3 \ -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.
create_state_retention_rule -name st1 -domain PD2 \ -save_edge {pm_inst.pge_enable[0]} create_state_retention_rule -name st2 -domain PD3 \ -save_edge {pm_inst.pge_enable[1]}

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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 Restore is Restore is active inactive

Power off

Power on

Region 1 sr_save

Region 2

Region 3 Retention mode with power off

Region 4 Retention mode with power on

Region 5

Retention mode with power on

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.
create_state_retention_rule -name st1 -domain PD2 \ -save_level {sr_save} \ -restore_level {sr_restore}

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Save is active

Save is inactive

Power off

Power on

Restore is Restore is active inactive

Region 1 sr_save

Region 2

Region 3

Region 4

Region 5

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}

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Save condition and save precondition are both true

Power off

Power on

Retention control becomes inactive

Region 1

Region 2

Region 3

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:
Precondition is always false Power off Retention control becomes inactive

Save condition is true

Power on

Region 1

Region 2

Region 3

pg rst Save

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Save condition is true

Precondition is false

Power off

Power on

Retention control becomes inactive

Region 1

Region 2

Region 3

pg rst Save

Region 3

pg rst Save No restore

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.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff You must use the simulator -lps_alt_srr option to enable this behavior (ncsim -lps_alt_srr or irun -lps_alt_srr). For example:
Restore condition is true Save condition is true Power off Power on Restore precondition becomes false

Region 1

Region 2

Region 3

pg rst Save Corrupt values in shadow register Restore

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:
create_state_retention_rule -name SR1 \ -save_level {sr_save} \ -restore_level {sr_restore} \ -save_precondition {rst}

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Save condition and save precondition are both true

Power off

Power on

Restore is Restore is inactive active

Region 1 sr_save

Region 2

Region 3

Region 4

Region 5

sr_restore

rst Save Restore values

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:

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:
create_state_retention_rule -name SR1 \ -save_level {sr_save} \ -restore_level {sr_restore} \ -restore_precondition {rst}

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Restore condition Restore condition is false is true Save condition is true Power off Power on Restore precondition is true Region 1 sr_save Region 2 Region 3 Region 4 Region 5

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.
Restore condition Restore condition is false is true

Save condition is true

Power off

Power on Restore precondition becomes false

Region 1 sr_save

Region 2

Region 3

Region 4

Region 5

sr_restore rst

Save

No restore

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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. You must use the simulator -lps_alt_srr option to enable this behavior (ncsim -lps_alt_srr or irun -lps_alt_srr). For example:
Restore condition Restore condition is false is true

Save condition is true

Power off

Power on Restore precondition becomes false

Region 1 sr_save

Region 2

Region 3

Region 4

Region 5

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:

For a single retention control, where both -save_edge and -restore_edge are not specified.

September 2011

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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.

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.

September 2011

100

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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.

Selecting the Targeted Nets

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. For an isolation rule with only a -from option, isolation will be placed at the output pin of the from domain unless doing so would violate other conditions of the isolation rule. If so, isolation is placed on a different pin that supports isolating the valid net segments.

-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. For an isolation rule with only a -to option, isolation will be placed at the input pin of the to domain unless doing so would violate other conditions of the isolation rule. If so, isolation is placed on a different pin that supports isolating the valid net segments.

-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. For an isolation rule with both a -from and a -to option, isolation will be placed at the input pin of the to domain unless doing so would violate other conditions of the isolation rule. If so, isolation is placed on a different pin that supports isolating the valid net segments.

September 2011

101

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

-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. Note: The -pins option must always be used with the -from, -to, or -from -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 and E will be isolated if there is a load in PD2 and a driver in another power domain. Isolation will be placed on the specified pin(s) unless doing so would violate the other conditions of the isolation rule. If so, isolation is placed on a different pin that supports isolating the valid net segments.

-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

September 2011

102

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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*

Either a -to or a -from option. With -force, no driver or load analysis is performed, so the -to or -from filters are ignored. These options are required because, according to the CPF specification, all isolation rules require a -to, a -from, or both.

A create_isolation_rule with a -force is ignored with an ISOFRC warning if:

Both -to and -from are specified The -exclude option is present The -no_condition option is present

Ignoring Isolation Rules

An isolation rule is ignored 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

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
September 2011 103 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff to a domain that is powered on. The isolation value (see Specifying Isolation Values on page 117) 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, the following CPF rule will not insert isolation:
create_isolation_rule -name foo -to PD2 -pins I1/A ....

Examples The following example illustrates the effect of the -from, -to, and -from -to options on the selection of nets to be isolated. In this design:

Instances I1 and I2 belongs to power domain PDA Instance I3 belongs to power domain PDB. Instance I4 belongs to power domain PDC.

September 2011

104

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

top

I1 A D E B

PDA

I3 F C I G H PDB

I4 J PDC

September 2011

105

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

Table 3-1 Effect of -from, -to, and -from -to Options Isolation Rule
create_isolation_rule -name iso1 \ -from PDA \ ...

Net Segments Selected Isolate net segments driven by logic in the specified from domain and with a load in another domain. If possible, isolation is placed at the output of the from domain. This rule isolates net segments:

CG and CJ. Isolation is placed at pin C. BF. Isolation is placed at pin F. Isolation cannot be placed at pin B because this would isolate net segment BE.

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.
create_isolation_rule -name iso2 \ -to PDB \ ...

Isolate net segments driving logic in the specified to domain and that are driven by logic from another power domain. If possible, isolation is placed at the input of the to domain. This rule isolates net segments:

BF. Isolation is placed at pin F. CG. Isolation is placed at pin G.

Ignore this rule for the net connected to pin H because it is driven by a tie-low signal that is not in a switchable domain.

September 2011

106

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Table 3-1 Effect of -from, -to, and -from -to Options Isolation Rule
create_isolation_rule -name iso3 \ -from PDA -to PDC \ ...

Net Segments Selected Isolate net segments that drive logic in the specified to domain and that are driven by logic in the specified from domain. If possible, isolation is placed at the input of the to domain. This rule isolates net segment CJ. Isolation is placed at pin J.

The following example illustrates the effect of the -pins, -exclude, and -force options on the selection of net segments to be isolated.

September 2011

107

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

PD1 B A

PD1

PD2 C D E G F H

Table 3-2 Effect of -pins, -exclude, and -force Options Isolation Rule
create_isolation_rule -name ISO1 \ -from PD1 \ -pins {A} \ ...

Net Segments Selected Isolate net segments that drive or connect to pin A, and that also meet the requirements of the -from option. This rule isolates net segment AC. Isolation cannot be placed at the specified pin (A) because this would also isolate net segment AB. Isolation is placed at pin C.

create_isolation_rule -name ISO1 \ -from PD1 \ -pins {B} \ ...

Isolate net segments that drive or connect to pin B, 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 B has a driver in the specified from domain, the load connected to pin B is in the same power domain.

September 2011

108

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Table 3-2 Effect of -pins, -exclude, and -force Options Isolation Rule
create_isolation_rule -name ISO1 \ -from PD1 \ -pins {F} \ ...

Net Segments Selected Isolate net segments that drive or connect to pin F, and that also meet the requirements of the -from option. No isolation is inserted. The net segment driving pin F 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 C and E, and that also meet the requirements of the -to option. This rule isolates net segments AC and DE. Isolation is placed at pins C and E.

create_isolation_rule -name ISO1 \ -to PD2 \ -pins {C,E} \ ...

create_isolation_rule -name ISO1 \ -to PD2 \ -pins {B} \ ...

Isolate net segments that are driven by or connected to pin B, and that also meet the requirements of the -to option. No isolation is inserted. This rule does not meet the requirements of the -to option. The net segment driven by pin B does not have a load in the specified to domain. Isolate net segments that are driven by or connected to pin G, and that also meet the requirements of the -to option. This rule isolates net segment DG. Isolation is placed at pin G.

create_isolation_rule -name ISO1 \ -to PD2 \ -pins {G} \ ...

create_isolation_rule -name ISO1 \ -to PD2 \ -pins {H} \ ...

Isolate net segments that are driven by or connected to pin H, and that also meet the requirements of the -to option. This rule isolates net segment DH. Isolation is placed at pin H.

September 2011

109

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Table 3-2 Effect of -pins, -exclude, and -force Options Isolation Rule
create_isolation_rule -name ISO1 \ -from PD1 \ -exclude {B} \ ...

Net Segments Selected 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 B. This rule isolates net segments:

AC. Isolation cannot be placed at pin A because this would also isolate segment AB, so isolation is placed at pin C. DE and DG. Isolation is placed at pin D.

create_isolation_rule -name ISO1 \ -from PD1 \ -exclude {G} \ ...

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 G. This rule isolates net segments:

AC. Isolation cannot be placed at pin A because this would also isolate segment AB, so isolation is placed at pin C. DE. Isolation cannot be placed at pin D because this would also isolate segment DG, so isolation is placed at pin E.

create_isolation_rule -name ISO1 \ -from PD1 \ -pins {D} \ -exclude {G} \ ...

Isolate net segments that drive or connect to pin D, and that also meet the requirements of the -from option. Exclude net segments connected to, driven by, or driving pin G. This rule isolates net segment DE. Isolation cannot be placed at the specified pin (D), so isolation is placed at pin E.

September 2011

110

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Table 3-2 Effect of -pins, -exclude, and -force Options Isolation Rule
create_isolation_rule -name ISO1 \ -to PD2 \ -pins {G} \ -exclude {H} \ ...

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

create_isolation_rule -name ISO1 \ -from PD1 \ -pins {F, B} -force \ ... create_isolation_rule -name ISO1 \ -from PD1 \ -pins {D} -force \ -exclude {E} \ ... create_isolation_rule -name ISO1 \ -from PD1 -to PD2 \ -pins {D} -force \ ...

Force isolation at pins F and B. Isolation is placed at the specified pins. No driver/load analysis is performed. This rule is ignored with an ISOFRC warning. Cannot use -exclude with -force.

This rule is ignored with an ISOFRC warning. Cannot use both -from and -to with -force.

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 a -force option Isolation rule with either a -pins option and/or a -exclude option Isolation rule with both -from and -to options Isolation rule with either a -from or -to option

September 2011

111

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff If multiple isolation rules have the same priority level, 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. Isolation 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.

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

September 2011

112

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

TB PDD PD1 A M B C N D DUT PD2

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.

September 2011

113

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

set_design TB -testbench create_isolation_rule -name ... \ -to PD1 \ -isolation_condition ... \ -isolation_output ...

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.
create_isolation_rule -name ... \ -from PD2 \ -isolation_condition ... \ -isolation_output ...

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

September 2011

114

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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

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 create_isolation_rule -name ... \ -to PD_ip2 \ # Must be a load in PD_ip2 and a driver in another domain.

-isolation_condition ... \ -isolation_output ...

TB IP1 A PD_ip1 B C PD_ip2 IP2 D

September 2011

115

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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:
create_isolation_rule -name iso1 \ -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:
create_isolation_rule -name iso1 \ -from PDA \ -no_condition \ ...

118

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff Back-to-back isolation is placed based on the -isolation_target option in the two create_isolation_rule commands. The simulator detects that multiple isolations is requested at the same power domain boundary, and places two isolation cells at the same point. The two devices are placed based on the value of the -isolation_target option. In rule ISOfrom, -isolation_target from indicates that isolation should be on when the domain of the driver (PD1) is off. In rule ISOto, -isolation_target to indicates that isolation should be on when the domain of the load(s) (PD2) is off.

PDD (default domain, AON) PDO (AON) PD1 (SW, Stby) ISOfrom ISOto PD2 (SW, Stby)

iso1

iso2

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

September 2011

119

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff 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. The CPF file includes the following rules:
create_isolation_rule -name ISO1 \ -from PD1 -to PD2 \ -isolation_target from \ -isolation_output high \ -isolation_condition p1.iso1 create_isolation_rule -name ISO2 \ -from PD1 -to PD2 \ -isolation_target to \ -isolation_output low \ -isolation_condition p1.iso2 create_isolation_rule -name ISO3 \ -from PD2 -to PD1 \ -isolation_target to \ -isolation_output high \ -isolation_condition p1.iso3 create_isolation_rule -name ISO4 \ -from PD2 -to PD1 \ -isolation_target from \ -isolation_output low \ -isolation_condition p1.iso4

In this example, the isolation device placed at p2.in1 supports both isolation rules ISO1 and iSO2. The isolation device placed at p2.out1 supports both isolation rules ISO3 and ISO4.

September 2011

120

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

PDD (default domain, AON) PDO (AON) PD1 (SW, Stby) PD2 (SW, Stby)

in1 ISO1/ISO2

out1 ISO4/ISO3

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.

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.

September 2011

121

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff According to the CPF 1.1 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.

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.
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:
September 2011 122 Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

-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:
Iso rule at source: Iso output: test.cpf:18 (test.t1.p1.out1) low Iso control condition:

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

Iso control condition:

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 either driver or load requirements for isolation. 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:
-lps_isofilter_verbose (Writes isolation filtering information to the default log file)

September 2011

123

Product Version 10.2

Low-Power Simulation Using CPF for Designs Using Power Shutoff

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

September 2011

124

Product Version 10.2

Low-Power Simulation

4
Using CPF for Designs with DVFS
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.

September 2011

125

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS 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 \ -voltage 1.0 -state on # Create power modes create_power_mode -name M1 \ -domain_conditions {PD1@high PD2@low} create_power_mode -name M2 \ -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 129 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 \ -voltage 1.2 -state on

September 2011

126

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

create_nominal_condition -name low \ -voltage 1.0 -state on # Specify active state conditions create_power_domain -name PD \ -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 139 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. 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.

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.

-lps_pmode This option turns on power mode simulation, mode tracking, and built-in mode checking, in addition to voltage tracking.

September 2011

127

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS 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 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 ....

-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 4-1 on page 129 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.

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.
September 2011 128 Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS Figure 4-1 Power Mode Example

top

pdT

instA pseA

pdA instB

pdB pseB

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. 2. Specify the power modes. 3. Describe the legal power mode transitions. 4. Specify the time it takes for power domains to transition from one nominal condition to another nominal condition.

Defining the Nominal Conditions

To specify the nominal conditions, use the create_nominal_condition command.

September 2011

129

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS Syntax:

create_nominal_condition -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 \ -voltage 0.8 -state on create_nominal_condition -name NC_12 \ -voltage 1.2 -state on 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. 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.
September 2011 130 Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS 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 142 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 4-2 Legal Power Modes

Power Mode

Corresponding Power Domains and Nominal Conditions pdT pdA NC_08 NC_OFF NC_12 NC_OFF pdB NC_OFF NC_08 NC_12 NC_OFF

M1 M2 M3 M4

NC_08 NC_08 NC_12 NC_08

September 2011

131

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

Power Mode

Corresponding Power Domains and Nominal Conditions pdT pdA NC_12 pdB NC_STANDBY

NC_12

The power modes shown in the table are specified with the following create_power_mode commands:
create_power_mode -name M1 \ -domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF} create_power_mode -name M2 \ -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. create_power_mode -name M3 \ -default \ -domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_12} create_power_mode -name M4 \ -domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF} create_power_mode -name M5 \ -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. Use the create_mode_transition command to describe the legal mode transitions.

September 2011

132

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS Syntax:

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

September 2011

133

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS Figure 4-3 Legal Power Mode Transitions

M1 mte[1] mte[5]

mte[2]

mte[4]

mte[6] M4 mte[3] M3 M5

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:
create_mode_transition -name mt1 \ -from M3 -to M1 \ -start_condition {pmc.mte[1]} create_mode_transition -name mt2 \ -from M1 -to M4 \ -start_condition {pmc.mte[2]} create_mode_transition -name mt3 \ -from M4 -to M3 \ -start_condition {pmc.mte[3]} create_mode_transition -name mt4 \ -from M3 -to M2 \ -start_condition {pmc.mte[4]}

September 2011

134

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

create_mode_transition -name mt5 \ -from M2 -to M4 \ -start_condition {pmc.mte[5]} create_mode_transition -name mt6 \ -from M3 -to M5 \ -start_condition pmc.mte[6]

Running the Example

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. 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:
create_power_mode -name M1 \ -domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF}

September 2011

135

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

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: At simulation time 99 NS: condition NC_08 At simulation time 99 NS: nominal condition NC_08 At simulation time 100 NS: At simulation time 100 NS: Mode transition mt1 [M3->M1] has started. Power domain pdT has transitioned to nominal

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 At simulation time 101 NS: nominal condition NC_08 At simulation time 101 NS: ... 190 clk=0 data=010011 ndata=xxxxxx Power domain pdA has finished transitioning to

Mode transition mt1 [M3->M1] has completed.

105 clk=1 data=001011 ndata=xxxxxx

At time 194 ns, mode transition mt2 (from mode M1 to mode M4) begins. Mode M4 is defined as follows:
create_power_mode -name M4 \ -domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF}

September 2011

136

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

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.
At simulation time 194 NS: At simulation time 194 NS: At simulation time 194 NS: off state Mode transition mt2 [M1->M4] has started. Power domain pdA is being powered off Power domain pdA has started transitioning to power

194 clk=0 data=xxxxxx ndata=xxxxxx 195 clk=1 data=xxxxxx ndata=xxxxxx At simulation time 198 NS: power off state At simulation time 198 NS: ... 295 clk=1 data=xxxxxx ndata=xxxxxx Power domain pdA has finished transitioning to

Mode transition mt2 [M1->M4] has completed.

200 clk=0 data=xxxxxx ndata=xxxxxx

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.
At simulation time 297 NS: At simulation time 297 NS: condition NC_12 At simulation time 298 NS: At simulation time 298 NS: nominal condition NC_12 At simulation time 298 NS: At simulation time 298 NS: condition NC_12 Mode transition mt3 [M4->M3] has started. Power domain pdT has transitioned to nominal

Power domain pdA is being powered up Power domain pdA has started transitioning to

Power domain pdB is being powered up Power domain pdB has transitioned to nominal

300 clk=0 data=xxxxxx ndata=xxxxxx At simulation time 304 NS: nominal condition NC_12 Power domain pdA has finished transitioning to

September 2011

137

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

At simulation time 304 NS: Mode transition mt3 [M4->M3] has completed.

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.
At simulation time 502 NS: current mode (M2) At simulation time 503 NS: At simulation time 503 NS: transition is in progress At simulation time 503 NS: nominal condition NC_12 Power mode transition (mt3) is illegal for the

Power domain pdA is being powered up Power domain pdA is being power up while no mode

Power domain pdA has started transitioning to

505 clk=1 data=xxxxxx ndata=xxxxxx At simulation time 509 NS: nominal condition NC_12 Power domain pdA has finished transitioning to

At simulation time 509 NS: The system is now in a transitional or undefined mode, and has not reached a stable power mode yet 510 clk=0 data=xxxxxx ndata=xxxxxx ... ... At simulation time 717 NS: ... 815 clk=1 data=101000 ndata=010111 Mode transition mt3 [M4->M3] has completed. 718 clk=1 data=011110 ndata=100001

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

September 2011

138

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS Use the -lps_stdby_nowarn option to suppress the input violation messages.
At simulation time 816 NS: At simulation time 816 NS: condition NC_STANDBY At simulation time 816 NS: At simulation time 825 NS: Mode transition mt6 [M3->M5] has started. Power domain pdB has transitioned to nominal

Mode transition mt6 [M3->M5] has completed. Standby mode input violation (top.instB.x[0])!

825 clk=1 data=101001 ndata=01011x 830 clk=0 data=101001 ndata=01011x At simulation time 835 NS: Standby mode input violation (top.instB.x[1])!

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 ncsim> #1000 $finish;

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.

Defining the Nominal Conditions

Use the create_nominal_condition command to specify the nominal conditions. See Defining the Nominal Conditions on page 129.

September 2011

139

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

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. 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 [min:]max

Note: The -transition_latency and -transition_cycles options are not supported in the current release.
September 2011 140 Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS By default, the transition rate is defined as V/ns (volts per nanosecond). You can specify a different time unit with the set_time_unit command.

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. You can override this default and use the minimum slope with the elaborator -lps_dtrn_min option.

In the example, a transition slope is defined for power domain pdA with the following command:
update_power_domain -name pdA \ -transition_slope 0.2

Running the Example

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.

Use the -lps_pmode option to drive the simulation using the power mode/mode transition specification.
irun -access +rwc -gui -input input.tcl \ -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.
irun -access +rwc -gui -input input.tcl \ -lps_cpf dut.cpf -lps_pmcheck_only -lps_stime 1ns -lps_verbose 3 \ dut.v pmc.v &

September 2011

141

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

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.

September 2011

142

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

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 create_mode_transition update_power_mode

September 2011

143

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS 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.

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 \ -voltage 1.0 -state on create_nominal_condition -name off \ -voltage 0.0 -state 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 M1a \ -domain_conditions {...} create_power_mode -name M1b \ -domain_conditions {...} create_power_mode -name M2 \ -domain_conditions {PD_C1@on PD_C2@on} create_power_mode -name M2a \ -domain_conditions {...} create_power_mode -name M3 \ Power domain PD_C2 is not referenced, and -domain_conditions {PD_C1@on} is assumed to be in the off state. create_power_mode -name M3a \ -domain_conditions {...}

create_mode_transition -name CT1 -from M1 -to M2 create_mode_transition -name CT2 -from M1 -to M1a create_mode_transition -name CT3 -from M2 -to M3 create_mode_transition -name CT4 -from M3 -to M1 [Other legal mode transitions] end_power_mode_control_group ... end_design
End power mode control group BLOCKA_PMCG definition.

September 2011

148

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS 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.

September 2011

149

Product Version 10.2

Low-Power Simulation Using CPF for Designs with DVFS

# TOP.cpf set_hierarchy_separator / set_design TOP create_power_domain -name PD_B set_instance BLOCKA_inst1 include BLOCKA.cpf
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_power_mode_control_group -name topPMCG1 \ -domains PD_B -groups BLOCKA_inst1/BLOCKA_PMCG create_power_mode -name T1 \ -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 create_power_mode -name T2 \ 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]

create_mode_transition -name TT1 -from T1 -to T2 ... [Other power mode transitions for BLOCKA_inst1] ... End power mode control group topPMCG1 definition. end_power_mode_control_group set_instance BLOCKA_inst2 include BLOCKA.cpf
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_power_mode_control_group -name topPMCG2 \ -domains PD_B -groups BLOCKA_inst2/BLOCKA_PMCG

Mode T3 is created with domain PD_B at create_power_mode -name T3 \ 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] ... create_mode_transition -name TT4 -from T3 -to T4 ... [Other power mode transitions for BLOCKA_inst2] ... end_power_mode_control_group end_design
End power mode control group topPMCG2 definition.

September 2011

150

Product Version 10.2

Low-Power Simulation

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

September 2011

151

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell 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.

September 2011

152

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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 create_nominal_condition create_power_mode create_mode_transition update_power_domain create_power_switch_rule set_floating_ports For power modes. For power modes. For power modes. For implementation tools and for specifying transition slope for power mode transitions. For implementation tools only For implementation tools only

set_input_voltage_tolerance For implementation tools only set_wire_feedthrough_ports For implementation tools only

The following sections discuss only the commands that affect simulation. Figure 5-1 on page 154 shows the design used in the examples.

September 2011

153

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell Figure 5-1 Macro Model Example VDD
D1

Pd_AON
iso1 iso2 ret pwr

Always On

Switches Pd_PSO Internally Switched State Retention Isolation

Isolation

Pd_EXT Externally Switched

VSS

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.

September 2011

154

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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. An error is generated if you specify instances with the -instances option. Specifying Verilog regs or VHDL Signals as a Power Domain In a CPF macro model, you can specify Verilog regs or VHDL signals as power domain instances with the -instances option. This lets you define memories as part of a power domain or as a separate power domain. For example:
// In your Verilog code reg [7:0] mem[0:15]; set_macro_model IPBlock # Create a power domain for mem create_power_domain -name domain_mem \ -shutoff_condition {pso_en} \ -instances {mem} ... ... end_macro_model

Note: Specifying a Verilog UDP reg as an instance in a power domain is an error. 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:
reg [7:0] mem[0:15][0:1];

September 2011

155

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

set_macro_model top create_power_domain -name {MACRO_DEFAULT} -default create_power_domain -name {MACRO_PD_1} \ -base_domains {MACRO_DEFAULT} \ -instances {mem} \ -shutoff_condition {tb/pso_en} ... end_macro_model top

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

You can use the * and ? wildcard characters to specify register instances. For example:
reg [7:0] mem1[0:15]; reg [7:0] mem2[0:15]; reg [7:0] mem3[0:15]; set_macro_model IPBlock create_power_domain -name domain_mem \ -shutoff_condition {pso_en} \ -instances {mem*} ... ... end_macro_model

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

September 2011

156

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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

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:

September 2011

157

Product Version 10.2

Low-Power Simulation Modeling a 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 63 for more information on the -boundary_ports option. For the example shown in Figure 5-1 on page 154, three power domains are defined:

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

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 set_macro_model IPBlock 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

September 2011

158

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

create_power_domain -name Pd_EXT \ -boundary_ports {D3 D5} ... end_macro_model

Defining Isolation
Figure 5-2 on page 160 shows the example design with the isolation rules.

September 2011

159

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell Figure 5-2 Isolation Rules VDD
D1 iso1 # Port D4 belongs to #default domain Pd_AON create_isolation_rule \ -name IsoOut \ -from Pd_PSO -pins {D4} \ -isolation_condition !pwr \ -isolation_output high iso2 ret pwr

Pd_AON

Always On

Switches Pd_PSO Internally Switched State Retention Isolation

Isolation

# Port D2 belongs to # domain Pd_PSO # D2 has no internal # isolation create_isolation_rule \ -name IsoInReq \ -to Pd_PSO -pins {D2} \ -isolation_output low # Port D3 belongs to # domain Pd_EXT create_isolation_rule \ -name IsoIn \ -to Pd_EXT -pins {D3} \ -isolation_condition iso1 \ -isolation_output low

Pd_EXT Externally Switched

VSS

VPP
# Isolation rule for internal # domain crossing create_isolation_rule \ -name IsoInt \ -from Pd_EXT -to Pd_PSO \ -isolation_condition iso2 \ -isolation_output low

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:

September 2011

160

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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. When the domain is powered down, the registers lose state. The following state retention rule specifies 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.
# macro.cpf # CPF file for macro model set_macro_model IPBlock ... ... create_state_retention_rule -name PSO_RET \ -domain Pd_PSO \ -secondary_domain Pd_AON \ -save_edge {ret}

September 2011

161

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

... ... end_macro_model

In this example, -domain Pd_PSO selects all registers in power domain Pd_PSO. Use the -instances option if you want to select only specified instances. 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 this example, the secondary domain of the state retention logic is domain Pd_AON, which was defined as the base domain of domain Pd_PSO.

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 # CPF file for macro model set_cpf_version 1.0e set_macro_model IPBlock ###################### # Create power domains ###################### create_power_domain -name Pd_AON -default

September 2011

162

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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 \ -isolation_output high # Port D2 belongs to domain Pd_PSO. D2 has no internal isolation create_isolation_rule -name IsoInReq \ -to Pd_PSO -pins {D2} \ -isolation_output low # Port D3 belongs to domain Pd_EXT create_isolation_rule -name IsoIn \ -to Pd_EXT -pins {D3} \ -isolation_condition iso1 \ -isolation_output low # Isolation rule for internal domain crossing create_isolation_rule -name IsoInt \ -from Pd_EXT -to Pd_PSO \ -isolation_condition iso2 \ -isolation_output low ############################## # Define state retention rules ############################## create_state_retention_rule -name PSO_RET \ -domain Pd_PSO \ -secondary_domain Pd_AON \
September 2011 163 Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

-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 5-3 on page 165.

September 2011

164

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell Figure 5-3 Top-Level Power Domains VDD

VDD
D1

PDBlue
iso1

Pd_AON

Always On

iso2 ret pwr

Always On

Switches Pd_PSO Internally Switched State Retention Isolation

Isolation

Switches PDRed Internally Switched State Retention Pd_EXT Isolation Externally Switched
D5

VSS

VPP

The two top-level domains are defined in the top-level CPF as follows:
# top.cpf # Top-level CPF file set_cpf_version 1.0e set_hierarchy_separator /

September 2011

165

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

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: Note: The set_instance -model option is not supported in the current release.

Explicitly, by immediately following the set_instance command with the CPF macro model.
set_instance ipInst -domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}} set_macro_model IPBlock ... ... end_macro_model

September 2011

166

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

Implicitly, by following the set_instance command with the include command.

set_instance ipInst -domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}} 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_cpf_version 1.0e set_hierarchy_separator / 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. ######################################################## create_isolation_rule -name ... \ -from PDRed -pins {D2} \ -isolation_condition ... \ -isolation_output ... ############################################################ # Define state retention rules for registers in domain PDRed ############################################################ create_state_retention_rule -name ... \ -domain PDRed \ -secondary_domain PDBlue \ -save_edge ...

September 2011

167

Product Version 10.2

Low-Power Simulation Modeling a Macro Cell

################################################# # Map domains in macro model to top-level domains ################################################# set_instance ipInst -domain_mapping {{Pd_AON PDBlue} {Pd_EXT PDRed}} ################################################## # include command specifies macro model for ipInst ################################################## include macro.cpf end_design

September 2011

168

Product Version 10.2

Low-Power Simulation

6
Running a Low-Power Simulation
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.

September 2011

169

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

Running in Multi-Step Invocation Mode

Figure 6-1 on page 170 illustrates the flow when debugging the design with power (mode 2 above) if you are running the simulator in multi-step invocation mode. Figure 6-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.

September 2011

170

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

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:

September 2011

171

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

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 89 for details on this option.

ncsim irun

-lps_alt_srr -lps_alt_srr

By default, the transition rate is defined as V/ns (volts per nanosecond). You can specify a different time unit with the set_time_unit command.

If you specify two numbers, the first number indicates the minimum transition rate, and the second number indicates the maximum transition rate.

September 2011

174

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

If you specify only one value, it is considered to be the maximum transition slope. Use the elaborator -lps_dtrn_min option to override this default and use the minimum slope.

ncelab irun

-lps_dtrn_min -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

-lps_enum_rand_corrupt [seed] -lps_enum_rand_corrupt [seed]

September 2011

175

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

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

-lps_enum_right -lps_enum_right

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

September 2011

176

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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.

States are not restored automatically when power is restored. A state element will remain corrupted unless it is restored or reset. See Corruption of VHDL User-Defined Enumerated Types for details on the corruption of VHDL enumerated types.

ncvhdl irun

-lps_implicit_pso -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

September 2011

177

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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. See Corruption of VHDL User-Defined Enumerated Types for details on the corruption of VHDL enumerated types.

ncelab irun

-lps_implicitpso_char -lps_implicitpso_char

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

September 2011

178

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation See Corruption of VHDL User-Defined Enumerated Types for details on the corruption of VHDL enumerated types.

ncelab irun

-lps_implicitpso_nonchar -lps_implicitpso_nonchar

-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 ncsim irun

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

September 2011

179

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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 ncsim irun

-lps_iso_verbose -lps_iso_verbose -lps_iso_verbose

-lps_isofilter_verbose
Enable reporting of isolation filtering information. This option prints messages for pins that have not been isolated because they do not satisfy either driver or load requirements for isolation. 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:
-lps_isofilter_verbose (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

Include the -lps_verbose option if you want to log other low-power information, not only the isolation information. 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). A leading <D> would indicate that it is due to Driver filtering.

September 2011

180

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

******Isolation Filtering Information Following pins from isolation rule at (./cpf.cpf:11) are not isolated: <L> tb.test.ISO1.B

ncelab irun

-lps_isofilter_verbose -lps_isofilter_verbose

-lps_isoruleopt_warn
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_isoruleopt_warn -lps_isoruleopt_warn

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

September 2011

181

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

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

-lps_log_verbose lps_verbose.log \ [other_options] source_files

The -lps_log_verbose option can be used as an elaborator or simulator option.

ncelab ncsim irun

-lps_log_verbose filename -lps_log_verbose filename -lps_log_verbose filename

-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_logfile filename -lps_logfile filename -lps_logfile filename

-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
September 2011 182 Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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_modules_wildcard -lps_modules_wildcard

-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.
create_mode_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. 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 irun

-lps_mtrn_min -lps_mtrn_min

-lps_mvs
Turns on voltage scaling simulation and voltage tracking.

September 2011

183

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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 127 for more information.

ncelab irun

-lps_mvs -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. 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 irun

-lps_no_xzshutoff -lps_no_xzshutoff

-lps_notlp
Turn off special treatment for top-level ports.

September 2011

184

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation Top-level ports 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.

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. 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 73 for information on corruption, and Isolation of Top-Level Ports on page 112 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. This is a simulation-time control option. You must elaborate with the -lps_simctrl_on option to enable the -lps_off option.

ncsim irun

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

September 2011

185

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation 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 ....

See Controlling a Power Mode Simulation on page 127 for more information.

ncelab irun

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

See Controlling a Power Mode Simulation on page 127 for more information.

ncelab irun

-lps_pmcheck_only -lps_pmcheck_only

September 2011

186

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

-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 6-2 on page 187 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. Figure 6-2 Simulating without -lps_rtn_lock
Value of Qm stored in Qs. Power down. Value of Qm forced to X. Qm restored with Power up. Force on Qm value of Qs. released.

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.

September 2011

187

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation The -lps_rtn_lock 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 ncsim irun

-lps_rtn_lock -lps_rtn_lock -lps_rtn_lock

-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 elaborate with the -lps_simctrl_on option to enable the use of this option at simulation time.

ncelab ncsim irun

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

September 2011

188

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

% 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 irun

-lps_simctrl_on -lps_simctrl_on

-lps_srruleopt_warn
Prints a warning message if a state retention rule has been optimized away. 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 irun

-lps_srruleopt_warn -lps_srruleopt_warn

-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

-lps_sim_verbose

September 2011

189

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation

irun

-lps_sim_verbose

-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.
At simulation time 814 NS: At simulation time 814 NS: NC_STANDBY At simulation time 814 NS: At simulation time 815 NS: ... At simulation time 825 NS: ... Standby mode input violation (top.instB.x[1])! Mode transition mt6 [M3->M5] has started. Power domain pdB has transitioned to nominal condition

-lps_upcase
Converts all identifiers in the CPF file to uppercase.
September 2011 191 Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation This option is required if you:

Are running in multi-step mode. Have compiled your Verilog source files with the -upcase option.

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

-lps_verbose {1 | 2 | 3}
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. -lps_verbose {1 | 2 | 3} -lps_verbose {1 | 2 | 3} -lps_verbose {1 | 2 | 3}

ncelab ncsim irun

September 2011

192

Product Version 10.2

Low-Power Simulation Running a Low-Power Simulation -lps_verbose Reporting Levels All -lps_verbose output, regardless of the specified level, begins with the following two sections:

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

Low-Power Simulation Running a Low-Power Simulation

-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 10, Advanced Low-Power Verification Features, for details.

ncelab irun

-lps_verify -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 10, Advanced Low-Power Verification Features, for details.

Low-Power Simulation Simulating an RTL-Level Design

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. set_hierarchy_separator / # 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 \ -base_domains {PDalu} \ -shutoff_condition {pcu_inst/plu[2]}

September 2011

199

Product Version 10.2

Low-Power Simulation Simulating an RTL-Level Design

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]} \ -isolation_output high create_isolation_rule -name PDlu_iso \ -from PDlu \ -pins alu_inst/lui/z* -isolation_output high create_isolation_rule -name PDalu_iso \ -from PDalu \ -pins alu_inst/z* \ -isolation_condition {pcu_inst/palu[0]} \ -isolation_output low
September 2011 200 Product Version 10.2

-isolation_condition {pcu_inst/plu[0]} \

Low-Power Simulation Simulating an RTL-Level Design

create_isolation_rule -name PDrf_iso \ -from PDrf \ -pins {rf_inst/a[*] \ rf_inst/b[*] \ rf_inst/z[*]} \ -isolation_condition {pcu_inst/prf[0]} \ -isolation_output high #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.

September 2011

201

Product Version 10.2

Low-Power Simulation Simulating an RTL-Level Design 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 171. 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,

, on the simulation toolbar.

Choose Simulation Run from the menu.

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,

, on the simulation toolbar.

Choose Simulation Run from the menu.

202 Product Version 10.2

September 2011

Low-Power Simulation Simulating an RTL-Level Design

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 7-2 on page 203. Figure 7-2 Finding the PDAU Opcode

2. Expand pau[4:0], as shown in Figure 7-3 on page 204. This is the power control bus for the arithmetic unit.

September 2011

203

Product Version 10.2

Low-Power Simulation Simulating an RTL-Level Design Figure 7-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: Power on/off Save/restore state retention cells Isolation on/off

pau[2] pau[1] pau[0]

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

September 2011

204

Product Version 10.2

Low-Power Simulation Simulating an RTL-Level Design 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 7-4 on page 205. This is the power control bus for the logic unit. Figure 7-4 Expanding the Logic Unit Power Control Bus

Isolation enabled

State retention save

Power down

Power up

State retention restore

Isolation disabled

September 2011

205

Product Version 10.2

Low-Power Simulation Simulating an RTL-Level Design The following signals in this bus control power: Power on/off 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

plu[2] plu[1]

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.

until you find the power-down or

September 2011

206

Product Version 10.2

Low-Power Simulation

8
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

September 2011

207

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design 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.

September 2011

208

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design 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.

September 2011

209

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design 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.

September 2011

210

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design 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 197). 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. set_hierarchy_separator / # 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 PDau \ -instances alu_inst/aui \ -shutoff_condition {pcu_inst/pau[2]} create_power_domain -name PDlu \ -instances alu_inst/lui \ -shutoff_condition {pcu_inst/plu[2]}

September 2011

211

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design

create_power_domain -name PDalu \ -instances alu_inst \ -shutoff_condition {pcu_inst/palu[2]} create_power_domain -name PDrf \ -instances rf_inst \ -shutoff_condition {pcu_inst/prf[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]} 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]} \ -isolation_output high create_isolation_rule -name PDlu_iso \ -from PDlu \ -pins alu_inst/lui/z* \ -isolation_condition {pcu_inst/plu[0]} \ -isolation_output high

September 2011

212

Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design

create_isolation_rule -name PDalu_iso \ -from PDalu \ -pins alu_inst/z* \ -isolation_condition {pcu_inst/palu[0]} \ -isolation_output high create_isolation_rule -name PDrf_iso \ -from PDrf \ -pins rf_inst/z* \ -isolation_condition {pcu_inst/prf[0]} \ -isolation_output high # 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.
September 2011 213 Product Version 10.2

Low-Power Simulation Simulating a Gate-Level Design 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/`endcelldefine directives.

`celldefine module ram_behave (...); ... reg tmp1, tmp2; ... endmodule `endcelldefine //Exclude these registers from state retention

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 {...}

September 2011

214

Product Version 10.2

Low-Power Simulation

9
Debugging a Low-Power Simulation
SimVision includes many features to help you debug a low-power simulation, including features for debugging a design with power modes. See Debugging Power Modes with SimVision on page 231 for a description of features related to debugging power modes. Enhancements to several interactive Tcl commands have also been implemented to facilitate debugging. See Tcl Command Enhancements for Low Power on page 238.

Debugging with SimVision

SimVision lets you view power domains and power conditions during simulation. You can monitor power-related signals in the Design Browser, access the CPF file in the Source Browser, display the power domains in the Schematic Tracer, and view the power-down and power-up sequence in the Waveform window. This section describes how to use SimVision to simulate and debug a low-power design.

Invoking SimVision for Low-Power Simulation

When debugging a low-power design, SimVision requires access to the design snapshot so that it can derive power domain states, isolation states, and other data pertinent to power usage. The snapshot is always available during simulation. However, when you run SimVision in post-processing mode, you must specify the snapshot name on the command line with the -snapshot option. For information on invoking SimVision, see Invoking SimVision.

Opening the Power Sidebar

To help you debug low-power designs, SimVision provides a Power sidebar in the Design Browser, Source Browser, Waveform window, and Schematic Tracer.
September 2011 215 Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation To open the sidebar: Click the Power tab in the Design Browser, Source Browser, Waveform window, or Schematic Tracer.

The Power sidebar displays each power domain in the design. For example, Figure 9-1 on page 216 shows the power domains in the design example used in Chapter 7, Simulating an RTL-Level Design. Figure 9-1 Power Domains in the Nano CPU Design

Low-Power Simulation Debugging a Low-Power Simulation

Isolation is not in effect and the isolation enable is unknown (x). Isolation value is specified as hold in the CPF file. Indicates a state retention rule.

You can place the cursor over an item or over any object to get information about the object. The Power sidebar contains a Click and add button at the bottom of the sidebar. If this button is enabled, you can select items in the sidebar and route the data from the sidebar to the containing window. The data that can be routed to the containing window differs, depending on the containing window. You can also use the Send to toolbar buttons to send the selected domain or domain object to a Source Browser, Design Browser, Schematic Tracer, or Waveform window.

Using the Power Sidebar in the Design Browser

When Click and add to signal list area is enabled, the following actions are available:

Expand Instances and select an instance to send the signals in the instance to the signal list. Select Isolation Ports to send all isolation ports to the signal list. Select an individual isolation port to send it to the signal list. Select Retention Elements to send all retention variables to the signal list. Select an individual retention element to send it to the signal list. Select an isolation rule to send the isolation ports associated with the rule to the signal list. Select a state retention rule to send the retention variables associated with the rule to the signal list.

No action is taken when you select a power domain, Instances, Isolation Rules, or a State Retention Rules. For more information about using the Design Browser, see Monitoring Signal Values.

September 2011

219

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

Using the Power Sidebar in the Source Browser

The Source Browser gives you access to the CPF file that defines the power intent for your design. If your CPF file has the .cpf extension, syntax highlighting is enabled automatically when you open a CPF file. That is, the Source Browser highlights commands, command options, and comments, similar to the way it highlights HDL source code. If you use a file extension other than .cpf, you can add the extension to the Source Browser Files tab of the Preferences form to enable syntax highlighting in all files with that extension. When Click and send to source code area is enabled, the following actions are available:

Select a domain to go to the location of the domain definition in the CPF file. Select a top-level instance under Instances to go to its definition in the HDL source code. Select an isolation port under Isolation Ports to go to the port definition in the HDL source code. Select a retention element under Retention Elements to go to the variable definition in the HDL source code. Select an isolation rule under Isolation Rules to go to the rule definition in the CPF file. Select a state retention rule under State Retention Rules to go to the rule definition in the CPF file.

No action is taken when you select any other type of object in the sidebar. For more information about using the Source Browser, see Accessing the Design Source Code.

Using the Power Sidebar in the Waveform Window

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. To probe all objects in a power domain:

From the Waveform window, open the Power sidebar and select the power domain. This adds a power domain group to the Waveform window. The probe is created when you run the simulation.

September 2011

220

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

From any other window that contains the Power sidebar, select the power domain and click Send to Waveform, .

Figure 9-4 on page 221 shows the PDau power domain in the Waveform window. Simulation has not run yet. The signals shown for this power domain are:

The shutoff condition for the domain The isolation control signal The isolation ports (zau[31:0]) The state retention save edge signal The state retention restore edge signal The state retention elements (z[31:0]) A signal for the state retention saved value (z_sr[31:0])

Figure 9-4 Power Domain PDau in the Waveform Window

Click Run, , to simulate the design. SimVision generates the waveforms for the objects. Figure 9-5 on page 222 shows the waveforms for the PDau domain.

September 2011

221

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-5 PDau Waveforms after Simulation

The waveforms in this figure illustrate the power-down sequence, as follows: 1. The baseline is set at the time when isolation is enabled, that is, when PDau_iso_isolation_control (the signal pau[0]) is 1. At that time, the isolation port zau[31:0] is isolated high. Slanted lines indicate that this port is isolated. 2. Next, the save edge signal, PDau_sr_save_edge goes high, and PDau_sr_restore_edge goes low to indicate that the current value of the state retention register (z[31:0]) must be saved. The saved value is shown by the value of z_sr[31:0]. 3. When shutoff occurs (PDau_shutoff is 1) the area behind the waveforms for z[31:0] shows a cross-hatch pattern to indicate that the X values are the result of power shutdown. Cross-hatching indicates power shutdown. Because power domain PDau has a base power domain, PDalu, the shutoff condition for PDau is an expression that ORs the shutoff condition for PDau and the shutoff condition for PDalu.
(pau[2] || palu[2])

Note: In the SimVision Waveform Window, a cross-hatch pattern is displayed behind the signals that are corrupted when a power domain is shut off. A power domain can be shut off when its shutoff control expression evaluates to true or when the shutoff condition transitions to an unknown state X (or U for VHDL) or Z. To help you distinguish the

September 2011

222

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation difference between corruption due to an unknown value on the power shutoff control signal and corruption due to a normal shutoff condition being evaluated to true, the cross-hatch pattern is drawn in red if the domain is shut off due to an X/U/Z value on the power shutoff control signal. 4. When power is restored (PDau_shutoff is 0) the cross-hatch pattern is removed. This indicates that the X values are no longer due to power shutoff. 5. PDrf_sr_save_edge then goes low and PDrf_sr_restore_edge goes high. The saved values are written back to the state retention register (z[31:0]). 6. The isolation control signal then goes low. Isolation on port zau[31:0] is disabled. In addition to routing all power domain objects to the Waveform window, you can send individual power-related objects to the waveform area. When Click and add to waveform area is enabled in the Power sidebar, the following actions are available:

Select a top-level instance under Instances to send the signals defined in that instance to the waveform area. Select an isolation port under Isolation Ports to send that port to the waveform area. Select an individual retention element under Retention Elements to send the retention variable to the waveform area. Select an isolation rule under Isolation Rules to create a group for the isolation rule that contains all of the ports in the rule and the isolation control expression for the rule. Select a state retention rule under State Retention Rules to create a group that contains all of the retention elements in the rule and the save and restore control expressions for the signal.

No action is taken when you select any other type of object in the sidebar. For more information about using the Waveform window, see Using the Waveform Window.

Using the Power Sidebar in the Schematic Tracer

The Schematic Tracer lets you view the power domains and their states in a schematic form. When Click and add to schematic area is enabled, the following actions are available:

Select a power domain to send all top-level instances in that domain to the schematic area. Select Instances to send all top-level instances to the schematic area.

September 2011

223

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

Select an instance from Instances to send that instance to the schematic area. Select Isolation Ports to send all isolation ports to the display. Select an isolation port under Isolation Ports to send that port and all of its connections to the display. Select Retention Elements to send all retention elements to the display. Select a retention element under Retention Elements to send that object and all of its connections to the display. Select an isolation rule under Isolation Rules to send all ports associated with that rule to the display. Select a state retention rule under State Retention Rules to send all of the retention variables associated with that rule to the display.

No action is taken when you select Isolation Rules or State Retention Rules. For more information about using the Schematic Tracer, see Viewing a Design Schematic. Figure 9-6 on page 224 shows the instance in the PDrf power domain. The background of the instance is filled gray, which indicates that the PDrf domain is currently powered off. Figure 9-6 Schematic Showing PDrf Instance

September 2011

224

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Values are displayed in the schematic. Isolation values are indicated by drawing the wire in white to show that the port is isolated. In Figure 9-7 on page 225, the port b[31:0] is currently isolated. Figure 9-7 Schematic Indicating Port Isolation

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-11 Tracing an Isolation Port

For more information about tracing signal values, see Tracing Paths with the Trace Signals Sidebar.

Viewing Assertion States during a Power Shutdown

By default, when a power domain that contains assertions is powered down, the assertions remain active. The Waveform window shows gray cross-hatching behind the assertion traces to indicate that the power domain containing the assertions is powered down. You can use the create_assertion_control command in the CPF file to turn off the evaluation of selected assertion instances related to a power domain when that power domain is shut down, and to specify how the assertions are evaluated when power is turned on again.
create_assertion_control -name ac2 -domains {dmn1 dmn2} -type reset

If you use the create_assertion_control command to turn off the evaluation of an assertion when the power domain is shut down, the assertion state is set to Suspended at power shutdown. The Assertion Browser displays this state in the Assertion State column, as shown in Figure 9-12 on page 230.

September 2011

229

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-12 Low-Power Assertion States in the Assertion Browser

The Waveform window displays this state in the assertion waveform trace, as shown in Figure 9-13 on page 231.

September 2011

230

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-13 Low-Power Assertion States in the Waveform Window

For more information about debugging assertions in SimVision, see Chapter 6, Viewing Assertions, in Assertion Checking in Simulation.

Debugging Power Modes with SimVision

This section describes SimVision features that help you debug a low-power design with power modes. Note: This section assumes that you are familiar with the SimVision features described in Debugging with SimVision on page 215.

The Power Sidebar

For a design with power modes, the Power sidebar includes an additional Power Modes and Conditions item when you expand a power domain. Expanding this item displays all of the power modes and nominal conditions for the domain. The current power mode and nominal condition for a domain is shown in boldface. Additional icons are added to indicate the current state of a power domain: Domain is transitioning from one power mode to a different power mode. Domain is transitioning from one power mode to a different power mode, and the domain has a base domain. Domain is in standby mode.

September 2011

231

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

Domain is in standby mode, and the domain has a base domain.

Figure 9-14 on page 232 illustrates the power mode related features in the Power Sidebar. Figure 9-14 Power Sidebar with Power Modes

Icon indicates that power domain pdB is off. Icon indicates that power domain pdA is in transition state.

Expand Power Modes and Conditions to display power modes, nominal conditions, and voltages. Current power mode and nominal condition is highlighted.

Icon indicates that power domain pdT is on.

You can also place the cursor over a power domain to get information about the domains current state, power mode, nominal condition, and voltage level, as shown in Figure 9-15 on page 233.

September 2011

232

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-15 Displaying Power Domain Information

Viewing Power Mode Information in the Waveform Window

When you probe a power domain, the simulator records all of the domain elements (shutoff condition, isolation ports and isolation conditions, state retention elements and save/restore conditions, and so on). It also records a struct to the database that contains the current power domain state, the power mode, the nominal condition, and the voltage. 1. In the Waveform window, open the Power sidebar. 2. Select each power domain in turn to add a group for each domain to the Waveform window. The groups contain all of the domain elements for each domain, including a struct for each domain. The structs have names that correspond to the names of the power domains. In this example, the structs are called pdT, pdA, and pdB, as shown in Figure 9-16 on page 234.

September 2011

233

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-16 Waveform Window with Power Domain Groups

3. Click Run, objects.

, to simulate the design. SimVision generates the waveforms for the

4. Expand struct pdT, pdA, and pdB to view power mode details, as shown in Figure 9-17 on page 235.

September 2011

234

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation Figure 9-17 Waveform Window with structs Expanded

September 2011

235

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation The TimeA cursor is positioned at time 297 ns, when a transition from power mode M4 to mode M3 begins. At time 297 ns, domain pdT, which has no transition time specified in the CPF file, transitions to nominal condition NC_12. At time 298 ns, the shutoff signal for power domain pdB is deasserted and the domain is being powered up. No transition time is specified in the CPF file, so the transition to nominal condition NC_12 is at 298 ns.

September 2011

236

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation At time 298 ns, the shutoff signal for power domain pdA is deasserted and the domain is being powered up. A transition slope of .2V/ns is specified for domain pdA in the CPF file, so the transition to nominal condition NC_12 is completed at 304 ns. Internal signals remain corrupted during the entire transition time.

At time 305 ns, the restore condition (!pgeA) is true, and data is restored.

September 2011

237

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

Note: Power modes are recorded to the database as a structure. You cannot select an element of a structure and then delete the element from the display unless the structure has first been ungrouped.

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.

September 2011

238

Product Version 10.2

Low-Power Simulation Debugging a 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 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 Information about Power Domains and Power Modes

The power command can be used to display:

Information about a specified power domain (-pdname) Information about the power domain that contains a specified HDL object (-object) A list of power domains within a specified power mode, along with their corresponding nominal condition names and voltage values (-pwr_mode).

September 2011

239

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation 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 ...]

The power command has one modifier: -show. This is the default action, and specifying -show is not required. 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:

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

September 2011

240

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation 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.

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.

Low-Power Simulation Debugging a Low-Power Simulation 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).
create_power_mode -name M3 \ -default \ -domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_08} ncsim> power -pwr_mode M3 Power mode top.M3 Domains: pdT Nominal condition is (NC_12): voltage = 1.200000 pdA Nominal condition is (NC_12): voltage = 1.200000 pdB Nominal condition is (NC_08): voltage = 0.800000

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)

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:

September 2011

244

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

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

-retentionStop when any state retention rule associated with the power domain saves or restores its variables.

Low-Power Simulation Debugging a Low-Power Simulation

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: Mode transition mt1 [M3->M1] has started.

At simulation time 99 NS: Power domain pdT has transitioned to nominal condition NC_08 At simulation time 99 NS: condition NC_08 top.mt1 ./dut.cpf line 62 ncsim> Power domain pdA has started transitioning to nominal

99 NS + 1 (stop 1: Power Mode Transition top.mt1)

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 ... ... At simulation time 814 NS: At simulation time 814 NS: NC_STANDBY At simulation time 814 NS: top.pdB ./dut.cpf line 32 ncsim> Mode transition mt6 [M3->M5] has started. Power domain pdB has transitioned to nominal condition Mode transition mt6 [M3->M5] has completed.

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

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 two suboptions:

-iso_disableStop only when the isolation rule becomes disabled.

248 Product Version 10.2

September 2011

Low-Power Simulation Debugging a Low-Power Simulation

-iso_enableStop only when the isolation rule becomes enabled.

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) TESTBENCH.inst.PDau_iso ./nano.cpf line 54 ncsim> run 28600 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso is DISABLED) TESTBENCH.inst.PDau_iso ./nano.cpf line 54

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 two suboptions:

-sr_restoreStop only when the state retention rule restores its variables. -sr_saveStop only when the state retention rule saves its variables.

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

September 2011

249

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation 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:
create_mode_transition -name mt1 \ -from M3 -to M1 \ -start_condition pmc.mte[1]

Power modes M3 and M1 are defined with the following two create_power_mode commands:
create_power_mode -name M3 \ -default \ -domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_12} create_power_mode -name M1 \ -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 ... ... 95 clk=1 data=001010 ndata=110101 At simulation time 99 NS: top.mt1 ./dut.cpf line 57 ncsim> run At simulation time 100 NS:
September 2011

Mode transition mt1 [M3->M1] has started.

99 NS + 1 (stop 1: Power Mode Transition top.mt1)

Power domain pdB is being powered off

250 Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

At simulation time 100 NS: At simulation time 100 NS: condition NC_08 At simulation time 100 NS: NC_08

Power domain pdB has transitioned to power off state Power domain pdA has started transitioning to nominal Power domain pdT has transitioned to nominal condition

100 clk=0 data=001010 ndata=xxxxxx At simulation time 101 NS: condition NC_08 At simulation time 101 NS: top.mt1 ./dut.cpf line 57 ncsim> Power domain pdA has finished transitioning to nominal Mode transition mt1 [M3->M1] has completed.

101 NS + 0 (stop 1: Power Mode Transition top.mt1)

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

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

September 2011

251

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation 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.
create_power_domain -name PDau \ -instances alu_inst/aui \ -shutoff_condition {pcu_inst/pau[2]} create_state_retention_rule -name PDau_sr \ -instances {alu_inst/aui/z* } \ -save_edge {pcu_inst/pau[1]} \ -restore_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 Created stop 2 ncsim> run 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 Power domain is (PDau) State Retention variables and registers: TESTBENCH.inst.alu_inst.aui.z State Retention rule: file ./nano.cpf line 44 Status is: retained ncsim> value inst.alu_inst.aui.z 32h0000124e ;# Display current value ;# See if variable is retained ;# Run until save enable is active 100 PS + 3 (stop 1: TESTBENCH.inst.pcu_inst.pau[1] = 0) ;# Set break on power domain PDau

September 2011

252

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

ncsim> run 15800 NS + 6 (stop 2: Power Domain PDau) ncsim> value inst.alu_inst.aui.z 32hxxxxxxxx ncsim> value -saved inst.alu_inst.aui.z 32h0000124e ncsim> ;# Display saved value ;# Display current value ;# Run until power domain is shut off

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 7-1 on page 198.
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.prf[1] TESTBENCH.inst.pcu_inst.pau[1] TESTBENCH.inst.pcu_inst.pau[0] TESTBENCH.inst.pcu_inst.plu[0] TESTBENCH.inst.pcu_inst.palu[0] TESTBENCH.inst.pcu_inst.prf[0] Number of objects probed : 10 ncsim>

September 2011

253

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

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>

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:

September 2011

254

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

create_power_domain -name PDau \ -instances alu_inst/aui \ -shutoff_condition {pcu_inst/pau[2]} create_power_domain -name PDrf \ -instances rf_inst \ -shutoff_condition {pcu_inst/prf[2]}

The following create_isolation_rule command is used to illustrate the output of the drivers command:
create_isolation_rule -name PDau_iso \ -to PDrf \ -isolation_condition {pcu_inst/pau[0]} \ -isolation_output low

ncsim> ;# Run until isolation is enabled and power is on ncsim> stop -object inst.pcu_inst.pau[0] 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) ncsim> run 1 ps Ran until 13400001 PS + 0 ncsim> value inst.alu_inst.aui.a 32h00000dfe ncsim> drivers inst.alu_inst.aui.a 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 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 32h00000000 ;# Display value of input result of rf_inst ;# Value is 0 because of isolation rule. ;# Display drivers of input a inst.alu_inst.aui.a...input net logic [31:0] ;# Display value of input a ;# Isolation enabled

September 2011

255

Product Version 10.2

Low-Power Simulation Debugging a Low-Power Simulation

ncsim> drivers inst.rf_inst.result 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 ncsim> stop -object inst.pcu_inst.pau[2] Created stop 2 ncsim> run ;# Display drivers of input result

inst.rf_inst.result...input net logic [31:0]

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. In a future release, the CPF set_sim_control command will be enhanced so that you can 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/acknowlege handshake, and the signal has not been isolated correctly. Check all isolations on signals leaving this domain, and going to this domain, to make sure that they are both the correct polarity, and are actually enabled before shutting off the domain.
256 Product Version 10.2

September 2011

Low-Power Simulation

10
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 257. Automatic generation of a SystemVerilog coverage model. See Generating a Coverage Model on page 265.

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

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 10-1 on page 258 shows the correct transition sequence of control signals when one state retention control signal is specified.

September 2011

257

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features Figure 10-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 down Power up

Figure 10-2 on page 258 shows the correct transition sequence of control signals when separate state retain and state restore control signals are specified. Figure 10-2 Transition Sequence with Separate Save and Restore Control Signals
Isolation enabled Save state Restore state Isolation disabled

Isolation

Save

Restore

Power switch enable Power down Power up

September 2011

258

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features 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 7, Simulating an RTL-Level Design, defines a power domain called PDau with a state retention rule and isolation rule as follows:
create_power_domain -name PDau \ -instances alu_inst/aui \ -base_domains {PDalu} -shutoff_condition {pcu_inst/pau[2]} create_state_retention_rule -name PDau_sr \ -instances {alu_inst/aui/z* } \ -restore_edge {!pcu_inst/pau[1]}
September 2011 259 Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

create_isolation_rule -name PDau_iso \ -from PDau \ -pins alu_inst/aui/z* \ -isolation_condition {pcu_inst/pau[0]} \ -isolation_output high

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.

September 2011

260

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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

September 2011

261

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

LPV_DMN_DomainName_NO_ISOLATION_TOGGLE_1 LPV_DMN_DomainName_NO_ISOLATION_TOGGLE_2

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.

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:

September 2011

262

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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.

For an edge-sensitive retention rule, the save region is the region from when the save edge expression becomes true until the power shutdown. For a level-sensitive retention rule, the save region is the region between when the save level expression becomes true until it becomes false.

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_PRECOND_NOT_FALSE_1 LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_2

The assertion failure message displays the CPF file name and the line number of the corresponding state retention rule.

LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_number Restore precondition cannot become false in the restore region.

September 2011

263

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features 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.

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_RESTORE_PRECOND_NOT_FALSE_1 LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_2

The assertion failure message displays the CPF file name and the line number of the corresponding state retention rule. 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. 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:

September 2011

264

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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

September 2011

265

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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

September 2011

266

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features 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 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

September 2011

267

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features 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

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

September 2011

268

Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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 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.
September 2011 269 Product Version 10.2

Low-Power Simulation Advanced Low-Power Verification Features

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.

September 2011

270

Product Version 10.2

Low-Power Simulation

11
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 272. See VHDL Procedures on page 309. 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

September 2011

271

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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

September 2011

272

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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 // Declare link_register

September 2011

273

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

$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 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;

power_domain_register

An error is generated if the register is too small for the full path.

September 2011

274

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

[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); $lps_get_power_domain(pd_reg, dut1); /* In module dut */ /* In module top */

$lps_get_power_domain(pd_reg, top.dut1); /* Anywhere */

September 2011 275 Product Version 10.2

$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 A register of width 1. The register will be linked to the powerdown state of the power domain of interest.

link_register

[power_domain]

The name of the power domain of interest. 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

Low-Power Simulation Power-Aware Modeling 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 always @(posedge link_pwrdown) 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.
// 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);

module testbench;

September 2011

282

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

// 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 always @(posedge link_pwrdown) DO_SOMETHING; endmodule

September 2011

283

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

$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. If the link_register exists in a switchable power domain, it is corrupted when the domain is powered down. Arguments A register of width 1. The register will be linked to the standby state of the power domain of interest.

link_register

[power_domain]

The name of the power domain of interest. 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 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
module top; // Declare 1-bit reg for link_register reg link_standby; topA t1();

September 2011

284

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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

September 2011

285

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

$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

If the link_register exists in a switchable power domain, it is corrupted when the domain is powered down. Arguments 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

link_register

[power_domain]

The name of the power domain of interest. 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 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.

September 2011

286

Product Version 10.2

Low-Power Simulation Power-Aware Modeling 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; // Declare link_register reg [1:13*8] link_pdA_state; // Declare a register to be used as the power domain name reg [1:32*8] str1 = top.t1.pdA; topA t1();

September 2011

287

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

initial begin // Link register link_pdA_state to state of domain top.t1.pdA. // Specify absolute path of power domain using register str1. $lps_link_power_domain_state(link_pdA_state, str1); end // Execute some code when link register link_pdA_state changes value. always @(link_pdA_state) 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; // 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 relative path of power domain using a string constant. $lps_link_power_domain_state(link_pdA_state, "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. string linkStr; always @(link_pdA_state) begin $swrite(linkStr, "%0s", link_pdA_state); if (linkStr == "TRANSITION") DO_SOMETHING; end endmodule

September 2011

288

Product Version 10.2

Low-Power Simulation Power-Aware Modeling Or:

module top; // Declare link_register reg link_pdA_state; // Declare a register to be used as the power domain name 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.
// Declare link_register. reg [1:13*8] link_pdA_state; // Declare power domain register for $lps_get_power_domain reg [1:250*8] pdReg; 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); $display($stime, " initial pdA top state = %0s\n", link_pdA_state); end

module top;

September 2011

289

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

// Execute some code when link register link_pdA_state changes value. string linkStr; always @(link_pdA_state) begin $swrite(linkStr, "%0s", link_pdA_state); if (linkStr == "TRANSITION") DO_SOMETHING; end endmodule

September 2011

290

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

$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 domain is powered down. Arguments A real variable. The variable will be linked to the voltage of the power domain of interest.

link_variable

[power_domain]

The name of the power domain of interest. 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 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
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);

September 2011

291

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

$lps_link_power_domain_nominal_condition(<link_register> [, <power_domain>]);
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 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

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.

September 2011

298

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

[power_domain]

The name of the power domain of interest. 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 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);

September 2011

299

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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

September 2011

300

Product Version 10.2

Low-Power Simulation Power-Aware Modeling 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 At simulation time 0 FS: NC_12 At simulation time 0 FS: NC_12 0 NomCond B = NC_12 0 Active state conditions for pdT: aseT08 = 0 aseT12 = 1 0 NomCond T = NC_12 At simulation time 2 NS: condition NC_08 2 NomCond A = NC_08 At simulation time 10 NS: At simulation time 10 NS: off state At simulation time 12 NS: off state Power domain pdA is being powered off Power domain pdA has started transitioning to power Power domain pdA has finished transitioning to nominal Power domain pdA has started transitioning to nominal

Power domain pdB has transitioned to nominal condition

Power domain pdT has transitioned to nominal condition

0 Active state conditions for pdB: aseB08 = 0 aseB12 = 1

2 Active state conditions for pdA: aseA08 = 1 aseA12 = 0

Power domain pdA has finished transitioning to power

12 Active state conditions for pdA: aseA08 = 0 aseA12 = 0 12 NomCond A = SHUTOFF At simulation time 20 NS: Power domain pdA is being powered up

September 2011

301

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

At simulation time 20 NS: Power domain pdA has transitioned to power on state

20 Active state conditions for pdA: aseA08 = 0 aseA12 = 0 20 NomCond A = UNINITIALIZED At simulation time 20 NS: At simulation time 20 NS: Power domain pdB is being powered off Power domain pdB has transitioned to power off state

20 Active state conditions for pdB: aseB08 = 0 aseB12 = 0 20 NomCond B = SHUTOFF At simulation time 30 NS: At simulation time 30 NS: Power domain pdB is being powered up Power domain pdB has transitioned to power on state

30 Active state conditions for pdB: aseB08 = 0 aseB12 = 0 30 NomCond B = UNINITIALIZED At simulation time 30 NS: condition NC_12 At simulation time 33 NS: condition NC_12 33 NomCond A = NC_12 ... ... Power domain pdA has started transitioning to nominal

Power domain pdA has finished transitioning to nominal

33 Active state conditions for pdA: aseA08 = 0 aseA12 = 1

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

$lps_link_power_domain_power_mode(<link_register> [, <power_domain>]);
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 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

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 name of the power domain of interest. 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

Low-Power Simulation Power-Aware Modeling

-- 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:
-- Declare link signal 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);

September 2011

310

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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

power_domain_signal

An error is generated if the signal is too small for the full path.

September 2011

311

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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

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

link_signal

[power_domain]

The name of 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. It can be:

The full path of the power domain The path of the power domain relative to the scope from which the procedure 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 procedure is called.

September 2011

318

Product Version 10.2

Low-Power Simulation Power-Aware Modeling 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; use NCUTILS.LPSUTILITIES.all; library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_textio.all; library std; use std.textio.all; entity TOP is end entity TOP; architecture RTL of TOP is .. -- Declare link signal signal link_pwrdown : std_logic := 0; procedure pwrdown 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);

322

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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. If the link_signal exists in a switchable power domain, it is corrupted when the domain is powered down. Arguments 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. The name of the power domain of interest. This argument is a string constant or the value of a signal of type string that holds the path of the power domain. It can be:

link_signal

[power_domain]

The full path of the power domain 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 procedure is called.

Example
library NCUTILS; use NCUTILS.LPSUTILITIES.all; ... entity top is end top;

September 2011

323

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

architecture top_rtl of top is ... signal clk ... -- 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; : std_logic;

signal data : std_logic_vector (5 downto 0);

pseA <= 0; pseB <= 0; aseA12 <= 1; aseB12 <= 1; aseT12 <= 1; wait for 99 ns; mte ... end Process; end top_rtl;
September 2011 324 Product Version 10.2

<= 00001;

Low-Power Simulation Power-Aware Modeling

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

If the link_signal exists in a switchable power domain, it is corrupted when the domain is powered down. Arguments 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);

link_signal

[power_domain]

The name of 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. It can be:

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

Low-Power Simulation Power-Aware Modeling

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. If the link_signal exists in a switchable power domain, it is corrupted when the domain is powered down. Arguments 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.

link_signal

[power_domain]

The name of 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. It can be:

The full path of the power domain The path of the power domain relative to the scope from which the procedure 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 procedure is called.

Example
library NCUTILS; use NCUTILS.LPSUTILITIES.all; ... entity top is end top; architecture top_rtl of top is ... signal clk : std_logic;

signal data : std_logic_vector (5 downto 0);

September 2011 328 Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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 domain is powered down. Arguments 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:
signal link_sig : string (512 downto 1);

link_signal

An error is generated if the signal is too small for the nominal condition name.

[power_domain]

The name of 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. It can be:

The full path of the power domain The path of the power domain relative to the scope from which the procedure 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 procedure is called.

September 2011

335

Product Version 10.2

Low-Power Simulation Power-Aware Modeling Example

library NCUTILS; use NCUTILS.LPSUTILITIES.all; ... entity top is end top; architecture top_rtl of top is ... signal clk ... -- 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); instB : modB port map(x => data, y => ndata); 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;
September 2011 336 Product Version 10.2

: std_logic;

signal data : std_logic_vector (5 downto 0);

Low-Power Simulation Power-Aware Modeling

wait for 99 ns; ... end Process; end top_rtl;

September 2011

337

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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 domain is powered down. Arguments 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:
signal link_sig : string (512 downto 1);

link_signal

An error is generated if the signal is too small for the power mode name.

[power_domain]

The name of 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. It can be:

The full path of the power domain The path of the power domain relative to the scope from which the procedure 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 procedure is called.

Example
library NCUTILS; use NCUTILS.LPSUTILITIES.all; ...
September 2011 338 Product Version 10.2

Low-Power Simulation Power-Aware Modeling

entity top is end top; architecture top_rtl of top is ... signal clk ... -- 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); : std_logic;

signal data : std_logic_vector (5 downto 0);

instB : modB port map(x => data, y => ndata); PowerDown : process begin -- Link link signal to power mode of power domain :pdA lps_link_power_domain_power_mode(link_pmA, :pdA); mte <= 00000;

September 2011

339

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

pseA <= 0; pseB <= 0; aseA12 <= 1; aseB12 <= 1; aseT12 <= 1; wait for 99 ns; ... end Process; end top_rtl;

September 2011

340

Product Version 10.2

Low-Power Simulation Power-Aware Modeling

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 A signal of type integer.

signal_name

Example
library NCUTILS; use NCUTILS.LPSUTILITIES.all; ... 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 pwrDA : string (10 downto 1); -- 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; procedure pwrdown is begin DO_SOMETHING; end pwrdown;
September 2011 341 Product Version 10.2

Low-Power Simulation Power-Aware Modeling

Index
Symbols
$lps_enabled 307 $lps_get_power_domain 274 $lps_get_stime 308 $lps_link_power_domain_gnd_voltage 29 3 $lps_link_power_domain_nmos_voltage 2 94 $lps_link_power_domain_nominal_conditio n 298 $lps_link_power_domain_pmos_voltage 2 95 $lps_link_power_domain_power_mode 30 5 $lps_link_power_domain_powerdown 279 $lps_link_power_domain_standby 284 $lps_link_power_domain_state 286 $lps_link_power_domain_voltage 291 verifying correct sequence 196 Corruption disabling with set_sim_control 33 of top-level ports 73 of VHDL user-defined enumerated types 75 Coverage model automatic generation of 265 CPF file specifying with -lps_cpf 174

D
Debugging infinite loops 256 Tcl commands 238 with SimVision 215

A
Assertion Browser 229 Assertions automatic generation of viewing 229 196

F
Feedthrough wires 41

I
Identifiers in CPF converting to upper case 191 Infinite loops debugging 256 Initial blocks replaying on powerup 30 Isolation back-to-back 117 Isolation information logging 179

B
Back-to-back isolation 117 Boundary ports specifying with -boundary_ports -boundary_ports 63 63

C
Cells excluding from state retention 173 Constants in shutoff control expression 70 Continuous assignments treating as buffers 172 Control signals generating a coverage model for 265
September 2011 345

L
Log file specifying a name for 182 Logging 192 isolation information 179 output of -lps_verbose 181

Product Version 10.2

Low-Power Simulation

-lps_alt_srr 172 -lps_assign_ft_buf 172 -lps_blackboxmm 173 -lps_cellrtn_off 173 -lps_cpf 174 -lps_dtrn_min 174 lps_enabled 341 -lps_enum_rand_corrupt 175 -lps_enum_right 176 lps_get_power_domain 311 lps_get_stime 344 -lps_implicit_pso 176 -lps_implicitpso_char 177 -lps_implicitpso_nonchar 178 -lps_iso_off 179 -lps_iso_verbose 179 -lps_isofilter_verbose 180 -lps_isoruleopt_warn 181 lps_link_power_domain_gnd_voltage 330 lps_link_power_domain_nmos_voltage 33 1 lps_link_power_domain_nominal_condition 335 lps_link_power_domain_pmos_voltage 33 2 lps_link_power_domain_power_mode 338 lps_link_power_domain_powerdown 318 lps_link_power_domain_standby 323 lps_link_power_domain_state 325 lps_link_power_domain_voltage 328 -lps_log_verbose 181 -lps_logfile 182 -lps_modules_wildcard 182 -lps_mtrn_min 183 -lps_mvs 183 -lps_no_xzshutoff 184 -lps_notlp 184 -lps_off 185 -lps_pmcheck_only 186 -lps_pmode 185 -lps_rtn_lock 187 -lps_rtn_off 188 -lps_sim_verbose 189 -lps_simctrl_on 188 -lps_srruleopt_warn 189 -lps_stdby_nowarn 190 -lps_stime 190 -lps_stl_off 191 -lps_upcase 191 -lps_verbose 192 -lps_verify 196
September 2011 346

-lps_vplan 196

M
Macro models 151 black box and gray box 151 treating as black box 173

N
Non-volatile memory modeling 33

P
Port isolation turning off 179 Power mode simulation controlling 185 suppressing informational messages 189 Power sidebar 215 in Design Browser 219 in Schematic Tracer 223 in Source Browser 220 in Waveform window 220 opening 215 Power-aware modeling 271 Verilog system tasks 272 $lps_enabled 307 $lps_get_power_domain 274 $lps_get_stime 308 $lps_link_power_domain_gnd_voltag e 293 $lps_link_power_domain_nmos_volt age 294 $lps_link_power_domain_nominal_c ondition 298 $lps_link_power_domain_pmos_volt age 295 $lps_link_power_domain_power_mo de 305 $lps_link_power_domain_powerdow n 279 $lps_link_power_domain_standby 284 $lps_link_power_domain_state 286 $lps_link_power_domain_voltage 2
Product Version 10.2

Low-Power Simulation

91 VHDL procedures 309 lps_enabled 341 lps_get_power_domain 311 lps_get_stime 344 lps_link_power_domain_gnd_voltage 330 lps_link_power_domain_nmos_volta ge 331 lps_link_power_domain_nominal_co ndition 335 lps_link_power_domain_pmos_volta ge 332 lps_link_power_domain_power_mod e 338 lps_link_power_domain_powerdown 318 lps_link_power_domain_standby 3 23 lps_link_power_domain_state 325 lps_link_power_domain_voltage 32 8

with save or restore preconditions 89 with separate save and restore controls 88 with single retention control 86

T
Tcl commands for low power 238 -testbench option 26 Top-level ports corruption of 73 Tracing signals 225

V
VHDL enumerated types corruption of 75 VPlan automatic generation of

196

S
set_design command -testbench option 26 set_sim_control command 29 disabling corruption 33 replaying initial blocks 30 Shutoff control expression specifying a constant 70 Signals tracing 225 Simulation-time control enabling 188 SimVision 215 Standby mode input violation messages 190 Start time specifying with -lps_stime 190 State loss and forced signals 81 turning off 191 State retention 82 excluding cells from 173 selecting targeted registers or instances 82 specifying control conditions 86 turning off 188
September 2011 347 Product Version 10.2

Low-Power Simulation

September 2011

348

Product Version 10.2

DeltaV Configuration
94% (16)
DeltaV Configuration
518 pages
DeltaV Configuration PDF
100% (1)
DeltaV Configuration PDF
518 pages
Component Description Format User Guide: Product Version 6.1.6 November 2013
No ratings yet
Component Description Format User Guide: Product Version 6.1.6 November 2013
192 pages
CPF User
No ratings yet
CPF User
207 pages
PPC464-S IV Databook
No ratings yet
PPC464-S IV Databook
228 pages
Gray Hat Hacking the Ethical Hacker's
From Everand
Gray Hat Hacking the Ethical Hacker's
Çağatay Şanlı
5/5 (1)
pg060 Floating Point
No ratings yet
pg060 Floating Point
81 pages
Sysgen User
No ratings yet
Sysgen User
350 pages
LowPower User
No ratings yet
LowPower User
74 pages
CFCB
No ratings yet
CFCB
136 pages
Img 20240313113733
No ratings yet
Img 20240313113733
154 pages
Xilinx System Generator For DSP PDF
No ratings yet
Xilinx System Generator For DSP PDF
376 pages
Modus Ug Pmbist
No ratings yet
Modus Ug Pmbist
261 pages
Sysgen User
No ratings yet
Sysgen User
416 pages
A Practical Guide To The UofU VLSI CAD Flow
No ratings yet
A Practical Guide To The UofU VLSI CAD Flow
8 pages
FPGA Tutorial
100% (1)
FPGA Tutorial
424 pages
Sysgen User
No ratings yet
Sysgen User
424 pages
Targeting 56800E PDF
No ratings yet
Targeting 56800E PDF
378 pages
Xilinx System Generator For DSP User Guide
100% (1)
Xilinx System Generator For DSP User Guide
424 pages
Digital ASIC Manual
100% (1)
Digital ASIC Manual
162 pages
Compiler Document
0% (1)
Compiler Document
133 pages
Fcug
No ratings yet
Fcug
101 pages
NEORV32 UserGuide-nightly
No ratings yet
NEORV32 UserGuide-nightly
48 pages
Alpha 21164 Data Sheet
No ratings yet
Alpha 21164 Data Sheet
122 pages
15h Mod 00h-0Fh BKDG
No ratings yet
15h Mod 00h-0Fh BKDG
639 pages
VHDLsim CMSG
No ratings yet
VHDLsim CMSG
114 pages
PA3 Nano UG
No ratings yet
PA3 Nano UG
326 pages
pg054 7series Pcie
No ratings yet
pg054 7series Pcie
398 pages
Pg054 7series Pcie en Us 3.3
No ratings yet
Pg054 7series Pcie en Us 3.3
413 pages
pg109-xfft - Copie
No ratings yet
pg109-xfft - Copie
98 pages
Book
No ratings yet
Book
40 pages
pg182 Gtwizard Ultrascale
No ratings yet
pg182 Gtwizard Ultrascale
130 pages
XuanTie C910 C920 UserManual
No ratings yet
XuanTie C910 C920 UserManual
415 pages
Pg060 Floating Point
No ratings yet
Pg060 Floating Point
105 pages
ChatGPT for Business: Strategies for Success
From Everand
ChatGPT for Business: Strategies for Success
Matthew C. Smith
No ratings yet
Pg056-Cpri v87
No ratings yet
Pg056-Cpri v87
180 pages
pg057 Fifo Generator PDF
No ratings yet
pg057 Fifo Generator PDF
221 pages
Sprugh 7
No ratings yet
Sprugh 7
1,013 pages
15h Mod 00h-0Fh BKDG
No ratings yet
15h Mod 00h-0Fh BKDG
629 pages
7601
No ratings yet
7601
211 pages
ST72F521 STMicroelectronics
No ratings yet
ST72F521 STMicroelectronics
215 pages
15h Models 30h-3Fh BKDG PDF
No ratings yet
15h Models 30h-3Fh BKDG PDF
706 pages
Manual HSPICE
0% (1)
Manual HSPICE
458 pages
Spruhx 9
No ratings yet
Spruhx 9
294 pages
CoreIP Clock
No ratings yet
CoreIP Clock
81 pages
PCIe Express
No ratings yet
PCIe Express
362 pages
m161 PDF
No ratings yet
m161 PDF
260 pages
Stm32f0xxx Cortexm0 Programming Manual Stmicroelectronics
No ratings yet
Stm32f0xxx Cortexm0 Programming Manual Stmicroelectronics
91 pages
DSP
No ratings yet
DSP
117 pages
Infineon XMC4500 RM
No ratings yet
Infineon XMC4500 RM
2,636 pages
Targeting 56800
No ratings yet
Targeting 56800
358 pages
xilinx-1G/10G/25G Switching Ethernet Subsystem
No ratings yet
xilinx-1G/10G/25G Switching Ethernet Subsystem
139 pages
Pg150 Ultrascale Memory Ip
No ratings yet
Pg150 Ultrascale Memory Ip
812 pages
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
From Everand
Securing ChatGPT: Best Practices for Protecting Sensitive Data in AI Language Models
Matthew C. Smith
No ratings yet
BlockChain for Beginners
From Everand
BlockChain for Beginners
Matthew Smith
No ratings yet
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
From Everand
The Linux Terminal for Advanced Users - The Command Line Made Easy: First Edition
Michael Basler
No ratings yet
10K Blueprint
From Everand
10K Blueprint
Cian O Farrell
5/5 (2)
Software Patterns Made Easy
From Everand
Software Patterns Made Easy
Justice Nanhou
No ratings yet
Cybersecurity for Executives: A Guide to Protecting Your Business
From Everand
Cybersecurity for Executives: A Guide to Protecting Your Business
Matthew C. Smith
No ratings yet
Web Video Business
From Everand
Web Video Business
MUHAMMAD NUR WAHID ANUAR
No ratings yet
7075
No ratings yet
7075
156 pages
Lab6 BCD-to-Excess-3 Code Conversion
No ratings yet
Lab6 BCD-to-Excess-3 Code Conversion
6 pages
An Introduction To Digital Image Processing
No ratings yet
An Introduction To Digital Image Processing
49 pages
Unit 1 - Lab 1-Flowchart
No ratings yet
Unit 1 - Lab 1-Flowchart
6 pages
Zfsboottalk Solaris Boot Zfsboot
No ratings yet
Zfsboottalk Solaris Boot Zfsboot
38 pages
EC574
No ratings yet
EC574
1 page
Fruit Detection and Sorting Based On Machine Learning
100% (1)
Fruit Detection and Sorting Based On Machine Learning
6 pages
History of Java Programming Language - WWW - Freejavaguide
No ratings yet
History of Java Programming Language - WWW - Freejavaguide
7 pages
Ioreg
No ratings yet
Ioreg
266 pages
The Systems Development Environment: Multiple Choice Questions
No ratings yet
The Systems Development Environment: Multiple Choice Questions
9 pages
Borislav Mirchev Kiril Borisov J2D 2014 Getting Started With Vaadin
No ratings yet
Borislav Mirchev Kiril Borisov J2D 2014 Getting Started With Vaadin
17 pages
Cheat Sheet For AIX User-Related Commands - AIX Content
No ratings yet
Cheat Sheet For AIX User-Related Commands - AIX Content
2 pages
Windows Services
No ratings yet
Windows Services
38 pages
ETSE Zeiss PCM Overview1
No ratings yet
ETSE Zeiss PCM Overview1
16 pages
Enhancement of DNVME Device Driver
No ratings yet
Enhancement of DNVME Device Driver
4 pages
Obout Calender Component
No ratings yet
Obout Calender Component
2 pages
GoToMyPC Overview White Paper
No ratings yet
GoToMyPC Overview White Paper
6 pages
VC# Connect Postgres
No ratings yet
VC# Connect Postgres
17 pages
VIAP
No ratings yet
VIAP
7 pages
Important ABAP Functions - 29oct2007
100% (1)
Important ABAP Functions - 29oct2007
6 pages
Standard Cell
No ratings yet
Standard Cell
133 pages
Enrollment System Thesis
67% (12)
Enrollment System Thesis
8 pages
NUS MA4268 Ch1
No ratings yet
NUS MA4268 Ch1
9 pages
Structured Query Language
No ratings yet
Structured Query Language
2 pages
Lesson 5 of C Programming
100% (1)
Lesson 5 of C Programming
25 pages
Entrust IdentityGuard 8.1 Directory Configuration Guide
100% (1)
Entrust IdentityGuard 8.1 Directory Configuration Guide
62 pages
AWS Notes
No ratings yet
AWS Notes
37 pages
Image Inpainting Using Partial Convolution
No ratings yet
Image Inpainting Using Partial Convolution
6 pages
Exploring Expect
No ratings yet
Exploring Expect
3 pages
The Complete Windows Programming Guide - MFC Tutorials
100% (1)
The Complete Windows Programming Guide - MFC Tutorials
610 pages

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.