Power Forward Ug

Low-Power Simulation Guide

Product Version 10.2September 2011

© 2006–2011 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 Cadence’s 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

1Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2CPF Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

CPF Support in Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14General CPF Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Library Cell-Related CPF Command Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23set_hierarchy_separator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25set_design / end_design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26set_instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28set_sim_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29create_assertion_control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Expressions in CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Feedthrough Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41SystemVerilog Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47VHDL Coding Style Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

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

Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Base and Derived Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Declaring Boundary Ports with the -boundary_ports Option . . . . . . . . . . . . . . . . . . . 63

State Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Verilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Specifying a Constant for a Shutoff Control Expression . . . . . . . . . . . . . . . . . . . . . . . 70Corruption of Top-Level Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

September 2011 3 Product Version 10.2


Corruption of VHDL User-Defined Enumerated Types . . . . . . . . . . . . . . . . . . . . . . . . 75State Loss and Forced Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Disabling Corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

State Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Selecting the Targeted Registers or Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Identification of Sequential Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Specifying the Control Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Incomplete State Retention Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Selecting the Targeted Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Ignoring Isolation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Isolation Rule Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Controlling Isolation Enable and Disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Specifying Isolation Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Back-to-Back Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Specifying a Secondary Domain for an Isolation Rule . . . . . . . . . . . . . . . . . . . . . . . 121Viewing Isolation Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Logging Isolation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4Using CPF for Designs with DVFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Controlling a Power Mode Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Power Mode Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Controlling Power Domain Transitions with Power Mode and Mode Transition Controls 129

Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Specifying the Power Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Describing the Power Mode Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Controlling Power Domain Transitions with Domain-Level Controls . . . . . . . . . . . . . . . 139Defining the Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Specifying the Conditions for the Power Domains to Transition to Specific Nominal Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Specifying the Delay for a Power Domain to Reach its Destination Nominal Condition . 140Running the Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Power Mode Control Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142



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

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

Writing a CPF Model for a Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Macro Model CPF Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Defining the Macro Model Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Defining Isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Defining State Retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Explicit Code to Handle X Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162CPF File for the Macro Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Integrating the Macro Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164CPF File for the Top Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

6Running a Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Running in Multi-Step Invocation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Simulating with irun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Simulating with ncverilog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Command-Line Options for Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

-lps_alt_srr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172-lps_assign_ft_buf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172-lps_blackboxmm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173-lps_cellrtn_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173-lps_cpf cpf_filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174-lps_dtrn_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174-lps_enum_rand_corrupt [seed] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175-lps_enum_right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176-lps_implicit_pso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176-lps_implicitpso_char ‘value’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177-lps_implicitpso_nonchar value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178-lps_iso_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179-lps_iso_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179-lps_isofilter_verbose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180



-lps_isoruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181-lps_log_verbose filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181-lps_logfile filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182-lps_modules_wildcard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182-lps_mtrn_min . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183-lps_mvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183-lps_no_xzshutoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184-lps_notlp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184-lps_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185-lps_pmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185-lps_pmcheck_only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186-lps_rtn_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187-lps_rtn_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188-lps_simctrl_on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188-lps_srruleopt_warn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189-lps_sim_verbose report_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189-lps_stdby_nowarn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190-lps_stime start_time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190-lps_stl_off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191-lps_upcase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191-lps_verbose {1 | 2 | 3} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192-lps_verify . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196-lps_vplan vplan_filename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

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

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

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

Simulating a Gate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Defining Low-Power Cells Instantiated in the Netlist . . . . . . . . . . . . . . . . . . . . . . . . 208



Disabling the Implicit CPF Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Example CPF File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Simulating a Mixed RTL/Gate Design with Instantiated Primitive Cells . . . . . . . . . . . . . 213

9Debugging a Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Debugging with SimVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Invoking SimVision for Low-Power Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Opening the Power Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Using the Power Sidebar in the Design Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Using the Power Sidebar in the Source Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Using the Power Sidebar in the Waveform Window . . . . . . . . . . . . . . . . . . . . . . . . . 220Using the Power Sidebar in the Schematic Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . 223Tracing Signals in a Power Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Viewing Assertion States during a Power Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 229

Debugging Power Modes with SimVision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231The Power Sidebar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Viewing Power Mode Information in the Waveform Window . . . . . . . . . . . . . . . . . . 233

Tcl Command Enhancements for Low Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Describing Low-Power Information for the Design . . . . . . . . . . . . . . . . . . . . . . . . . . 239Displaying Information about Power Domains and Power Modes . . . . . . . . . . . . . . 239Setting Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Displaying the Saved Value of a State Retention Variable . . . . . . . . . . . . . . . . . . . . 251Probing Control Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Probing Power Mode Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Displaying the Drivers of an Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

Debugging Infinite Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

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

Generating Assertions to Verify Power Control Signals . . . . . . . . . . . . . . . . . . . . . . . . . 257Automatically-Generated Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Generating a Coverage Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Generating a Verification Plan for Power Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267



11Power-Aware Modeling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Verilog System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272$lps_get_power_domain(<power_domain_register>[, <instance>]); . . . . . . . . . . . . 274$lps_link_power_domain_powerdown(<link_register>[,<power_domain>); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279$lps_link_power_domain_standby(<link_register>[, <power_domain>]); . . . . . . . . . 284$lps_link_power_domain_state(<link_register> [,<power_domain>]) . . . . . . . . . . . 286$lps_link_power_domain_voltage(<link_variable>[, <power_domain>]); . . . . . . . . . 291$lps_link_power_domain_gnd_voltage(<link_variable>[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293$lps_link_power_domain_nmos_voltage(<link_variable>[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294$lps_link_power_domain_pmos_voltage(<link_variable>[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295$lps_link_power_domain_nominal_condition(<link_register>[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298$lps_link_power_domain_power_mode(<link_register>[, <power_domain>]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305$lps_enabled(); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307$lps_get_stime(); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

VHDL Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309lps_get_power_domain (“power_domain_signal”[, “instance_path”]); . . . . . . . . . . . 311lps_link_power_domain_powerdown(“link_signal”[, power_domain]); . . . . . . . . . . . 318lps_link_power_domain_standby(“link_signal”[, power_domain]); . . . . . . . . . . . . . . 323lps_link_power_domain_state(“link_signal”[, power_domain]); . . . . . . . . . . . . . . . . 325lps_link_power_domain_voltage(“link_signal”[, power_domain]); . . . . . . . . . . . . . . 328lps_link_power_domain_gnd_voltage(“link_signal”[, power_domain]); . . . . . . . . . . 330lps_link_power_domain_nmos_voltage(“link_signal”[, power_domain]); . . . . . . . . . 331lps_link_power_domain_pmos_voltage(“link_signal”[, power_domain]); . . . . . . . . . 332lps_link_power_domain_nominal_condition(“link_signal”[, power_domain]); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335lps_link_power_domain_power_mode(“link_signal”[, power_domain]); . . . . . . . . . . 338lps_enabled(“signal_name”); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341lps_get_stime(“signal_name”); . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344



Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345





1Introduction

Note: The low-power simulation functionality described in this document is available with the Incisive Enterprise Simulator XL (IES-XL) product.

The Power Forward Initiative is an industry-wide effort to establish a single standard format for specifying all power-specific design, constraint, and functionality requirements for a design. This new standard, called the Common Power Format (CPF), captures all design and technology-related power constraints in a single file. The CPF file acts as the sole repository for all power-related information from design through verification and implementation. This enables an entire multi-specialist project team to work from a common view of the low-power intent of the design and ensures consistency throughout the flow.

In time, the entire Cadence verification, validation, synthesis, test, physical synthesis, routine, analysis, and signoff tool flow will support the CPF-based methodology. Currently, CPF is supported by the following Cadence products:

■ Encounter Conformal Low Power

■ Encounter Digital Implementation System

■ Encounter Power System

■ Encounter RTL Compiler

■ Encounter Test Architect

■ Encounter Timing System

■ Incisive Enterprise Manager

■ Incisive Enterprise Simulator

■ Incisive Palladium

Note: For information on the product option, feature, or package that supports CPF, contact your local sales representative or AE.

Refer to the product documentation for information on:


Low-Power SimulationIntroduction

■ 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



2CPF 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_*}


-instances {mcore0/ahb0 \

mcore?/*/dsu0 \

mcore*/?/dcom0 \

mcore0/as*/asm \

mcore0/uart?} \

-shutoff_condition {...}


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



If a command is not applicable to simulation, or if the command is not yet supported, options to that command are not shown in the table.

Command Options Valid in CPF Version Comment Support

Status

assert_illegal_domain_configurations -- -- 1.1 U

create_analysis_view 1.0 1.0e 1.1 U

create_assertion_control -- 1.0e 1.1 See create_assertion_control S

-assertions -- 1.0e 1.1 S

-domains -- 1.0e 1.1 S

-exclude -- -- 1.1 U

-name -- 1.0e 1.1 S

-shutoff_condition -- 1.0e 1.1 S

-type -- 1.0e 1.1 S

create_bias_net 1.0 1.0e 1.1 NA

create_global_connection 1.0 1.0e 1.1 NA

create_ground_nets 1.0 1.0e 1.1 NA

create_isolation_rule 1.0 1.0e 1.1 See Isolation S

-exclude 1.0 1.0e 1.1 S

-from 1.0 1.0e 1.1 S

-isolation_condition 1.0 1.0e 1.1 S

-isolation_output 1.0 1.0e 1.1 -isolation_output tristate is notsupported.

S

-isolation_target 1.0 1.0e 1.1 See Back-to-Back Isolation S

-name 1.0 1.0e 1.1 S

-no_condition -- 1.0e 1.1 S

-pins 1.0 1.0e 1.1 S

-secondary_domain -- 1.0e 1.1 S

-to 1.0 1.0e 1.1 S



create_level_shifter_rule 1.0 1.0e 1.1 U

create_mode_transition 1.0 1.0e 1.1 See Describing the PowerMode Transitions

S

-clock_pin 1.0 1.0e 1.1 U

-end_condition 1.0 1.0e 1.1 S

-cycles 1.0 1.0e 1.1 U

-from -- 1.0e 1.1 S

-from_mode 1.0 -- -- Replaced with -from inCPF 1.0e

U

-latency 1.0 1.0e 1.1 S

-name 1.0 1.0e 1.1 S

-start_condition 1.0 1.0e 1.1 S

-to -- 1.0e 1.1 S

-to_mode 1.0 -- -- Replaced with -to in CPF 1.0e U

create_nominal_condition 1.0 1.0e 1.1 See Defining the NominalConditions

S

-ground_voltage -- 1.0e 1.1 U

-nmos_bias_voltage 1.0 1.0e 1.1 U

-name 1.0 1.0e 1.1 S

-pmos_bias_voltage 1.0 1.0e 1.1 U

-state -- 1.0e 1.1 S

-voltage 1.0 1.0e 1.1 S


Status



create_operating_corner 1.0 1.0e 1.1 U

create_power_domain 1.0 1.0e 1.1 See Power Domains S

-active_state_conditions -- 1.0e 1.1 S

-base_domains -- -- 1.1 S

-boundary_ports 1.0 1.0e 1.1 S

-default 1.0 1.0e 1.1 S

-default_isolation_condition -- 1.0e 1.1 S

-default_restore_edge 1.0 1.0e 1.1 S

-default_restore_level -- 1.0e 1.1 S

-default_save_edge 1.0 1.0e 1.1 S

-default_save_level -- 1.0e 1.1 S

-external_controlled_shutoff -- 1.0e 1.1 S

-instances 1.0 1.0e 1.1 S

-name 1.0 1.0e 1.1 S

-power_up_states 1.0 1.0e 1.1 U

-secondary_domains -- 1.0e -- Replaced with -base_domainsin CPF 1.1

S

-shutoff_condition 1.0 1.0e 1.1 S

create_power_mode 1.0 1.0e 1.1 See Specifying the PowerModes

S

-default 1.0 1.0e 1.1 S

-domain_conditions 1.0 1.0e 1.1 S

-group_modes -- 1.0e 1.1 S

-name 1.0 1.0e 1.1 S


Status



create_power_nets 1.0 1.0e 1.1 U

create_power_switch_rule 1.0 1.0e 1.1 U

create_state_retention_rule 1.0 1.0e 1.1 See “State Retention” on page 82 for details on this command and for information on selecting state elements for retention.

S

-domain 1.0 1.0e 1.1 S

-exclude -- 1.0e 1.1 S

-instances 1.0 1.0e 1.1 S

-name 1.0 1.0e 1.1 S

-restore_edge 1.0 1.0e 1.1 S

-restore_level -- 1.0e 1.1 S

-restore_precondition -- 1.0e 1.1 S

-save_edge 1.0 1.0e 1.1 S

-save_level -- 1.0e 1.1 S

-save_precondition -- 1.0e 1.1 S


-target_type -- 1.0e 1.1 U

define_library_set 1.0 1.0e 1.1 U

end_design 1.0 1.0e 1.1 S

module -- -- 1.1 S

end_macro_model -- 1.0e -- S

macro_cell -- -- 1.1 S

end_power_mode_control_group -- 1.0e 1.1 S


Status



get_parameter -- 1.0e 1.1 U

identify_always_on_driver 1.0 1.0e 1.1 U

identify_power_logic 1.0 1.0e 1.1 U

identify_secondary_domain -- 1.0e 1.1 S

-cells -- 1.0e 1.1 S

-domain -- 1.0e 1.1 S

-from -- 1.0e 1.1 S

-instances -- 1.0e 1.1 S


-to -- 1.0e 1.1 S

include -- 1.0e 1.1 S

file -- 1.0e 1.1 S

set_array_naming_style 1.0 1.0e 1.1 U

set_cpf_version 1.0 1.0e 1.1 S

value 1.0 1.0e 1.1 S

set_design 1.0 1.0e 1.1 A -testbench option is alsosupported. See set_design /end_design.

S

module 1.0 1.0e 1.1 S

-honor_boundary_port_domain -- 1.0e 1.1 U

-parameters -- 1.0e 1.1 U

-ports 1.0 1.0e 1.1 S

set_equivalent_control_pins -- 1.0e 1.1 U

set_floating_ports -- 1.0e 1.1 U

set_hierarchy_separator 1.0 1.0e 1.1 See set_hierarchy_separator S

character 1.0 1.0e 1.1 S


Status



set_input_voltage_tolerance -- 1.0e 1.1 U

set_instance 1.0 1.0e 1.1 See set_instance. S

-design -- 1.0e 1.1 U

-domain_mapping -- 1.0e 1.1 This option is supported, but with limitations. See set_instance.

S

instance 1.0 1.0e 1.1 S

-merge_default_domains 1.0 -- -- Replaced with-domain_mapping in CPF 1.0e

U

-model -- 1.0e 1.1 U

-of_macro -- 1.0e -- No replacement U

-parameter_mapping -- 1.0e 1.1 U

-port_mapping 1.0 1.0e 1.1 S

set_macro_model -- 1.0e 1.1 See Chapter 5, “Modeling a Macro Cell,”.

S

macro_cell -- 1.0e 1.1 S

set_power_mode_control_group -- 1.0e 1.1 S

-domains -- 1.0e 1.1 S

-groups -- 1.0e 1.1 S

-name -- 1.0e 1.1 S


Status



set_power_target 1.0 1.0e 1.1 U

set_power_unit 1.0 1.0e 1.1 U

set_register_naming_style 1.0 1.0e 1.1 U

set_sim_control -- -- -- This command has beenproposed for CPF 2.0. It is notincluded in the CPF 1.1specification. Nodocumentation is available inthe CPF LanguageReference. Seeset_sim_control.

S

-action power_up_replay -- -- -- S

-action disable_corruption -- -- -- S

-action disable_isolation -- -- -- U

-action disable_retention -- -- -- U

-controlling_domain -- -- -- S

-domains -- -- -- U

-exclude -- -- -- S

-instances -- -- -- S

-lib_cells -- -- -- U

-modules -- -- -- S

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

S

-type -- -- -- S

set_switching_activity 1.0 1.0e 1.1 U

set_time_unit 1.0 1.0e 1.1 S

{ms | ns | us} 1.0 1.0e 1.1 S


Status



set_wire_feedthrough_ports -- 1.0e 1.1 U

update_isolation_rules 1.0 1.0e 1.1 U

update_level_shifter_rules 1.0 1.0e 1.1 U

update_nominal_condition 1.0 1.0e 1.1 U

update_power_domain 1.0 1.0e 1.1 See Specifying the Delay for aPower Domain to Reach itsDestination Nominal Condition

S

-equivalent_ground_nets -- -- 1.1 U

-equivalent_power_nets -- -- 1.1 U

-internal_ground_net 1.0 -- -- Replaced with-primary_ground_net inCPF 1.0e

U

-internal_power_net 1.0 -- -- Replaced with-primary_power_net inCPF 1.0e

U

-library_set 1.0 -- -- No replacement U

-max_power_up_time 1.0 -- -- Replaced with-transition_latency and-transition_cycles in CPF 1.0e

U

-min_power_up_time 1.0 -- -- U

-name 1.0 1.0e 1.1 S

-nmos_bias_net 1.0 1.0e 1.1 U

-pmos_bias_net 1.0 1.0e 1.1 U

-primary_ground_net -- 1.0e 1.1 U

-primary_power_net -- 1.0e 1.1 U

-rail_mapping 1.0 -- -- No replacement U

-transition_cycles -- 1.0e 1.1 U

-transition_latency -- 1.0e 1.1 U

-transition_slope -- 1.0e 1.1 S

-user_attributes 1.0 1.0e 1.1 U

update_power_mode 1.0 1.0e 1.1 U

update_power_switch_rule 1.0 1.0e 1.1 U

update_state_retention_rules 1.0 1.0e 1.1 U


Status



Library Cell-Related CPF Command Support

In the following table, the Status column has one of the following values:

■ S: supported

■ U: unsupported

■ NA: not applicable to simulation

If a command is not applicable to simulation, or if the command is not yet supported, options to that command are not shown in the table.


Status

define_always_on_cell 1.0 1.0e 1.1 See Defining Always-On Cells S

-cells 1.0 1.0e 1.1 S

-ground 1.0 1.0e 1.1 U

-ground_switchable 1.0 1.0e 1.1 U

-library_set 1.0 1.0e 1.1 U

-power 1.0 1.0e 1.1 U

-power_switchable 1.0 1.0e 1.1 U



define_isolation_cell 1.0 1.0e 1.1 See Defining Isolation Cells S

-always_on_pin 1.0 Replaced with-always_on_pins in CPF 1.0e

U

-always_on_pins -- 1.0e 1.1 S

-cells 1.0 1.0e 1.1 S

-enable 1.0 1.0e 1.1 S

-ground 1.0 1.0e 1.1 U


-library_set 1.0 1.0e 1.1 S

-no_enable -- 1.0e 1.1 U

-non_dedicated 1.0 1.0e 1.1 U

-power 1.0 1.0e 1.1 U


-valid_location 1.0 1.0e 1.1 U


Status



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:

define_level_shifter_cell 1.0 1.0e 1.1 U

define_open_source_input_pin 1.0 1.0e 1.1 U

define_power_clamp_cell 1.0 1.0e 1.1 U

define_power_switch_cell 1.0 1.0e 1.1 U

define_related_power_pins -- 1.0e 1.1 U

define_state_retention_cell 1.0 1.0e 1.1 See Defining State RetentionCells

S

-always_on_components -- 1.0e 1.1 S

-always_on_pin 1.0 -- -- Replaced with-always_on_pins in CPF 1.0e

U

-always_on_pins -- 1.0e 1.1 S

-cells 1.0 1.0e 1.1 S

-cell_type -- 1.0e 1.1 S

-clock_pin 1.0 1.0e 1.1 S

-ground 1.0 1.0e 1.1 U


-library_set 1.0 1.0e 1.1 U

-power 1.0 1.0e 1.1 U


-restore_check 1.0 1.0e 1.1 U

-restore_function 1.0 1.0e 1.1 S

-save_check 1.0 1.0e 1.1 U

-save_function 1.0 1.0e 1.1 S


Status



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



# File top.cpf # File top.cpf

set_cpf_version 1.0e set_cpf_version 1.0e

set_hierarchy_separator / set_hierarchy_separator /

set_design tb_top -testbench set_design tb_top -testbench

[CPF commands for testbench. [CPF commands for testbench.

Does not include the definition Does not include the definition

of a default power domain.] of a default power domain.]

set_instance dut_inst set_instance dut_inst

set_design dut source dut.cpf

[CPF commands for DUT. end_design

end_design

end_design # File dut.cpf

set_cpf_version 1.0e


set_design dut

[CPF commands for DUT]

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)



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

Macro model blocks 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.



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.

Other blocks(non-macro cell blocks)

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.

Mapping Type IES 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*}



If the argument to -targets is the full wildcard character (-targets {*}), all initial blocks, including blocks without labels, in the specified scope are selected.

Note: In addition to replaying all labeled and unlabeled initial blocks, the -targets {*} option also replays variables that are initialized in their declaration statement. For example, the following variables will be reinitialized when power is restored:

reg aaa = 1`b1;

integer delay = 10;

The -exclude option excludes the specified initial blocks from the list of blocks selected with -targets. If a block specified with -exclude is not in the list of blocks selected with -targets, the block is ignored. The following command selects all initial blocks whose label starts with L, but excludes those blocks whose label starts with L1.

set_sim_control -action power_up_replay -targets {L*} -exclude {L1*}

By default, the -targets and -exclude options select initial blocks in the CPF scope where the command is used. The -instances and -modules options let you select initial blocks from other scopes.

■ -instances specifies a list of hierarchical instances from which the initial blocks will be selected. Initial blocks are not selected from instances below the specified instances. For example, the following options select all initial blocks with the label L in instance A.B.C only.

-targets {L} -instances {A.B.C}

■ -modules specifies a list of module names. This option performs a tree search and selects initial blocks in all instances of the specified modules under the current scope (or the scopes selected with the -instances option). For example, the following options select all initial blocks with the label L in all instances of modules M1 and M2.

-targets {L} -modules {M1 M2}

You can use the * and ? wildcard characters in the module(s) specified with the -modules option. You must use the elaborator -lps_modules_wildcard option (ncelab -lps_modules_wildcard or irun -lps_modules_wildcard) to enable the use of wildcard characters in the argument to the -modules option.

Caution

Be careful when using wildcards in the module_list argument to the -modules option. The -modules option performs a tree search starting at the current scope, or the scope specified with -instances. Every initial block in the current scope down to the leaf scopes will be replayed. Using a wildcard to specify the modules can result in accidentally replaying



initial blocks in unintended modules. Using a wildcard at a high-level scope will also adversely affect elaborator performance. Use the following guidelines when using wildcards:

❑ Limit the scope to somewhere near the leaf of the hierarchy. This will lessen the chance of accidentally replaying unintended modules.

❑ Use one of the following forms: abc*, *abc, abc*def.

❑ Using a wildcard with no qualifiers (-modules *) is strongly discouraged. This will match every module at that scope and below.

You can use the -controlling_domain domain option to specify the power domain that controls the initial block replay. The specified initial blocks are replayed when the domain specified with -controlling_domain is powered up. The default controlling domain is the power domain of the logic hierarchy containing the selected initial block.

Note: An initial block cannot be replayed unless it has completed executing. For example, the following initial block will not be replayed because it will never stop executing.

reg xxx;

...

initial begin

xxx = 0;

forever #10 xxx = !xxx;

end

This initial block can be rewritten as follows:

initial begin

xxx = 0;

end

always

#10 xxx = !xxx;

Examples

Replay all initial blocks with a label that starts with L in instance iSTAR only.

set_sim_control -action power_up_replay -targets {L*} -instances {iSTAR}

Replay all initial blocks, including blocks with statements that do not have a label, in instance iSTAR only. Variables that are initialized in their declaration statement are also replayed.

set_sim_control -action power_up_replay -targets {*} -instances {iSTAR}



Replay all initial blocks, and all variables that are initialized in their declaration statement, in all instances of module M, beginning with the current scope. The -modules option performs a tree search.

set_sim_control -action power_up_replay -targets {*} -modules {M}

Replay all initial blocks, and all variables that are initialized in their declaration statement, in all instances of module M, beginning with the current scope, except for block L1.

set_sim_control -action power_up_replay -targets {*} -modules {M} -exclude {L1}

Replay all initial blocks, and all variables that are initialized in their declaration statement, in all instances of module M starting at instance iSTAR. This is a tree search starting at iSTAR.

set_sim_control -action power_up_replay -targets {*} -instances {iSTAR} -modules {M}

Replay all initial blocks with a label that starts with L in modules whose names begin with RAM, starting at scope inst_A.

set_sim_control -action power_up_replay -targets {L*} \

-instances inst_A -modules {RAM*}

Replay all initial blocks L in the current scope. This command is the same as: -targets {L} -instances <current_scope>.

set_sim_control -action power_up_replay -targets {L}

Disabling Corruption of Verilog reg Variables

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. Disabling corruption of these variables allows you to model non-volatile memory.

Syntax:

set_sim_control

[-targets target_list [-exclude target_list]]

-action disable_corruption -type reg

[-instances instance_list]

[-modules module_list]

The -action disable_corruption option specifies that the simulator must ignore the default simulation corruption semantics for the selected targets. You must include the -type option to specify the type of the target objects. In the current release, the only supported argument is reg, which selects only reg type variables from the RTL.

set_sim_control -action disable_corruption -type reg



Use the -targets and -exclude options to specify the list of registers that should not be corrupted when power is shut off. The argument to both options is a list of registers. You can specify hierarchical names, and wildcards are supported. For example:

# Disable corruption of q1, q2, and q3 in the CPF scope where the command is used

set_sim_control -action disable_corruption -type reg \

-targets {q1 q2 q3}

# Disable corruption of all regs in scope dut3


-targets {dut3.*}

# Disable corruption of all regs in scope dut3, except q3


-targets {dut3.*} -exclude {q3}

By default, the -targets and -exclude options select reg variables in the CPF scope where the command is used. The -instances and -modules options let you select regs from other scopes.

■ -instances specifies a list of hierarchical instances from which the regs will be selected. Regs in instances below the specified instances are not selected. Instance names can contain wildcards.

When -instances is specified, -targets is optional.

❑ If -targets is not specified, all regs in the specified instances are selected.

❑ If -targets is specified, the target regs in the specified instances are selected .

For example:

# Disable the corruption of all regs in instances tb_top.dut and dut2 only


-instances {tb_top.dut dut2}

# Disable the corruption of regs q1 and q2 in instances tb_top.dut and dut2 only


-targets {q1 q2} -instances {tb_top.dut dut2}

■ -modules specifies a list of module names. If this option is specified, all instances of the specified module(s) in the current CPF scope (or the scope(s) specified with -instances) are searched hierarchically, and regs are selected only from the instances of the specified modules. Module names can contain wildcards.

When -modules is specified, -targets is optional.



❑ If -targets is not specified, all 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


-modules {mod1 mod2}

# Disable corruption of regs q1 and q2 in all instances of modules mod1 and mod2


-targets {q1 q2} -modules {mod1 mod2}

# Disable corruption of all regs in all instances of modules mod1 and mod2.# Exclude reg q1 from this list


-targets {*} -modules {mod1 mod2} -exclude {q1}

■ If you specify both the -instances and -modules options, all specified instances are searched, but targets are selected only from instances of the specified modules.

# Disable corruption of all regs in all instances of module M starting at# instance iSTAR. This is a tree search starting at iSTAR.


-targets {*} -instances {iSTAR} -modules {M}

# Disable corruption of all regs with a name that starts with reg in modules# whose names begin with RAM, starting at scope inst_A.


-targets {reg*} -instances inst_A -modules {RAM*}

create_assertion_control

Turns off the evaluation of selected assertion instances related to a power domain when that power domain is shut down. By default, assertions remain active when the power domain is powered down.

You can control the evaluation of both SystemVerilog and PSL assertions.

The set of assertion instances to be controlled can be specified by:

■ Providing a list of assertion instances using the -assertions option. Assertion names can be simple names or hierarchical names. Assertion names can contain wildcards.



■ Specifying a list of power domains using the -domains option. All assertions that appear in any hierarchical instance associated with a specified power domain will be turned off. You cannot use wildcards in the power_domain_list.

In a create_assertion_control command, the default shutoff condition for the selected assertions is the shutoff condition specified with the -shutoff_condition option in the create_power_domain command. However, using the power domain shutoff condition as the assertion shutoff condition can lead to a race condition between corruption caused by shutting off the logic in the power domain (which could cause an assertion to trigger) and the disabling of assertions using the create_assertion_control command.

It is recommended that you use the create_assertion_control -shutoff_condition option to specify the condition when the assertions should be disabled. This shutoff condition should be active before the domain shuts off, and stay active until after it powers up (the isolation enable signal, for example).

Use the -type option to specify if the selected assertions are reset or suspended when they are turned off. The default is reset.

Examples

In the following example, the create_assertion_control command suppresses the evaluation of two assertion instances associated with hierarchical instance add_ef. Instance add_ef belongs to power domain PD_add_ef. The assertions are turned off when iso_en is enabled. The -type reset option is included to specify that the assertions should be reset. Because reset is the default behavior, the -type option could be omitted.

create_power_domain -name PD_add_ef \

-instances {add_ef} \

-shutoff_condition {u_pmc/pso_en[2] & u_pmc/cond_3[2]}

...

...


-assertions {add_ef/SVA_A1 add_ef/SVA_A2} \

-shutoff_condition {iso_en} \

-type reset

In the following example, the create_assertion_control command suppresses the evaluation of all assertion instances associated with all instances included in the power domains PD_add_ab and PD_mux.

create_power_domain -name PD_add_ab \

-instances {add_ab} \

-shutoff_condition {u_pmc/pso_en[0] & u_pmc/cond_3[0] }



create_power_domain -name PD_mux \

-instances {mux} \

-shutoff_condition {u_pmc/pso_en[3] & u_pmc/cond_3[3]}


-domains {PD_add_ab PD_mux}

-shutoff_condition {iso_en} \

-type suspend

Note: Some assertions are given automatically-generated names. These include PSL assertions derived from synthesis pragmas (for example, // synopsys full_case) and properties that can accept parameters. You can control these assertions by specifying an instance and using the wildcard character, or by using the -domains option, which will turn off all assertions in the specified power domains. For example:

-assertions {mux/*}

-domains {PD1 PD2}

Note: Immediate assertions (procedural assertions that check only a single combinational condition) are not supported. For example, the assertion in the following code cannot be turned off with a create_assertion_control command.

always @(posedge clk)

if (reset)

begin

temp <= ’b00000000;

resetchk: assert (reset) $display("Reset is now active"); //Immediate assertion

end

else

temp <= a + b;

Expressions in CPF Commands

In many CPF commands, you specify a control condition. For example, in a create_power_domain command, you use the -shutoff_condition option to specify the condition when the power domain is shut off, or in a create_isolation_rule command, you use the -isolation_condition option to specify the condition when the specified pins should be isolated.

These control conditions are indicated in the CPF specification by using the word expression as the argument to a command option. For example:

create_power_domain ... -shutoff_condition expression



The expression can be a complex expression (unless explicitly noted otherwise in the CPF specification).

Verilog syntax is used in expressions.

The following restrictions apply to expressions in control conditions:

■ The final result of the expression evaluation must be one bit wide.

■ Only the following operators are allowed:

■ For the binary operators, the operands must be one bit wide. In the following example expressions, pse and ice are one bit wide, and pge is a 3-bit vector (pge[0:2]).

{top.pse}

{!top.pse}

{top.pge[2]}

{top.pse | top.ice}

{!top.pse | !top.ice}

{!(top.pse | top.ice)}

{top.pse | top.ice & top.pge[1]}

{(top.pse | top.ice) & top.pge[0]}

{top.pse & (!top.ice ^ top.pge[2])}

The expression is evaluated using the precedence order specified in the Verilog LRM. From highest to lowest, the precedence order is as follows:

!

&

^

! logical negation

& bit-wise binary and

| bit-wise binary or

^ bit-wise binary xor

~^ or ^~ bit-wise binary xnor

& reduction and

| reduction or

^ reduction xor



~^ or ^~

|

For example, the expression:

w | x & y ^ z

evaluates to:

w | ((x & y) ^ z)

Parentheses can be used to change the operator precedence.

■ The reduction operators are unary operators whose operand is a vector, and whose result is equivalent to applying the corresponding logical operator to each of the elements of the vector. For example:

reg [0:1] enable;

reg [0:3] out;

{&out}

// Same as: {out[0] & out[1] & out[2] & out[3]}

{&enable | |out}

// Same as: {(enable[0] & enable[1]) | (out[0] | out[1] | out[2] | out[3])}

{&out | enable[0]}

// Same as: {(out[0] & out[1] & out[2] & out[3]) | enable[0]}

{enable[1] & ôut}

// Same as: {enable[1] & (out[0] ^ out[1] ^ out[2] ^ out[3])}

The operand of the reduction operator must be an object. The operand cannot be an expression. For example:

reg [0:1] a;

reg [0:3] b;

{!&a} // Supported

{&a|&b} // Supported. Parsed as {&a | (&b)}

{a&|b} // Supported. Parsed as {a & (|b)}

{&!a} // Not supported

{&(a|b)} // Not supported

Because of confusion with the Verilog logical operators && and ||, the following expressions generate an error stating that the && or || operator is not a legal operator in a CPF expression:



{a||b} // Error. Not parsed as {a | (|b)}

{a&&b} // Error. Not parsed as {a & (&b)}

Limitations

The following limitations exist in the current release:

■ A power domain that is subject to power shutoff can consist of Verilog instances and VHDL components. SystemC constructs and/or data structures cannot be part of a power-down domain. The elaborator generates a warning if it detects SystemC constructs in a power-down domain, and the constructs are ignored.

■ Only digital components are supported. Verilog AMS or VHDL AMS components located inside a power domain that is subject to power shutoff are ignored with a warning.

■ Only synthesizable code is supported in a power domain that is subject to power shutoff.

■ The current release includes support for feedthrough wires. See “Feedthrough Wires” on page 41 for details on feedthrough support for Verilog, VHDL, and mixed Verilog/VHDL designs.

■ There are some limitations on the simulator’s ability to identify state elements to be replaced with state retention registers. These state elements are specified with create_state_retention_rule commands. See “State Retention” on page 82 for more information.

■ The set_instance -domain_mapping option is used in a hierarchical flow to specify the mapping of block-level power domains to power domains at a higher level. This option is only supported for instantiated macro models and for mapping a domain to the testbench-level domain. See “set_instance” on page 28 for details.

■ The current release supports SystemVerilog interfaces and modports at power domain boundaries as well as within a power shutoff domain. All other SystemVerilog constructs and/or data structures cannot be part of a power-down domain. The elaborator generates a warning if it detects these SystemVerilog constructs in a power-down domain, and the constructs are ignored. See “SystemVerilog Interfaces” on page 47 for information on support for SystemVerilog interfaces.

■ Some VHDL coding styles can have a significant effect on the accuracy of low-power simulations. See “VHDL Coding Style Recommendations” on page 49 for details.

■ Low-power simulation behavior is done through the implicit behavior specified by CPF commands or through the cell simulation models in the netlist. When simulating a low-power design at the RTL level, the implicit behavior (isolation, state retention, and power down) is provided by commands in the CPF file. When simulating a post-synthesis netlist, the low-power behavior is provided by the cell simulation models, and the virtual



logic implicitly modeled by the simulator must be disabled by using command-line options (-lps_iso_off and -lps_rtn_off).

You should not instantiate low-power cells in your RTL code in some, but not all, locations. The implicit CPF behavior is either enabled, in which case the implicit behavior will be imposed on the inserted low-power cells, or disabled (using -lps_iso_off and -lps_rtn_off), in which case no virtual logic will be created for sites that have no cells inserted but that are identified as sites for low-power in the CPF file. If you must simulate a mixed RTL/gate design, the CPF commands associated with the inserted low-power logic cells must be either commented out or removed from the CPF file before simulating.

Feedthrough Wires

Feedthrough wires are wires that pass through a power domain without affecting, or being affected by, logic inside the power domain. An input that does not have other readers (loads) inside the power domain is connected to an output that does not have any other writers (drivers) inside the domain. These wires are not corrupted when the domain is powered down.

The wire cannot pass through any logic inside the power domain. If a wire splits inside a power domain (that is, if the same primary input is assigned to multiple outputs), a continuous assignment in which a primary input is directly linked to a primary output without passing through any logic is treated as a feedthrough wire. Wires with loads inside the power domain are corrupted.

In the illustrations shown in this section:

= simple assignment

= driver or load



Consider the following assignment statements:

Verilog VHDL

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

assign Q2 = D2; Q2 <= D2; /* A continuous assignment connects a powerdomain primary input to a primary output.This continuous assignment is treated asa feedthrough wire, and D2 is notcorrupted outside of dut1 when the powerdomain is powered down. */

assign Q3 = !D3; Q3 <= NOT D3; /* D3 splits inside the power domain.Because of the load that drives toQ3, D3 is corrupted inside dut1 whenthe domain is shut down. */

assign Q4 = D3; Q4 <= D3; /* Because there are no loads driving to Q4,this continuous assignment is treated asa feedthrough wire. The outside logicdirectly connected to the wire is drivendirectly by the driver of the wire at thepower domain’s primary input. */

top

dut1

•D 1 •

•D 3 •

•

Q1D1

Q2

D3

Q3

Q4

• •

••

••

• •

dout1

dout2

dout3

dout4

Q1

Q3

•D2



The following types of assignment statements are identified as feedthrough wires if they meet the restrictions noted above.

■ Simple assignment of input to output

Verilog VHDL

assign outp = inp; outp <= inp;

■ Bit-selects

Verilog VHDL

assign outp[1] = inp; outp(1) <= inp;

assign outp = inp[1]; outp <= inp(1);

assign outp[1] = inp[2]; outp(1) <= inp(2);

■ Part-selects

Verilog VHDL

assign outp[1:2] = inp; outp(1 to 2) <= inp;

assign outp = inp[5:4]; outp <= inp(5 downto 4);

assign outp[1:2] = inp[5:4]; outp(1 to 2) <= inp(5 downto 4);

■ Assignments with a delay

Verilog VHDL

assign out = #1 in; out <= in after 1ps;

Delayed assignments can be combined with non-delayed assignments.

■ Concatenation of signals

Note: VHDL does not allow concatenations on the left-hand side of an assignment.

Verilog VHDL

assign outp = {inp, inp, inp, inp}; outp <= inp & inp & inp & inp;

assign outp = {inp1, inp2, inp3, inp4 outp <= inp1 & inp2 & inp3 & inp4;

assign out = {in[0], in[1]}; out <= in(0) & in(1);

assign out = {in1[0], in1[2], in1[3:0]; out <= in1(0) & in1(2) & in1(3 downto 0);

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

assign {out1, out2} = in1;

assign {out1, out2} = {in1, in2};

Note: The following assignment using the Verilog replication operator is not supported in the current release:

assign outp = { 4{inp} };



■ Busses with sources in multiple domains

When assigning to a bus, the inputs can come from different domains. Each bit of the bus is analyzed separately to determine if the wire is a feedthrough. In the following example, the path from sig3 to sig4[3] is not a feedthrough.

Verilog VHDL

assign sig1_tmp = sig1; sig1_tmp <= sig1;


assign sig3_tmp = !sig3; sig3_tmp <= NOT sig3;

assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp}; 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.

sig1

sig2

sig3

sig4[3:1]



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

Verilog VHDL

assign sig6 = !sig1; sig6 <= NOT sig1;

assign sig5 = sig1; sig5 <= sig1;


assign sig2_tmp = !sig2; sig2_tmp <= NOT sig2;


assign sig_concat = {sig3_tmp, sig2_tmp, sig1_tmp}; 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.

sig1

sig2

sig3

sig4[3:1]

sig5

sig6



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

INPUTS

OUTPUTS

PD1

PD2

PD3

= Feedthrough assignment

= Hierarchical connection



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.

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 domain’s 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 // Interface instance

inst1(intf_inst) // Module instance (in power domain PD1)

inst2(intf_inst) // Module instance (in power domain PD2)

u_pmc

The Verilog code is as follows:

D3

Q3

Q4



interface myintf;

wire a, b, c, d;

modport master (input a, b, output c, d);

modport slave (output a, b, input c, d);

endinterface

module m (myintf.master i);

...

endmodule

module s (myintf.slave i);

...

endmodule

module dut;

myintf intf_inst();

m inst1(.i(intf_inst));

s inst2(.i(intf_inst));

endmodule

In this example, inst1 and inst2 are module instances connected through interface instance intf_inst. The instances inst1 and inst2 have been defined as power domains in the CPF file, as follows:

set_design dut

create_power_domain -name topdmn -default


-instances inst1 \

-shutoff_condition {u_pmc.pso_en[0]}


-instances inst2 \


end_design

Interfaces within a Power Shut Off Domain

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



tbench

dut // Power domain PD1

intf_inst // Interface instance

inst1(intf_inst) // Module instance

inst2(intf_inst) // Module instance

u_pmc

In this example, inst1 and inst2 are module instances connected through interface instance intf_inst. The power domain defined in the CPF surrounds the dut instance.

set_design dut

create_power_domain -name topdmn -default

create_power_domain -name maindmn \

-instances dut \


end_design

Referring to Design Objects in an Interface

Commands in the CPF file can refer to the interface and modport ports. Because an interface instance introduces a scope, the hierarchical path to an object in an interface must include the interface instance name. For example:

intf_inst.req // Signal req in the interface instance

VHDL Coding Style Recommendations

This section presents some coding styles that have a significant effect on the accuracy of low-power simulations when subjected to unknown (X or U) situations. The following restrictions apply only to the DUT, not to the testbench or behavioral models.

Data Constructs

The use of any data type other than std_logic or std_ulogic is not supported. This is necessary because only these data types can assume the value of U (undefined).

All internal signals and FFs in a chip (DUT) must initially start at U, and then come out of this undefined state in a predictable manner as the reset signal is applied. If integers, enumerated data types, or user data types are used in the DUT, these data types will assume their default states (0, left-hand element, and so on) when going through power shutdown instead of being



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.



library ieee;

use ieee.std_logic_1164.all;

entity SUB_A is

generic (G1 : integer := 3);

port (out1 : out std_logic;

out2, out6 : out integer;

out3, out4 : out std_logic_vector(3 downto 0);

out5 : out std_logic_vector(4 downto 0));

end entity SUB_A;

architecture RTL of SUB_A is

begin

out1 <= '1'; -- Scalar constant

out2 <= 2; -- Integer

out3 <= "1100"; -- Vector

out4 <= (others => '1'); -- Aggregate onstant definition

out5(4 downto 2) <= "010"; -- Part-select / Bit-select

out6 <= G1; -- Assignment from generics

end architecture RTL;

The above constants are recognized by the VHDL simulator, and will be powered down and restored correctly. However, in both Verilog and VHDL, there are many ways of writing RTL code that synthesizes down to a constant. Currently, the simulator does not recognize any form of a constant expression except for the simple cases shown above.

Type Conversions

Type conversions are commonly found in VHDL code. The following type conversions are not supported for low-power simulations:

std_logic <=> integer

std_logic <=> real

real <=> std_logic



real <=> integer

time <=> integer

real <=> time

signed_int <=> integer

unsigned_int <=> integer

std_ulogic <=> integer

std_ulogic <=> real

std_logic <=> natural

std_logic <=> positive

std_ulogic <=> natural

std_ulogic <=> positive

converting to type integer using std_logic_arith::conv_integer (…)

Processes that Use Variables of Type Integer

In the example below, Q is an integer that changes on the rising edge of Clk. If the circuit powers down while Q is changing, Q will not be corrupted because it is an integer. This could cause differences between simulation and silicon. If Q was of type std_logic, this example would work correctly after power up.

entity count16 is

port (Clk, Rst, Load : in std_ulogic;

Data : in std_ulogic_vector(3 downto 0);

Count : out std_ulogic_vector(3 downto 0));

end entity count16;

architecture count16a of count16 is

begin

process(Rst,Clk)

variable Q: integer range 0 to 15;

begin

if Rst = '1' then -- Asynchronous reset

Q := 0;



elsif rising_edge(Clk) then

if Load = '1' then

Q := to_uint(Data); -- Convert vector to integer

elsif Q = 15 then

Q := 0;

else

Q := Q + 1;

end if;

end if;

Count <= to_vector(4,Q); -- Convert integer to vector

-- for use outside the process

end process;

end architecture count16a;





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


Low-Power SimulationUsing CPF for Designs Using Power Shutoff

Figure 3-1 Example of Design with PSO

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.

inst_A inst_B

inst_Dinst_C

PD2

PD3

PD1

pm_inst

top

pse_enable

ice_enable

pge_enable



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.

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

Power DomainControl Signals

power switch isolation state retention

PD1 no control signal no control signal no control signal

PD2 ps_enable[0] ice_enable[0] pge_enable[0]

PD3 ps_enable[1] ice_enable[1] pge_enable[1]



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



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

In CPF, a power domain can be defined as a base domain of another power domain (referred to as the derived domain). A base domain is defined as follows:

A power domain X is a base power domain of power domain Y if the primary power and ground nets of power domain X provide the power supply to domain Y through some power switch network.

Defining a base domain lets you:

■ Model the secondary pin of a physical cell.



■ Shut off the derived domain when the base domain is powered down.

■ Share the power switches of the base domain.

■ Simplify the power domain shutoff conditions specified in the CPF file.

In CPF, you define the power domains with create_power_domain commands. Use the -base_domains option to specify a list of the base domains that supply external power to the derived power domain. The derived domain is powered down if either its shutdown condition is true or if all of its base power domains are switched off.

In Figure 3-2 on page 60, power domain PD is defined as the base power domain of domain PD1. When the shutoff condition for domain PD is true, the domain is powered down, and so is domain PD1, including the standard cells, SR, AO, and the isolation cells.

Figure 3-2 Derived Power Domain with a Base Power Domain - Example 1

Secondary Power Domains of Special Low-Power Instances

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

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



nets of the secondary domain provide the power supply to the secondary power and (or) ground pins of the instance.

The secondary power domain for special low-power logic is defined using the -secondary_domain option of the corresponding create_xx_rule command. For example, to specify that a register instance reg1 in power domain PD1 is a register that must be replaced with a state retention cell, use the create_state_retention_rule command. To specify that power domain PD provides the continuous power when the cell is in retention mode, use the -secondary_domain option.

create_state_retention_rule -name PD1_sr \

-instances {reg1} \

-restore_edge {...} \

-secondary_domain {PD}

In Figure 3-3 on page 62:

■ Power domain PD_ON is an always-on domain (no shutoff condition is specified).

■ Power domain PD is defined as the base power domain of domain PD1. When the shutoff condition for domain PD is true, the domain is powered down, and so is domain PD1. The standard cells in domain PD1 are shut off. The always-on buffer (AO) and the isolation cells are connected to an external power supply and are not shut off.

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



Figure 3-3 Derived Power Domain with a Base Power Domain - Example 2

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.

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



Figure 3-4 Derived Power Domain with Multiple Base Power Domains

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:

PD1

PD3

B

VDD1 VDD2

SR

SWA

C

SW SW

SW

PD2SW

VDDSW

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



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



Example 1: Signal Driven from PD1 to PD2, with a Load Inside PD2

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.

PD1

pd1_inst

A

PD4PD2

pd2_inst

B

PD3



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.

The RTL code for the RAM IP block is as follows:

module sram (we, ce, data_in, addr, &);

input we, ce;

input [15:0] data_in;

input [7:0] addr;

// ram memory array

reg [15:0] ram_core [0:2047]

// memory block

always @(posedge clk or negedge reset)

begin: core_logic

if (we_int && ce_int)

ram_core[addr_int] = data_in_int;

PD_TB

testbench

A

PD4PD_ON

RAM(IP block)

B

PD_SW

PD_CORE

addrdata_in

wece

B



else if (!we_int && ce_int)

dout_int = ram_core[addr_int];

end

// input signal buffers

always @(addr)

begin: input_sig_logic

addr_int = addr;

data_in_int = data_in

we_int = we;

ce_int = ce;

end

The CPF commands are in two CPF files: the top-level file (top.cpf) and the lower-level file (sram.cpf).

# Top-level CPF file: top.cpf


set_hierarchy_separator "/"

# The -testbench option in the following set_design command is necessary because# a default power domain is not defined for the testbench scope.

set_design testbench -testbench

# You must follow the set_design with set_instance to link in the sram.

# Create two virtual domains so that they can be mapped to the lower# level domains in the macro model

create_power_domain -name PD_core_tb \

-shutoff_condition {pse_core}

create_power_domain -name PD_sw_tb \

-shutoff_condition {pse_sw}

# The next command will map the testbench domains to the lower-level domains# in the macro model

set_instance xSRAM -domain_mapping { {PD_SW PD_sw_tb} \

{PD_CORE PD_core_tb} }

# set_instance -model is not supported, so you must source the lower-level CPF file

source ../cpf/sram.cpf

end_design



# Lower-level CPF file: sram.cpf

# Define macro model for ram

# NOTE: All CPF commands in this file are ignored by implementation tools.# They are necessary for simulation only.

set_macro_model ram

# Create the default power domain for the RAM

create_power_domain -name PD_ON -default

# Define two domains: one for the memory core and one for the peripheral pins

create_power_domain -name PD_SW \

-boundary_ports {we ce addr data_in}

create_power_domain -name PD_CORE \

-instances ram_core

# Add isolation rules, state retention rules, etc. here

end_macro_model

In this example, the PD_SW domain must be mapped to the upper-level PD_sw_tb domain, and the PD_CORE domain must be mapped to the upper-level PD_core_tb domain. The set_instance -domain_mapping command links these domains together. Whenever the top-level domain shuts off, the corresponding lower-level domain reflects this shutoff state.

Whenever pse_sw is active, the pins ce, we, addr, and data_in get corrupted. This causes the always block, input_sig_logic, to see Xs at all of its inputs, and therefore emulate shutdown behavior.

Likewise, whenever pse_core is active, the memory array (ram_core) will be corrupted. This emulates a RAM that has lost its contents.

The rest of the RTL code in the RAM model is always on, and will respond normally to any inputs.

By defining various pins to be in different power domains (through the -boundary_ports options), it is possible to separate different regions of a single model into many independent parts. This is analogous to placing each of these regions in separate instances, and then assigning these instances to their own power domains. However, it is not necessary to rewrite the vendor IP code to accomplish this.



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.



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} # Create a virtual port

create_power_domain -name {PD_default} \

-default

-shutoff_condition {top_pwr}

...

...

At the top level, the CPF can use port mapping to map a virtual port to a design signal that has a value of 1 or 0. For example:



# top.cpf

...

...

set_design TOP

create_power_domain -default \

-shutoff_condition {VD_pwr_on}

set_instance IP_inst -port_mapping {top_pwr VD_pwr_on}

source IP.cpf

end_design

However, this design signal (VD_pwr_on) may not be available in the testbench. In this case, you could:

■ Modify the testbench to declare a dummy signal, and then map the virtual port to the dummy signal.

set_design TOP -testbench

set_instance IP_inst -port_mapping {top_pwr VD_power_on}

source IP.cpf

end_design

■ Specify a literal in the -port_mapping option and map the virtual port to the literal. This avoids having to modify the testbench to implement a dummy signal. For example:

#top.cpf

...

...

set_design TOP -testbench

set_instance ip_inst -port_mapping {top_pwr 1}

source IP.cpf

end_design

The mapping of literals is only allowed in a set_instance -port_mapping command. Literals cannot be specified directly as the shutoff condition in a create_power_domain command. The literals map only to the shutoff condition in a create_power_domain command. They do not map to any other control condition, such as isolation or state retention control conditions.

Only the following literals are allowed:



■ 1 or 1’b1. 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 1’b0. 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 1.1


set_time_unit "ns"

set_design IP -ports {pso1 pso2} # Create two virtual ports

create_power_domain -name {PD_default} \

-default

create_power_domain -name {PD_1} \

-instances {inst_level_2_1} \

-shutoff_condition {pso1} \

-base_domains {PD_default}



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 1.1


set_time_unit "ns"

set_design top -testbench

set_instance ip_inst -port_mapping {{pso1 pso1} {pso2 0}}

source IP.cpf

end_design

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.



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


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

TB

MB

A

DUT

PDD

C

D

PD1 PD2

N



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



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.



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;



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.



■ VHPI design and value access

The implicit enumeration literal is hidden when accessed through VHPI design access mechanisms. However, all value access routines return the implicit value.

■ Case statements

All case statements that have case expressions with the subtype as an enumerated type have an implicit choice inserted for the implicitly-added enumeration literal.

case <expression> is

when <implicit_enum> => -- Implicitly-added choice with no statements

when STATE_0 => ...

when STATE_1 => ...

...

other choices

...

end case;

This ensures that case statements are complete as per VHDL semantics. No statements are added for this choice to ensure that any state machines modeled with the case statement remain in the shutoff/corrupted state until state elements are restored or the state machines are reset.

■ Predefined Attributes

There are several predefined attributes that apply to an enumerated type. A subset of these attributes can be affected due to the implicitly-added literal. For these attributes, the simulator ignores the existence of the implicit literal under certain situations to preserve the power on behavior of the design. The behavior of the attributes is shown in the following table.

Attribute Behavior with Implicit Literal

T’RIGHT Simulator ignores the implicitly-added literal, and returns the literal that lies just to the left of the right-most (implicit) literal.

T’HIGH Simulator ignores the implicitly-added literal, and returns the literal that is one less than the highest (implicit) position number.

T’IMAGE(X) This attribute returns a string representation of the value of parameter X, which is an expression of the enumerated type.

If parameter X evaluates to the unknown implicit literal, the simulator returns a string representation of the value so that you can detect expressions that are in the unknown state due to power shut off.



T’VALUE(X) This attribute takes a string parameter X and returns the literal value that matches the string representation.

If parameter X evaluates to the string representation of the implicit literal, the simulator returns the value of the literal.

T’POS(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.

T’VAL(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 T’HIGH. 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.

T’SUCC(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.

T’PRED(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.

T’LEFTOF(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.




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.


-targets {q1 q2 q3}

See Disabling Corruption of Verilog reg Variables for details.

T’RIGHTOF(X) This attribute takes a parameter expression whose type is the base type of the enumerated type and returns the value that is to the right of the parameter in the range of the enumerated type.

The simulator generates an error if X equals T'RIGHT or if X does not belong to the range T'LOW to T'HIGH. The implicit literal is not considered to be in this range. The simulator generates an error if X evaluates to the implicit literal.




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.


-instances {A/B/I1} \

...




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


-domain PD1 \

-exclude {test/u1/reg3 test/u1/reg4 test/u1/reg5} \

...


-domain PD1 \

-exclude {test/u1/reg1 test/u1/reg2} \

...

■ The first rule selects all registers in PD1, then excludes reg3, reg4, and reg5. That is, this rule selects reg1 and reg2.

■ The second rule selects all registers in PD1, then excludes reg1 and reg2. That is, this rule selects reg3, reg4, and reg5.

In this example, all five registers are selected for state retention. No register is excluded.

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



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:


-instances {A/B/*} \

...

Limit the use of wildcards to situations in which you know that the wildcard will match only the intended state elements. For example, if you have used a naming convention in which _reg is used to identify registers, you can use the following specification:


-instances {A/B/*_reg} \

...



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'



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.



In the following figure, the retention control signal is called pg.

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


-restore_edge {!pm_inst.pge_enable[1]}

Using -save_edge

The following rules specify that the current values are saved when the control expressions change from false to true. No restore edge is specified, so the saved values are restored when the power is turned back on.


-save_edge {pm_inst.pge_enable[0]}


-save_edge {pm_inst.pge_enable[1]}

Region 1 Region 2 Region 3

pg

Retention control becomes active and power is on Power off Power on

Retention control becomes inactive

Retention mode with power on

Retention mode with power off




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.

The CPF standard states that the current values are saved as long as the save expression is true, and that the saved values are restored as long as the restore expression is true. In the Incisive simulators:

■ The register saves the current value as soon as the save expression evaluates to true.

■ The register restores the saved value at the last moment when the restore expression evaluates to true.

The following rule specifies that the current values are saved as soon as sr_save evaluates to true. The saved values are restored at the end of the period where sr_restore evaluates to true.


-save_level {sr_save} \

-restore_level {sr_restore}


sr_save

Save is active Power off Power on

Restore is active


Retention mode with power off


Save is inactive

Region 3

sr_restore

Region 5

Restore is inactive



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}


sr_save

Save is active Power off Power on

Restore is active

Save is inactive

Region 3

sr_restore

Region 5

Restore is inactive

Save current values Restore values



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:


pg

Save condition and save precondition are both true Power off Power on


rstSave


pg

Precondition is always false Power off Power on


rst

Save

Save condition is true



■ Corrupt the saved value in the shadow register for the remainder of Region 1. The value of the master register will be X when values are restored.

You must use the simulator -lps_alt_srr option to enable this behavior (ncsim -lps_alt_srr or irun -lps_alt_srr).


pg

Precondition is false Power off Power on


rst

Save



pg

Save condition and save precondition are both true

Power off Power onRetention control becomes inactive

rst

Save Re-evaluate values

Save again

Precondition becomes false



For example:

Single Retention Control with a Restore Precondition

If a restore precondition is specified, the saved values are restored when the restore condition evaluates to true and if the restore precondition also evaluates to true. The precondition must remain true for the entire period after power on. For example:


-restore_edge {!pg} \

-restore_precondition {rst}


pg


Power off Power onRetention control becomes inactive

rst

Save

Corrupt values in shadow register

Precondition becomes false



If the restore precondition is always false or is false before the restore condition evaluates to true (that is, if the restore precondition is false at any time between power up and restore), two modeling choices are available:

■ Do not restore the value in the shadow register. This is the default behavior. For example:

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


pg

Save condition is true Power off Power on

Restore condition is true

rst

Save Restore

Restore precondition is true


pg



rst

Save No restore

Restore precondition becomes false




For example:

Separate Save and Restore Controls with a Save Precondition

If a save precondition is specified, the current values are saved when the save condition evaluates to true and if the save precondition expression also evaluates to true. The precondition must remain true for the entire period during which the save condition is true. For example:



-restore_level {sr_restore} \

-save_precondition {rst}


pg



rst

SaveCorrupt values in shadow register


Restore



If the save precondition is always false or is false at any time before the save signal becomes inactive (that is, if the precondition is false at any time during Region 1), two modeling choices are available:

■ Save the current values when the save signal becomes inactive. This is the default behavior. For example:


sr_save

Power off Power on Restore is active

Region 3 Region 5

Restore is inactive

Restore valuesrst

Save


sr_restore


sr_save


Region 3 Region 5

Restore is inactive

Restore valuesrst

Save


sr_restore

Precondition is always false



■ Corrupt the saved value in the shadow register for the remainder of Region 1. The value of the master register will be X when values are restored.


For example:


sr_save


Region 3 Region 5

Restore is inactive

Restore values

rst

SaveSave again


sr_restore

Re-evaluate values

Save precondition becomes false



Separate Save and Restore Controls with a Restore Precondition

If a restore precondition is specified, the saved values are restored when the restore condition expression evaluates to false and the restore precondition expression is evaluated to be true for the entire period during which the restore condition is true. For example:



-restore_level {sr_restore} \

-restore_precondition {rst}


sr_save


Region 3 Region 5

Restore is inactive

Restore values

rst

Save


sr_restore


Save precondition becomes false



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.


sr_save

Power off Power on


Region 3 Region 5

Restore condition is false

Restore values

rst

Save


sr_restore

Restore precondition is true


sr_save

Power off Power on


Region 3 Region 5


No restore

rst

Save


sr_restore




■ Corrupt the saved value in the shadow register for the remainder of Region 5. Restore when the restore condition becomes false. The value of the master register will be X when values are restored.


For example:

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.


sr_save

Power off Power on


Region 3 Region 5


rst

Save


sr_restore



Restore



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



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.



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



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



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.



top PDAI1 I2

I3

PDB

A

B

C

I

D

E

F

G

H

I4

PDC

J



Table 3-1 Effect of -from, -to, and -from -to Options

Isolation Rule Net Segments Selected


-from PDA \

...

Isolate net segments driven by logic in thespecified from domain and with a load in anotherdomain.

If possible, isolation is placed at the output of thefrom domain.

This rule isolates net segments:

■ CG and CJ. Isolation is placed at pin C.

■ BF. Isolation is placed at pin F. Isolationcannot be placed at pin B because this wouldisolate net segment BE.

Net segments AD and BE are not isolatedbecause the leaf-level driver and loads are in thesame power domain.

This rule is ignored for the net connected to pin Ibecause it is a floating net.


-to PDB \

...

Isolate net segments driving logic in the specifiedto domain and that are driven by logic fromanother power domain.

If possible, isolation is placed at the input of theto domain.


■ BF. Isolation is placed at pin F.

■ CG. Isolation is placed at pin G.

Ignore this rule for the net connected to pin Hbecause it is driven by a tie-low signal that is notin a switchable domain.



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


-from PDA -to PDC \

...

Isolate net segments that drive logic in thespecified to domain and that are driven by logicin the specified from domain.

If possible, isolation is placed at the input of theto domain.

This rule isolates net segment CJ. Isolation isplaced at pin J.

Table 3-1 Effect of -from, -to, and -from -to Options




Table 3-2 Effect of -pins, -exclude, and -force Options


create_isolation_rule -name ISO1 \

-from PD1 \

-pins {A} \

...

Isolate net segments that drive or connect to pinA, 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 segmentAB. Isolation is placed at pin C.


-from PD1 \

-pins {B} \

...

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

PD1

D

A

F

E

B

C

G

PD2

PD1

H




-from PD1 \

-pins {F} \

...

Isolate net segments that drive or connect to pinF, and that also meet the requirements of the-from option.

No isolation is inserted. The net segment drivingpin F has a driver in the from domain, but noload in another domain. Isolation is ignored for afloating net.


-to PD2 \

-pins {C,E} \

...

Isolate net segments that are driven by orconnected to pins C and E, and that also meetthe requirements of the -to option.

This rule isolates net segments AC and DE.

Isolation is placed at pins C and E.


-to PD2 \

-pins {B} \

...

Isolate net segments that are driven by orconnected to pin B, and that also meet therequirements of the -to option.

No isolation is inserted. This rule does not meetthe requirements of the -to option. The netsegment driven by pin B does not have a load inthe specified to domain.


-to PD2 \

-pins {G} \

...

Isolate net segments that are driven by orconnected to pin G, and that also meet therequirements of the -to option.

This rule isolates net segment DG.

Isolation is placed at pin G.


-to PD2 \

-pins {H} \

...

Isolate net segments that are driven by orconnected to pin H, and that also meet therequirements of the -to option.

This rule isolates net segment DH.

Isolation is placed at pin H.






-from PD1 \

-exclude {B} \

...

Isolate all net segments that meet therequirements of the -from option, except for thenet segment that is connected to, driven by, ordriving pin B.


■ AC. Isolation cannot be placed at pin Abecause this would also isolate segment AB,so isolation is placed at pin C.

■ DE and DG. Isolation is placed at pin D.


-from PD1 \

-exclude {G} \

...

Isolate all net segments that meet therequirements of the -from option, except for thenet segment that is connected to, driven by, ordriving pin G.


■ AC. Isolation cannot be placed at pin Abecause this would also isolate segment AB,so isolation is placed at pin C.

■ DE. Isolation cannot be placed at pin Dbecause this would also isolate segmentDG, so isolation is placed at pin E.


-from PD1 \

-pins {D} \

-exclude {G} \

...

Isolate net segments that drive or connect to pinD, and that also meet the requirements of the-from option. Exclude net segments connectedto, 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.





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


-to PD2 \

-pins {G} \

-exclude {H} \

...

Isolate net segments that are driven by orconnected to pin G and that also meet therequirements of the -to option. Exclude netsegments connected to, driven by, or driving pinH.

This rule does not isolate any net segments.Isolation cannot be placed at pin G because thiswould isolate H, which has been excluded.


-from PD1 \

-pins {F, B} -force \

...

Force isolation at pins F and B.

Isolation is placed at the specified pins. Nodriver/load analysis is performed.


-from PD1 \

-pins {D} -force \

-exclude {E} \

...

This rule is ignored with an ISOFRC warning.

Cannot use -exclude with -force.


-from PD1 -to PD2 \

-pins {D} -force \

...

This rule is ignored with an ISOFRC warning.

Cannot use both -from and -to with -force.





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.



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 create_isolation_rule -from and -to options filter out pins for isolation based on drivers and loads:

■ -to requires that there are loads inside the specified to domain and that the net segment is driven by a signal from another power domain.

■ -from requires that there are drivers inside the specified from domain and at least one leaf load in another power domain.

The semantics of these options also applies to the top-level ports and their associated domains. If you write a rule to isolate the inputs of a DUT (-to), input isolation will be inserted only if there is a load in the DUT. A driver in the associated domain of the input port is assumed, and this driver must not be in the same domain as the specified to domain. For example, if the load in the DUT is in the default domain and the boundary ports are implicit boundary ports, no isolation is placed because they have a driver and load in the same domain.

If you write a rule to isolate the outputs of a DUT (-from), the ports will be isolated only if there is a driver in the DUT. A load in the associated domain of the output port is assumed, and this load must not be in the same domain as the specified from domain.

In the following example, the DUT is instantiated in a testbench.



Domain PDD is the default power domain. This domain is always-on. Ports A, B, C, and M are defined as boundary ports of a switchable domain called PD3.



-boundary_ports {A B C M} \

-shutoff_condition {pso}

Input ports A, B, and C are assumed to have a driver in their associated domain, PD3. Output port M is assumed to have a load in domain PD3.

Ports D and N, which have not been defined as explicit boundary ports, become implicit boundary ports associated with the default domain PDD. Input port D is assumed to have a driver in domain PDD, and output port N is assumed to have a load in domain PDD.

Given the following create_isolation_rule command, input isolation will be inserted on ports A, B, and C because the driver and load requirements are met. A driver is assumed in the associated domain of these ports (PD3), and there is a load in PD1.

Isolation will also be placed on port D because there is (an assumed) driver in the default domain PDD and a load in PD1.

TB

MB

A

DUT

PDD

C

D

PD1 PD2

N



set_design TB -testbench

create_isolation_rule -name ... \

-to PD1 \

-isolation_condition ... \


Given the following create_isolation_rule command, output isolation will be inserted on port M because the driver and load requirements are met. There is a driver in domain PD2, and a load is assumed in the associated domain, PD3. Isolation will also be placed on port N because there is a driver in domain PD2, and a load is assumed in the associated domain for this port, PDD.


-from PD2 \



The default isolation behavior also applies to cases where the DUT is instantiated in a wrapper if the ports are wired to the testbench through the wrapper.

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

TB

C

B

A

PD_dut

DUT



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.

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

set_design -testbench TB


-to PD_ip2 \ # Must be a load in PD_ip2 and adriver in another domain.



DUTTB

TB

BA

PD_ip1

IP1

DC

PD_ip2

IP2



Controlling Isolation Enable and Disable

Based on the design intent, isolation enable and disable can be controlled by:

■ An explicit isolation control signal

Use the -isolation_condition expression option to specify the isolation condition. Nets are isolated when the condition expression evaluates to true. For example:


-from PDA \

-isolation_condition {iso_en} \

...

■ The power shutoff or power up of the driving power domains (the power domains containing the drivers of the selected net segments).

Use the -no_condition option to specify that there is no explicit isolation condition. This option specifies that the isolation logic is automatically enabled when the power domains containing the drivers of the selected net segments are shut off. For example:


-from PDA \

-no_condition \

...

The simulator ensures that isolation is enabled before power shutdown to prevent the propagation of unknown states on an isolated net. Isolation is automatically disabled when the power domains are powered up.

■ A default isolation condition specified for the power domain that contains the leaf level driver of the selected net

IP blocks can have special requirements for input ports. For example, when the signals driving these input ports are switched off, the signals must be held at specific values. For these input ports, no isolation condition can be specified because the IP developer has no knowledge of how the IP will be used. For these cases, isolation rules must be created without enable conditions (neither the -isolation_condition nor the -no_condition option is specified).

If neither -isolation_condition nor -no_condition is specified, the rule is considered incomplete. To complete an incomplete isolation rule, the simulator checks the create_power_domain command for the originating (driving) power domain(s) of the selected net segments to see if a default isolation condition was specified with the -default_isolation_condition option. If a default isolation condition is defined, that condition is used as the isolation condition.



Note: For an incomplete isolation rule, the create_isolation_rule command can be specified only for net segments that connect to an input port of a module or a macro cell.

Specifying Isolation Values

Use the -isolation_output option to control the output value at the output of the isolation cells when isolation is enabled. The output can be:

■ low—Forces the output to the logic low value (0). This is the default.

■ high—Forces the output to the logic high value (1).

■ hold—Forces the output to the same logic value as the value of the signal being isolated.

Note: The tristate argument to the -isolation_output option is not supported in the current release.

The logic behavior of low and high isolation is as follows: When the isolation control expression is false (or, if you have used the -no_condition option, when the power domains containing the drivers of the selected net segments are powered up), no isolation occurs and the port signal value is propagated. When the isolation control expression is true (or, if you have used the -no_condition option, when the power domains containing the drivers of the selected net segments are shut off), isolation is enabled, and the signal value propagated from the port is either 0 (for low isolation) or 1 (for high isolation). If the control signal value should ever be X, the signal value propagated from the port is also X.

For hold isolation type, the value of the isolated output is latched when the isolation control is enabled.

Back-to-Back Isolation

In some cases, you may need to place two isolation devices, an off-to-on device and an on-to-off device, on the same net segment. A common scenario is when a switchable domain drives a standby domain. If the domain of the driver is off, the domain of the load(s) must be isolated to prevent the propagation of unknown values. If the domain of the load(s) is in standby, the domain must be isolated to prevent the inputs from changing. If the domain of the load(s) is off, inputs must be isolated to prevent electrical issues (this scenario is not relevant to simulation because, in the current release, the inputs to a domain that is off have an unknown value during simulation).



This back-to-back isolation placement can be achieved by specifying the create_isolation_rule -isolation_target {from | to} option. Two create_isolation_rules are written, both of which specify the same net.

■ One of the rules includes -isolation_target from to indicate that isolation should be on when the domain of the driver is off.

■ The other rule uses -isolation_target to to indicate that isolation should be on when the domain of the load(s) is off.

Example 1

In this example, the net segment has two power domain boundaries.

The CPF file includes the following rules:

create_power_domain -name PD1 -instances d1 -shutoff_condition p1.pso1

create_power_domain -name PD2 -instances d2 -shutoff_condition p1.pso2

create_isolation_rule -name ISOfrom \

-from PD1 -to PD2 \

-isolation_target from \

-isolation_condition p1.iso1 \

-isolation_output high

create_isolation_rule -name ISOto \

-from PD1 -to PD2 \

-isolation_target to \

-isolation_condition p1.iso2 \

-isolation_output low

PDD (default domain, AON)

PDO (AON)

PD1 (SW, Stby) PD2 (SW, Stby)

out1 in1



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.

Example 2

In this example, the net segment only has one power domain boundary.


PDO (AON)

PD1 (SW, Stby) PD2 (SW, Stby)

ISOfrom

iso1

ISOto

iso2


PDO (AON)

PD1 (SW, Stby)

out1in1

PD2 (SW, Stby)



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:


-from PD1 -to PD2 \


-isolation_output high \

-isolation_condition p1.iso1


-from PD1 -to PD2 \


-isolation_output low \



-from PD2 -to PD1 \


-isolation_output high \



-from PD2 -to PD1 \


-isolation_output low \


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.



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.


PDO (AON)

PD1 (SW, Stby)

out1in1PD2 (SW, Stby)

ISO1/ISO2 ISO4/ISO3



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:



■ -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: test.cpf:18

Iso control condition: (test.t1.p1.out1)

Iso output: low

test.t1.d1.out1[2]

test.t1.d1.out1[1]

Iso rule at source: test.cpf:13

Iso control condition: (test.t1.p1.out1)

Iso output: high

test.t1.d2.in1[3]

By default, the isolation information is written to the default log file (ncelab.log or irun.log). Use the -lps_logfile option to create a log file that contains only the isolation information. For example:

-lps_iso_verbose (Writes isolation information to thedefault log file)

-lps_iso_verbose -lps_logfile iso.log (Writes isolation informationto 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 informationto the default log file)



-lps_isofilter_verbose -lps_logfile iso.log (Writes isolation filteringinformation 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.



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


Low-Power SimulationUsing 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 \


# Create power modes

create_power_mode -name M1 \

-domain_conditions {PD1@high PD2@low}


-domain_conditions {PD1@low PD2@high}

After defining the power modes, you define the power mode transitions. A mode transition describes a transition from one power mode to a different power mode. Mode transitions are defined with the create_mode_transition command. For example:

create_mode_transition -name mt1 \

-from M1 -to M2 \

-start_condition {pmc.mte[1]}

See “Controlling Power Domain Transitions with Power Mode and Mode Transition Controls” on page 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 \




create_nominal_condition -name low \


# Specify active state conditions

create_power_domain -name PD \

-instances ... \

-shutoff_condition ... \

-active_state_conditions {[email protected]_high [email protected]_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.



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.



Figure 4-1 Power Mode Example

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.

top

pdAinstA

pdB

instB

pdT

pseA pseB



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 \


create_nominal_condition -name NC_12 \


create_nominal_condition -name NC_OFF \

-voltage 0.0 -state off

create_nominal_condition -name NC_STANDBY \

-voltage 0.5 -state standby

Specifying the Power Modes

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

Power modes let you identify which combinations of power domain states are valid, and which are not. Any combination of nominal conditions that is not defined in the CPF file is considered an illegal power mode.



Use the create_power_mode command to define the power modes.

Syntax:

create_power_mode

-name string [-default]

{-domain_conditions domain_condition_list

| -group_modes group_mode_list

| -domain_conditions domain_condition_list -group_modes group_mode_list}

Note: The -group_modes option is used to specify the mode of each power mode control group to be considered with the defined mode. See “Power Mode Control Groups” on page 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 andNominal Conditions

pdT pdA pdB

M1 NC_08 NC_08 NC_OFF

M2 NC_08 NC_OFF NC_08

M3 NC_12 NC_12 NC_12

M4 NC_08 NC_OFF NC_OFF



The power modes shown in the table are specified with the following create_power_mode commands:


-domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF}


-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_08}

# Power mode M3 is the default power mode. This corresponds to# the initial state of the design.


-default \



-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF}


-domain_conditions {pdT@NC_12 pdA@NC_12 pdB@NC_STANDBY}

Describing the Power Mode Transitions

A power mode transition describes a transition from one power mode to a different power mode. It defines the power mode from which to transition and the power mode to which to transition, the condition that triggers the transition, and the time needed to complete the transition.

Mode transitions let you control how the chip is allowed to change from one power mode to another power mode. Mode transitions that are not defined in the CPF file are considered illegal transitions.

Use the create_mode_transition command to describe the legal mode transitions.

M5 NC_12 NC_12 NC_STANDBY

Power Mode

Corresponding Power Domains andNominal Conditions

pdT pdA pdB



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:



Figure 4-3 Legal Power Mode Transitions

In a create_mode_transition command, the starting mode (-from) and the transition start condition (-start_condition) must uniquely determine the destination mode (-to). For example, in the diagram above, transitions from M3 to M1, M2, or M5 are valid. Therefore, mte[1], mte[4], and mte[6] must be unique signals. The other signals used as the start condition (mte[2], mte[3], and mte[5]) could be the same signal.

For the example, the power mode transitions shown in the diagram above are specified with the following create_mode_transition commands:


-from M3 -to M1 \



-from M1 -to M4 \



-from M4 -to M3 \



-from M3 -to M2 \


M1

M4 M3

M2

mte[1]

mte[4]mte[2]

mte[3]

mte[5]

M5mte[6]




-from M2 -to M4 \



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


-domain_conditions {pdT@NC_08 pdA@NC_08 pdB@NC_OFF}



■ At time 99 ns, domain pdT transitions to nominal condition NC_08 (no transition slope has been defined for pdT).

■ At time 99 ns, domain pdA starts transitioning from NC_12 (1.2 V) to NC_08 (.8 V). The transition slope for pdA is defined as .2V/ns.

■ At time 100 ns, the power shutoff signal for domain pdB (pseB) is asserted. A transition slope for pdB has not been defined, so pdB transitions to nominal condition NC_OFF at 100 ns.

■ At time 101 ns, power domain pdA has finished transitioning to nominal condition NC_08.

ncsim> run

0 clk=0 data=000000 ndata=111111

5 clk=1 data=000001 ndata=111110

...

95 clk=1 data=001010 ndata=110101

At simulation time 99 NS: Mode transition mt1 [M3->M1] has started.

At simulation time 99 NS: Power domain pdT has transitioned to nominal condition NC_08

At simulation time 99 NS: Power domain pdA has started transitioning to nominal condition NC_08

At simulation time 100 NS: Power domain pdB is being powered off

At simulation time 100 NS: Power domain pdB has transitioned to power off state

100 clk=0 data=001010 ndata=xxxxxx

At simulation time 101 NS: Power domain pdA has finished transitioning to nominal condition NC_08

At simulation time 101 NS: Mode transition mt1 [M3->M1] has completed.


...


■ At time 194 ns, mode transition mt2 (from mode M1 to mode M4) begins. Mode M4 is defined as follows:


-domain_conditions {pdT@NC_08 pdA@NC_OFF pdB@NC_OFF}



■ At time 194 ns, the power shutoff signal for domain pdA (pseA) is asserted, so data goes to X. Domain pdA starts transitioning from nominal condition NC_08 (.8 V) to nominal condition NC_OFF.

■ At time 198 ns, power domain pdA has finished transitioning to NC_OFF.


At simulation time 194 NS: Power domain pdA is being powered off

At simulation time 194 NS: Power domain pdA has started transitioning to power off state

194 clk=0 data=xxxxxx ndata=xxxxxx


At simulation time 198 NS: Power domain pdA has finished transitioning to power off state



...


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



At simulation time 298 NS: Power domain pdA is being powered up


At simulation time 298 NS: Power domain pdB is being powered up

At simulation time 298 NS: Power domain pdB has transitioned to nominal condition NC_12






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: Power mode transition (mt3) is illegal for the current mode (M2)


At simulation time 503 NS: Power domain pdA is being power up while no mode transition is in progress




At simulation time 509 NS: The system is now in a transitional or undefined mode, and has not reached a stable power mode yet


...

...


718 clk=1 data=011110 ndata=100001

...

815 clk=1 data=101000 ndata=010111

■ At time 816 ns, the system is in mode M3, and mode transition mt6 (from mode M3 to mode M5) starts. Domain pdB transitions to the standby state. While the domain is in standby mode, its inputs should be isolated and should not toggle. When an input does toggle during standby mode, the input is corrupted, and a standby mode input violation warning message is generated.

■ At time 825 ns, bit 0 of the input bus instB.x toggles and is corrupted. As more bits of the bus toggle, the bits go to X, and additional messages are generated.



Use the -lps_stdby_nowarn option to suppress the input violation messages.


At simulation time 816 NS: Power domain pdB has transitioned to nominal condition NC_STANDBY


At simulation time 825 NS: Standby mode input violation (top.instB.x[0])!

825 clk=1 data=101001 ndata=01011x

830 clk=0 data=101001 ndata=01011x


835 clk=1 data=101010 ndata=0101xx

840 clk=0 data=101010 ndata=0101xx

...

Simulation complete via $finish(1) at time 1 US + 0

./dut.v:23 #1000 $finish;

ncsim>

Controlling Power Domain Transitions with Domain-Level Controls

Note: The source files for the example used in this section are included in your installation at the following location:

install_dir/doc/PowerForwardUG/examples/power_modes_plus_active_state_cond

To create domain-level controls:

1. Define the operating voltages (nominal conditions) used in the design.

2. Specify the conditions for the power domains to transition to specific nominal conditions.

3. Specify the delay it takes for a power domain to reach its destination nominal condition.

Defining the Nominal Conditions

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



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 {[email protected] [email protected]}

create_power_domain -name pdA \

-instances instA \

-shutoff_condition pmc.pseA \

-base_domains {pdT}

-active_state_conditions {[email protected] [email protected]}

create_power_domain -name pdB \

-instances instB \

-shutoff_condition pmc.pseB \

-base_domains {pdT}

-active_state_conditions {[email protected] [email protected] [email protected]}

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.



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.


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


-lps_cpf dut.cpf -lps_pmcheck_only -lps_stime 1ns -lps_verbose 3 \

dut.v pmc.v &



Power Mode Control Groups

A power mode control group is a set of power domains with an associated set of power modes and mode transitions that apply to this group only. All power modes defined for this group can only reference power domains within this group. All power mode transitions can only reference power modes defined for this group.

Power mode control groups are used in a hierarchical flow where a piece of reusable IP has defined power modes in the CPF for that IP. When the IP block is instantiated, the CPF for the higher level can define its own power mode control group. The power modes defined in that control group can then specify:

■ The nominal condition of each power domain to be considered in the specified power mode (using the create_power_mode -domain_conditions option)

■ The mode of each power mode control group to be considered in the specified power mode (using the create_power_mode -group_modes option)

Each power domain must belong to one and only one power mode control group. Also, each power mode control group must have one and only one default power mode.

A power mode control group can contain other power mode control groups. If a power mode control group has another power mode control group as its member and the other power mode control group is not referenced in any power mode definition, the other power mode control group is assumed to be in the default power mode of that group.

If a power mode control group in a lower scope is not referred to by another power mode in an upper scope, the power mode at the block level is ignored at the top level.

Default Power Mode Control Group

A default power mode control group is automatically created for each CPF scope. To reference the default power mode control group of a scope, use the hierarchical path from the current scope to the targeted scope.

The default power mode control group for a scope contains all those power domains defined in this scope that are not declared as members of an explicitly defined power mode control group. In other words, if all power domains of a scope belong to an explicitly defined power mode control group, the default power mode control group has no members.



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



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.

The power modes and mode transitions for BLOCKA are shown in the following diagram.

The CPF file for this block defines the power domains, power modes, and power mode transitions for the block. The power modes and power mode transitions are defined with respect to the power domains at this level of hierarchy in the design.

PD_B

INST_A

BLOCKA

PD_C1

TOP

PD_C2

M1

M3

M2

M1b

M1a

M2a

M3a



While the CPF file for the IP block must specify all power modes and mode transitions that are required for the correct low-power behavior of the block, only a subset of these power modes may be relevant when the IP block is instantiated in the design. For example, when BLOCKA is used in the design, modes M1, M2, and M3 may be the only modes that are relevant.

# BLOCKA.cpfset_design BLOCKA

create_power_domain -name PD_C1 -instances ...create_power_domain -name PD_C2 -instances ...

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 -name M1 -default \-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 M3 \-domain_conditions {PD_C1@on}


create_mode_transition -name CT1 -from M1 -to M2create_mode_transition -name CT2 -from M1 -to M1acreate_mode_transition -name CT3 -from M1a -to M1bcreate_mode_transition -name CT4 -from M1b -to M2create_mode_transition -name CT5 -from M2 -to M3create_mode_transition -name CT6 -from M3 -to M1...[Other legal mode transitions]...end_design

No explicit power mode control group is created.

The default power mode control group containsboth power domains defined in this scope.

Mode M1 is the default power mode. Each power mode control group musthave one default power mode.

Power domain PD_C2 is not referenced, andis assumed to be in the off state.



Creating a power mode control group at the higher level lets you define a group that includes the power mode control group for the IP block. Then, when you define the power modes, you can specify that the power mode control group for the block must be in one of the relevant power modes.

Note: When BLOCKA in the example is instantiated, the hierarchical scope name of the block (INST_A) must be used to refer to the default power mode control group for BLOCKA.

The following file is the CPF file for design TOP. In this file, a power mode control group called top is created. This group includes power domain PD_B and the default power mode control group for BLOCKA.

When defining a power mode for design TOP:

■ Use the -domain_conditions option for any power domains at this level of hierarchy.

■ Use the -group_modes option to refer to the power mode of BLOCKA.

For example:

create_power_mode -name T3 -domain_conditions {PD_B@on} -group_modes {INST_A@M3}

If the power mode control group for BLOCKA is not referenced in a top-level power mode definition, it is assumed to be in the default mode of the power mode control group (mode M1 in this example).



Example 2: Using a User-Created Power Mode Control Group

In Example 1, the CPF file for BLOCKA did not contain set_power_mode_control_group and end_power_mode_control_group commands to define a power mode control group. A default group was created, which was referred to in the top-level CPF using the hierarchical scope name of the block (INST_A).

The BLOCKA.cpf file in Example 1 could have been written using an explicitly created power mode control group. IP blocks can also, of course, contain multiple power mode control groups with unique names.

The following example includes a user-created power mode control group in the CPF file for the IP block. This example illustrates:

■ How to refer to this power mode control group in the top-level CPF

# TOP.cpfset_hierarchy_separator /set_design TOPcreate_power_domain -name PD_B

set_instance INST_Ainclude BLOCKA.cpf

set_power_mode_control_group -name top \-domains PD_B -groups INST_A

create_power_mode -name T1 \-domain_conditions {PD_B@on}

create_power_mode -name T2 \-domain_conditions {PD_B@off} \-group_modes {INST_A@M2}

create_power_mode -name T3 -default \-domain_conditions {PD_B@on} \-group_modes {INST_A@M3}

create_mode_transition -name TT1 -from T1 -to T2create_mode_transition -name TT2 -from T2 -to T3create_mode_transition -name TT3 -from T3 -to T1

end_power_mode_control_groupend_design

Create power mode control group. This groupcontains power domain PD_B and the defaultpower mode control group for BLOCKA. Thehierarchical scope name of BLOCKA (INST_A)is used to refer to this control group.

Power mode T3 is the default mode.

Mode T1 does not reference the power mode control group (INST_A), so the power mode control group is assumed to be in its default mode (mode M1).

Mode T2 is created with domain PD_B at nominal condition off and power mode control group of BLOCKA (INST_A) in power mode M2, in which both block-level domains PD_C1 and PD_C2 are at nominal condition on.

End power mode control group definition.



■ 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.cpfset_design BLOCKA

create_power_domain -name PD_C1create_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 ...

set_power_mode_control_group -name BLOCKA_PMCG \-domains {PD_C1 PD_C2}

create_power_mode -name M1 -default \-domain_conditions {PD_C1@off PD_C2@on}


create_power_mode -name M1b \-domain_conditions {...}

create_power_mode -name M2 \-domain_conditions {PD_C1@on PD_C2@on}


create_power_mode -name M3 \-domain_conditions {PD_C1@on}


create_mode_transition -name CT1 -from M1 -to M2create_mode_transition -name CT2 -from M1 -to M1acreate_mode_transition -name CT3 -from M2 -to M3create_mode_transition -name CT4 -from M3 -to M1[Other legal mode transitions]

end_power_mode_control_group...end_design

Create power mode control group BLOCKA_PMCG. This group contains both power domains defined in this scope.

Default power mode for the power mode control group.

Power domain PD_C2 is not referenced, andis assumed to be in the off state.

End power mode control group BLOCKA_PMCG definition.



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.



# TOP.cpfset_hierarchy_separator /set_design TOPcreate_power_domain -name PD_B

set_instance BLOCKA_inst1include BLOCKA.cpf

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}

create_power_mode -name T2 \-domain_conditions {PD_B@off} \-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

set_instance BLOCKA_inst2include BLOCKA.cpf

set_power_mode_control_group -name topPMCG2 \-domains PD_B -groups BLOCKA_inst2/BLOCKA_PMCG

create_power_mode -name T3 \-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

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.

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 atnominal condition off and power mode controlgroup BLOCKA_PMCG in power mode M2.

End power mode control group topPMCG1 definition.

Create power mode control group topPMCG2. This group contains power domain PD_B and power mode control group BLOCKA_PMCG for BLOCKA. Use the hierarchical scope name to refer to this control group.

End power mode control group topPMCG2 definition.

Mode T3 is created with domain PD_B atnominal condition on and power mode controlgroup BLOCKA_PMCG in power mode M3.



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


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



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.

The following sections discuss only the commands that affect simulation.

Figure 5-1 on page 154 shows the design used in the examples.

create_power_domain

create_isolation_rule

create_state_retention_rule

create_nominal_condition For power modes.

create_power_mode For power modes.

create_mode_transition For power modes.

update_power_domain For implementation tools and for specifying transition slope for power mode transitions.

create_power_switch_rule For implementation tools only

set_floating_ports For implementation tools only

set_input_voltage_tolerance For implementation tools only

set_wire_feedthrough_ports For implementation tools only



Figure 5-1 Macro Model Example

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.

Internally Switched

State Retention

Switches

Isol

atio

n

Always On

Externally Switched

Isol

atio

n

D1

iso1

iso2

ret

pwr

VDD

D4

D5D3

D2

VSS VPP

Isolation

Pd_AON

Pd_PSO

Pd_EXT



■ 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];



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




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



reg [7:0] mem[0:15][0:7];

...

...

set_macro_model top

...

# Create a power domain for “mem”



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

■ if the port is a primary output of a macro cell, the boundary port domain is the domain of the driver(s) of the port inside the macro cell.

■ If the port is a primary input of a macro cell, the boundary port domain is the domain of the loads of the port inside the macro cell.



If an input pin is assigned to a switchable domain, when the shutoff condition of the domain becomes true, all logic within the macro model that is driven by this input pin will receive logic value X, irrespective of the logic value that drives the input pin.

If an output pin is assigned to a switchable domain, all of the logic that connects to the pin at the top level or testbench level will receive logic value X when the shutoff condition of the domain becomes true.

See “Declaring Boundary Ports with the -boundary_ports Option” on page 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


create_power_domain -name Pd_AON -default

create_power_domain -name Pd_PSO \

-shutoff_condition !pwr \

-boundary_ports {D2} \

-instances {mem*} \

-base_domains Pd_AON



create_power_domain -name Pd_EXT \

-boundary_ports {D3 D5}

...

end_macro_model

Defining Isolation

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



Figure 5-2 Isolation Rules

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:

Internally Switched

State Retention

Switches

Isol

atio

n

Always On

Externally Switched

Isol

atio

n

D1

iso1

iso2

ret

pwr

VDD

D4

D5D3

D2

VSS VPP

Isolation

# Port D4 belongs to#default domain Pd_AONcreate_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# isolationcreate_isolation_rule \-name IsoInReq \-to Pd_PSO -pins {D2} \-isolation_output low

# Port D3 belongs to# domain Pd_EXTcreate_isolation_rule \-name IsoIn \-to Pd_EXT -pins {D3} \-isolation_condition iso1 \-isolation_output low

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

Pd_AON

Pd_PSO

Pd_EXT



❑ 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



...

...

create_state_retention_rule -name PSO_RET \

-domain Pd_PSO \

-secondary_domain Pd_AON \

-save_edge {ret}



...

...

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




######################

# Create power domains

######################

create_power_domain -name Pd_AON -default



create_power_domain -name Pd_PSO \

-shutoff_condition !pwr \

-boundary_ports {D2} \

-instances {mem*} \

-base_domains Pd_AON

create_power_domain -name Pd_EXT \

-boundary_ports {D3 D5}

########################

# Define isolation rules

########################

# Port D4 belongs to default domain Pd_AON

create_isolation_rule -name IsoOut \

-from Pd_PSO -pins {D4} \

-isolation_condition !pwr \


# Port D2 belongs to domain Pd_PSO. D2 has no internal isolation

create_isolation_rule -name IsoInReq \

-to Pd_PSO -pins {D2} \


# Port D3 belongs to domain Pd_EXT

create_isolation_rule -name IsoIn \

-to Pd_EXT -pins {D3} \

-isolation_condition iso1 \


# Isolation rule for internal domain crossing

create_isolation_rule -name IsoInt \

-from Pd_EXT -to Pd_PSO \

-isolation_condition iso2 \


##############################

# Define state retention rules

##############################

create_state_retention_rule -name PSO_RET \

-domain Pd_PSO \

-secondary_domain Pd_AON \



-save_edge {ret}

end_macro_model

Integrating the Macro Model

When you instantiate a macro cell in the design, you must specify how the domains of the CPF macro model are mapped to the domains of the parent level. Macro model power domains are integrated with parent block power domains using the set_instance -domain_mapping option.

For the example design, the top-level design has two power domains: a default always-on domain called PDBlue, and an internally switchable domain called PDRed, as shown in Figure 5-3 on page 165.



Figure 5-3 Top-Level Power Domains

The two top-level domains are defined in the top-level CPF as follows:

# top.cpf

# Top-level CPF file



Internally Switched

State Retention

Switches

Isol

atio

n

Always On

Externally Switched

Isol

atio

n

D1

iso1

iso2

ret

pwr

VDD

D4

D5D3

D2

VSS VPP

Isolation

Always On

Internally Switched

State Retention

Switches

VDD

Pd_AON

Pd_PSO

Pd_EXT

PDBlue

PDRed



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.



...

...

end_macro_model



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


include macro.cpf

CPF File for the Top Level

The following file, top.cpf, shows the top-level CPF file with all simulation-related commands:



set_design top

######################

# Create power domains

######################

create_power_domain -name PDBlue -default

create_power_domain -name PDRed \

-shutoff_condition {pso} \

-default_isolation_condition {I1/iso1} \

-base_domains PDBlue

########################################################

# Define isolation rules

# If domain PDRed can be off, while domain Pd_PSO is on,# isolation is required on pin D2.

########################################################


-from PDRed -pins {D2} \



############################################################

# Define state retention rules for registers in domain PDRed

############################################################

create_state_retention_rule -name ... \

-domain PDRed \

-secondary_domain PDBlue \

-save_edge ...



#################################################

# Map domains in macro model to top-level domains

#################################################


##################################################

# include command specifies macro model for ipInst

##################################################

include macro.cpf

end_design



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


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

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.

Source

ncvlog/ncvhdl

ncelab

Snapshot

CPF

Compile the design.

Elaborate the design.

The elaborator reads the CPF file and creates the necessary logic to model your design’s power requirements.

The -lps_simctrl_on option enables the use of several low-power command-line options at simulation time.

Simulate the snapshot.

ncelab -lps_cpf cpf_file -lps_simctrl_on [other_options] top_level_unit

ncsim

ncsim [-lps_options] [other_options] snapshot_name



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:



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

-lps_assign_ft_buf

Specifies that a continuous assignment is to be treated as a buffer.

By default, a net from an always-on domain that enters and passes through a power-down domain (a feedthrough net modeled as a continuous assignment) is treated as a wire and is not forced to X when the domain is powered down. Use the -lps_assign_ft_buf option to specify that a continuous assignment is to be treated as a buffer. In this case, the feedthrough net will be corrupted.

ncsim -lps_alt_srr

irun -lps_alt_srr

ncelab -lps_assign_ft_buf

irun -lps_assign_ft_buf



-lps_blackboxmm

Treat all macro models as a black box.

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

For a macro model that is treated as a black box:

■ All corruption, isolation, and state retention outside the macro model is limited to the boundary ports defined by the macro model. All input boundary ports of the macro model will assume there is a load inside the macro model in the domain associated with the input boundary port. All output boundary ports of the macro model will assume a driver inside the macro model in the domain associated with the output boundary port.

■ All corruption, isolation, and state retention defined inside the macro model (that is, inside set_macro_model and end_macro_model) is ignored. All isolation and state retention rules are ignored. Boundary ports are not corrupted. Registers that are part of a switchable power domain are not corrupted. A black box macro model will not apply any corruption to an internal domain even if it is mapped to an external switchable domain.

By default, the simulator treats all macro models as having a partially power-aware model, and treats them as gray boxes.

You must use the -lps_blackboxmm option (ncelab -lps_blackboxmm or irun -lps_blackboxmm) to treat macro models as black box models.

See Chapter 5, “Modeling a Macro Cell,” for details on macro models.

-lps_cellrtn_off

Suppresses implicit state retention insertion from primitive cells.

In a mixed gate/RTL simulation, the implicit state retention behavior should apply to the RTL portions of the design, but must not apply to a gate netlist or to primitive cells instantiated in the RTL code. Use the -lps_cellrtn_off option to exclude primitive cells from the implicit state retention behavior.

ncelab -lps_blackboxmm

irun -lps_blackboxmm



See “Simulating a Mixed RTL/Gate Design with Instantiated Primitive Cells” on page 213 for details on using this option.

-lps_cpf cpf_filename

Specifies the name of the CPF file to be used with the design or block being simulated.

Power information can be specified in multiple CPF files, each of which describes power information for a block of the design. In most cases, there is one CPF file that specifies the power information for the whole design by directly or indirectly sourcing other CPF files. The CPF file specified with the -lps_cpf option is the CPF file corresponding to the design being simulated.

-lps_dtrn_min

Treats the value specified for the transition slope with an update_power_domain -transition_slope option as the minimum slope.

When you specify domain-level active state conditions to control the transition of power domains to specific nominal conditions (create_power_domain -active_state_conditions), you can specify the delay for a power domain to reach its destination nominal condition. The delay is specified with the -transition_slope option of the update_power_domain command.

update_power_domain -name domain_name -transition_slope [float:]float

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.

ncelab -lps_cellrtn_off

irun -lps_cellrtn_off

ncelab -lps_cpf cpf_filename

irun -lps_cpf cpf_filename



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

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

ncelab -lps_dtrn_min

irun -lps_dtrn_min

ncsim -lps_enum_rand_corrupt [seed]

irun -lps_enum_rand_corrupt [seed]



-lps_enum_right

When power is shut off, corrupt objects of VHDL user-defined enumerated types with the right-most values.

When a domain is powered down, this option selects the right-most enumeration literal as the corruption value.


Besides the -lps_enum_right option, you can specify how VHDL enumerated types are corrupted at power down with the following options:

■ -lps_enum_rand_corrupt

■ -lps_implicit_pso

■ -lps_implicitpso_char

■ -lps_implicitpso_nonchar


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

ncsim -lps_enum_right

irun -lps_enum_right



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.



-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

ncvhdl -lps_implicit_pso

irun -lps_implicit_pso



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.


-lps_implicitpso_nonchar value

When power is shut off, corrupt objects of VHDL user-defined enumerated types that have identifiers specified in the definition with the identifier specified by the value argument.

-lps_implicitpso_char Y

If the source file that contains the definition of the enumerated type has been compiled with the -lps_implicit_pso option, an X enumeration literal is implicitly added as the right-most literal in the enumeration type definition to represent the power-down state. However, if the definition of the enumerated type includes an X enumeration literal, the elaborator generates an error telling you that there is a conflict between the existing X enumeration literal and the implicitly-added X.

Use the elaborator -lps_implicitpso_nonchar option (ncelab -lps_implicitpso_nonchar or irun -lps_implicitpso_nonchar) to override the default implicitly-added X value. The specified enumeration literal will be used as the power-down state.

Note: If the source file has not been compiled with -lps_implicit_pso, the -lps_implicitpso_nonchar option is ignored with a warning.

ncelab -lps_implicitpso_char

irun -lps_implicitpso_char




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

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

ncelab -lps_implicitpso_nonchar

irun -lps_implicitpso_nonchar

ncelab -lps_iso_off

ncsim -lps_iso_off

irun -lps_iso_off



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.

-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 filteringinformation to the default log file)

-lps_isofilter_verbose -lps_logfile iso.log (Writes isolation filteringinformation 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.

ncelab -lps_iso_verbose

ncsim -lps_iso_verbose

irun -lps_iso_verbose



******Isolation Filtering Information

Following pins from isolation rule at (./cpf.cpf:11) are not isolated:

<L> tb.test.ISO1.B

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

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

ncelab -lps_isofilter_verbose

irun -lps_isofilter_verbose

ncelab -lps_isoruleopt_warn

irun -lps_isoruleopt_warn



% irun -lps_cpf dut.cpf -lps_verbose 3 \

-logfile simrun.log \ ;# Creates log file simrun.log (instead of irun.log)

-lps_logfile lps.log \ ;# Creates lps.log for low-power information

-lps_log_verbose lps_verbose.log \ ;# Creates lps_verbose.log for-lps_verbose output

[other_options] source_files

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

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

-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

ncelab -lps_log_verbose filename

ncsim -lps_log_verbose filename

irun -lps_log_verbose filename

ncelab -lps_logfile filename

ncsim -lps_logfile filename

irun -lps_logfile filename



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.

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

-lps_mvs

Turns on voltage scaling simulation and voltage tracking.

ncelab -lps_modules_wildcard

irun -lps_modules_wildcard

ncelab -lps_mtrn_min

irun -lps_mtrn_min



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.

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

-lps_notlp

Turn off special treatment for top-level ports.

ncelab -lps_mvs

irun -lps_mvs

ncelab -lps_no_xzshutoff

irun -lps_no_xzshutoff



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.



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.

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

ncsim -lps_off

irun -lps_simctrl_on -lps_off



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

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


ncelab -lps_pmode

irun -lps_pmode

ncelab -lps_pmcheck_only

irun -lps_pmcheck_only



-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

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.

Qm

Save/Restore

Poff

Value of Qm stored in Qs.

Qm restored with value of Qs.

Power down.Value of Qm forced to X.

Power up. Force on Qm released.



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.

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

-lps_simctrl_on

Enables simulation-time control over the power simulation.

This option lets you elaborate the design with power and then control the power simulation without re-elaborating the design.

In multi-step invocation mode, you include this option on the ncelab command line, and then include the options that control the power simulation on the ncsim command line. For example:

ncelab -lps_rtn_lock

ncsim -lps_rtn_lock

irun -lps_rtn_lock

ncelab -lps_rtn_off

ncsim -lps_rtn_off

irun -lps_rtn_off



% 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

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

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

ncelab -lps_simctrl_on

irun -lps_simctrl_on

ncelab -lps_srruleopt_warn

irun -lps_srruleopt_warn

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





...


...

Use the -lps_stdby_nowarn option to suppress the generation of the input violation warning messages.

The -lps_stdby_nowarn option can be used as a simulation-time control option. You must elaborate with the -lps_simctrl_on option to enable this option at simulation time.

-lps_stime start_time

Specifies the time when the simulator should start low-power simulation.

irun -lps_sim_verbose

ncelab -lps_stdby_nowarn

ncsim -lps_stdby_nowarn

irun -lps_stdby_nowarn



This option is useful when, at the beginning of simulation, there is a long initialization sequence that does not include power signal activities.

The start_time argument is an integer value followed by a time unit. The unit can be ps, ns, or s. If you do not specify a unit, the default is ps. For example, the following two options are identical:

-lps_stime 40ps

-lps_stime 40

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

The -lps_stime option can be used as a simulation-time control option. You must elaborate with the -lps_simctrl_on option to enable this option at simulation time.

-lps_stl_off

Turns off state loss.

By default, state loss is enabled. When simulating a gate-level netlist in which state retention cells are represented by physical models with power and ground connections, the state loss behavior is modeled by the cell itself. The simulator does not need to provide any implicit state loss behavior. Use the -lps_stl_off option to turn off the CPF implicit state loss behavior.

The -lps_stl_off option can be used as a simulation-time control option. You must elaborate with the -lps_simctrl_on option to enable the use of this option at simulation time.

-lps_upcase

Converts all identifiers in the CPF file to uppercase.

ncelab -lps_stime start_time

ncsim -lps_stime start_time

irun -lps_stime start_time

ncelab -lps_stl_off

ncsim -lps_stl_off

irun -lps_stl_off



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.

ncelab -lps_verbose {1 | 2 | 3}

ncsim -lps_verbose {1 | 2 | 3}

irun -lps_verbose {1 | 2 | 3}


../vlogcompopts/vlog_comp_opts.html#uppercase


-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

The -lps_verbose output can be divided into two sections. The first section contains information about the power domains; the second section contains information about power modes. The following two tables show you what information is printed to the log file with -lps_verbose 1, and what information is added when you specify -lps_verbose 2 or -lps_verbose 3.



Table 6-1 Power Domain Information in -lps_verbose Output

-lps_verbose 1 -lps_verbose 2 adds ... -lps_verbose 3 adds ...

domain name and scope

base domain names

mapped domain names

power mode control groupname

current slope, min slope,max slope

Isolation:

rule name and scope

secondary domain

isolation output

State Retention:

rule name and scope

secondary domain

Active State Conditions:

nominal condition name

expression

Assertion Control:

rule name and scope

type (reset or suspend)

power domain name

CPF source/line of powerdomain rule

initial blocks for power replay

CPF source/line for mappeddomains

CPF source/line of isolationrule

control condition

CPF source/line of retentionrule

save edge/level

restore edge/level

save/restore precondition

CPF source/line of assertioncontrol rule

disable condition

domain instances

boundary ports

isolation ports

register names

assertion names



Table 6-2 Power Mode Information in -lps_verbose Output

-lps_verbose 1 -lps_verbose 2 adds ... -lps_verbose 3 adds ...

Nominal Conditions:

name

scope

voltage

Power Mode Control Group:

name

scope

power domain names

power mode names

power mode transitions(with from and to modes)

Power Modes:

name

scope

power domain name andnominal condition

Power ModeTransitions:

name

scope

from and to mode

min and max latency

CPF source/line of nominalcondition command

state

CPF source/line of controlgroup command

CPF source/line of powermode command

group modes

CPF source/line of modetransition command

start condition

end condition

For power modeinformation,-lps_verbose 3 isthe same as-lps_verbose 2



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

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

ncelab -lps_verify

irun -lps_verify

ncelab -lps_vplan

irun -lps_vplan



7Simulating an RTL-Level Design

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

Simulating an Example Design

This section shows how to perform a low-power simulation on a simple nano CPU design.

Note: The source files for this example are located in the following directory:

install_directory/doc/PowerForwardUG/examples/pso

The nano CPU is a 32-bit RISC processor, shown in Figure 7-1 on page 197.

Figure 7-1 The Nano CPU Processor


Low-Power SimulationSimulating an RTL-Level Design

This design has the following power domains:

■ PDcore—The default power domain, which contains the I/O controller, program counter, state sequencer, power control unit, address register, instruction register, data-in register, and data-out register

Power to this domain is always on.

■ PDau—The arithmetic unit power domain

The arithmetic unit requires state retention and isolation.

■ PDlu—The logic unit power domain

The logic unit requires isolation, but not state retention.

■ PDalu—The ALU power domain

The ALU requires isolation, but not state retention.

■ PDrf—The register file power domain

The register file requires state retention and isolation.

The Power Control Unit generates the control signals for isolation, state retention, and power switch enable. The power control signals, along with the power domains that they control, are defined in Table 7-1 on page 198. The PDcore power domain is not associated with any control signals because its power is always on.

Table 7-1 Nano Design Power Specification

Signals Controlling the Power Domains

Domains Isolation Enable State RetentionEnable

Power SwitchEnable

PDcore — — —

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

PDlu plu[0] — plu[2]

PDalu palu[0] — palu[2]

PDrf prf[0] prf[1] prf[2]



Specifying Power Information in the CPF File

The CPF file used in this example is called nano.cpf. This file contains only commands that pertain to simulation. However, a CPF file can contain commands that are used by downstream tools. These commands are ignored during simulation.

See the Common Power Format Language Reference for complete details on the commands used in the CPF file.

The nano.cpf file is as follows:

# Specify the CPF version.

set_cpf_version 1.1

# Specify the hierarchy delimiter character to be used in object names.


# Specify the name of the module to which the power information applies.

set_design core

# Define the power domains.

# Specify the instances that belong to the domain (-instances).

# Specify the condition when the domain is shut off (-shutoff_condition).

create_power_domain -name PDcore -default

create_power_domain -name PDalu \

-instances alu_inst \

-base_domains {PDcore} \

-shutoff_condition {pcu_inst/palu[2]}

# Power domain PDalu is base power domain of domain PDau

create_power_domain -name PDau \

-instances alu_inst/aui \

-base_domains {PDalu} \

-shutoff_condition {pcu_inst/pau[2]}

# Power domain PDalu is base power domain of domain PDlu

create_power_domain -name PDlu \

-instances alu_inst/lui \


-shutoff_condition {pcu_inst/plu[2]}



create_power_domain -name PDrf \

-instances rf_inst \

-base_domains {PDcore} \

-shutoff_condition {pcu_inst/prf[2]}

# Define the rules for replacing registers in a power domain with state# retention registers.

# Specify the instances to be replaced with a state retention register (-instances).

# Specify the condition when the states of the registers need to be# restored (-restore_edge).

# The condition when the states of the registers need to be saved is the inversion# of the restore_edge expression.

create_state_retention_rule -name PDrf_sr \

-instances {rf_inst/rf[*]} \

-restore_edge {!pcu_inst/prf[1]}

create_state_retention_rule -name PDau_sr \

-instances {alu_inst/aui/z*} \

-restore_edge {!pcu_inst/pau[1]}

# Define the rules for adding isolation cells.

# Specify the pins that must be isolated in a power domain (-pins).

# Limit the pins to be isolated to output pins in the power domain (-from).

# Specify the condition when the pins should be isolated (-isolation_condition).

# Specify the isolation type (-isolation_output).

create_isolation_rule -name PDau_iso \

-from PDau \

-pins alu_inst/aui/z* \

-isolation_condition {pcu_inst/pau[0]} \


create_isolation_rule -name PDlu_iso \

-from PDlu \

-pins alu_inst/lui/z* \

-isolation_condition {pcu_inst/plu[0]} \


create_isolation_rule -name PDalu_iso \

-from PDalu \

-pins alu_inst/z* \

-isolation_condition {pcu_inst/palu[0]} \




create_isolation_rule -name PDrf_iso \

-from PDrf \

-pins {rf_inst/a[*] \

rf_inst/b[*] \

rf_inst/z[*]} \

-isolation_condition {pcu_inst/prf[0]} \


#Define assertion control rules

create_assertion_control -name AC_1 \

-domains {PDau PDlu PDalu} \

-type {reset}

create_assertion_control -name AC_4 \

-domains {PDrf} \

-type {reset}

end_design core

Running the Simulation

For this example, we assume that you have simulated and debugged the design without power information, and that you now want to simulate and debug the design with power. The design will be elaborated with the -lps_simctrl_on option to enable simulation-time control over the power simulation. Using this option lets you elaborate the design and generate a snapshot with power and then simulate the snapshot using command-line options to control the simulation.

You can simulate the design by invoking the compiler, elaborator, and simulator in separate steps (multi-step invocation mode), or you can run the simulation in single-step invocation mode with irun.

Simulating in Multi-Step Mode

1. Compile the design files.

% ncvlog nano_defines.v testbench.v nano.v

2. Elaborate with power.



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.



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.



Figure 7-3 Expanding the Arithmetic Unit Power Control Bus

The following signals in this bus control power:

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:

pau[2] Power on/off

pau[1] Save/restore state retention cells

pau[0] Isolation on/off

Isolation enabled

State retention save

Power down

Power up

State retention restore

Isolation disabled



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, , until you locate the PDLU opcode at 33,800,000 ps.

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



The following signals in this bus control power:

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 until you find the power-down or Nano exampleNpower-up opcodes.

plu[2] Power on/off

plu[1] Store/restore state retention cells

Note: This signal is ignored because state retention is not specified for this power domain in the CPF file.

plu[0] Isolation on/off



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

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

RTL Source CPF

Encounter RTL CompilerLibrary

Gate-level netlist

Incisive simulator TestbenchTest vectors


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



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.



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.



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.


# Specify the name of the module to which the power information applies.

set_design core

# Define the power domains.

# Specify the instances that belong to the domain (-instances).

# Specify the condition when the domain is shut off (-shutoff_condition).

create_power_domain -name PDcore -default




create_power_domain -name PDlu \

-instances alu_inst/lui \

-shutoff_condition {pcu_inst/plu[2]}



create_power_domain -name PDalu \

-instances alu_inst \

-shutoff_condition {pcu_inst/palu[2]}




# Define rules for replacing registers in a power domain with state retention# registers.

# Specify the instances to be replaced with a state retention register (-instances).

# Specify the condition when the states of the registers need to be restored# (-restore_edge).

# The condition when the states of the registers need to be saved is the inversion# of the restore_edge expression.

create_state_retention_rule -name PDrf_sr \

-instances {rf_inst/rf[0] rf_inst/rf[1] rf_inst/rf[2]

rf_inst/rf[3] rf_inst/rf[4] rf_inst/rf[5]

rf_inst/rf[6] rf_inst/rf[7]} \

-restore_edge {!pcu_inst/prf[1]}


-instances {alu_inst/aui/z* } \


# Define the rules for adding isolation cells.

# Specify the pins that must be isolated in a power domain (-pins).

# Limit the pins to be isolated to output pins in the power domain (-from).

# Specify the condition when the pins should be isolated (-isolation_condition).

# Specify the isolation type (-isolation_output).


-from PDau \




create_isolation_rule -name PDlu_iso \

-from PDlu \

-pins alu_inst/lui/z* \

-isolation_condition {pcu_inst/plu[0]} \




create_isolation_rule -name PDalu_iso \

-from PDalu \

-pins alu_inst/z* \

-isolation_condition {pcu_inst/palu[0]} \


create_isolation_rule -name PDrf_iso \

-from PDrf \

-pins rf_inst/z* \

-isolation_condition {pcu_inst/prf[0]} \


# Specify cells that are always on

define_always_on_cell -cells "BUFGX2M BUFGX8M INVGX2M INVGX8M"

# Identify isolation cells in the netlist. Wildcards can be used in cell names.

define_isolation_cell -cells ISOLN* \

-enable EN

define_isolation_cell -cells "LVLHLEHX* LVLLHEHX* LVLHLELX*" \

-enable EN

# Identify state retention cells in the netlist. Wildcards can be used.

# Specify cell pins that are always on (-always_on_pins)

# Specify the restore pin, which enables the cell to restore the saved value after exiting power shutoff mode (-restore_function).

# Identify the register(s) within the state retention cell that remains on when the power domain is powered down (-always_on_components)

define_state_retention_cell -cells *DRFF* \

-always_on_pins {clear clk enable save restore} \

-restore_function restore \

-always_on_components {ad1_1 nd1_1 nd2_1 nd4_1 nd5_1nd6_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.



To exclude primitive cells from the implicit state retention behavior, use the -lps_cellrtn_off option (ncelab -lps_cellrtn_off or irun -lps_cellrtn_off).

The -lps_cellrtn_off option specifies that all modules that are marked as cells must be excluded from state retention. A module is tagged as a cell if:

■ The module is enclosed by the `celldefine/èndcelldefine directives.

`celldefine

module ram_behave (...);

...

reg tmp1, tmp2; //Exclude these registers from state retention

...

endmodule

èndcelldefine

■ The module is in a file compiled with the -libcell option (ncvlog -libcell or irun -libcell).

Note: If you are running the simulator in multi-step invocation mode, you must use the -libcell option to tag modules not enclosed with `celldefine/èndcelldefine as cells. However, if you are running the simulator in single-step invocation mode using irun, the -libcell option is turned on by default to tag modules extracted from libraries (from -y, -v, or ùselib) as cells. You can use the irun -nolibcell option to override this behavior. Modules surrounded with `celldefine/èndcelldefine are still treated as cell modules.

The -lps_cellrtn_off option eliminates state retention for all primitive cells. No checking is performed to filter out special low-power cells. If the modules that are tagged as cells include low-power cells that provide low-power functionality, this option must be used with caution. State retention cells are in switchable domains, and their states will be corrupted during power off. Isolation cells with a hold latch will also be corrupted. In order to allow the cell's simulation model to correctly simulate the state retention behavior, you must specify these cells in the CPF file with the define_state_retention_cell and define_isolation_cell commands to identify always-on pins and the always-on components, such as the save or hold latch, that must not be corrupted during power off.

define_state_retention_cell \

-cells {...} \

-always_on_components {...} \

-always_on_pins {...} \

-save_function {...} -restore_function {...}



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


../InvokingSimVision/invoking.html#firstpage

Low-Power SimulationDebugging a Low-Power Simulation

To open the sidebar:

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

The lightbulb next to each domain name indicates its state at the current simulation time, as follows:

Click the Power tab in the Design Browser, Source Browser, Waveformwindow, or Schematic Tracer.

Domain is powered up.

Domain is powered down.



If you place the cursor over a power domain name, information about that domain is displayed, as shown in Figure 9-2 on page 217.

Figure 9-2 Displaying Power Domain Information

In this example, domain PDau is powered on. Domain PDau will be powered off if its shutoff condition is true. It will also be powered off when its base domain (PDalu) is powered off.

When you expand a power domain, the sidebar displays items for the instances, isolation ports, state retention elements, isolation rules, and state retention rules in that domain. You can expand these items to see those objects, as shown in Figure 9-3 on page 218.

Domain state is not available.

Power domain and its base domains are powered up.

Domain is powered down because all of its base domainsare powered down.

Domain is powered down because its shutoff condition istrue.



Figure 9-3 Expanding the PDau Power Domain

The following icons are used in the Power sidebar to provide information about each object:

Isolation is in effect and the isolation value for the port is high.

Isolation is in effect and the isolation value for the port is low.

Isolation is in effect and the isolation value for the port is hold.

Isolation is not in effect. Isolation value is specified as high in the CPF file.

Isolation is not in effect. Isolation value is specified as low in the CPF file.

Isolation is not in effect. Isolation value is specified as hold in the CPF file.

Isolation is not in effect and the isolation enable is unknown (x).Isolation value is specified as high in the CPF file.

Isolation is not in effect and the isolation enable is unknown (x).Isolation value is specified as low in the CPF file.



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.

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.


../DesignBrowser/monitoring_objects.html#firstpage


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.


../SourceBrowser/source.html#firstpage

../SourceBrowser/source.html#firstpage


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



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



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.


../Waveform/WaveformTOC.html


■ 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


../SchematicTracer/schematic.html#firstpage


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

Tracing Signals in a Power Domain

When a signal is in a power domain, the shutoff condition is also a driver of the net. When the shutoff condition is true, the shutoff condition is the driver on the net.

Likewise, when a port is isolated, the value on the net is the isolation value. The driver of the net is the isolation condition which causes the isolation value to be applied to the signal.

Both shutoff conditions and isolation conditions appear as the drivers of a signal in the Trace Signals sidebar when they apply to the signal being traced. With driver grading, if the condition evaluates to true, the condition appears as the driver of the net. You can then expand the condition to see the signals that contribute to the condition and continue to trace these signals back. Placing the cursor over a condition displays the location in the CPF file where the condition is defined.

To trace a signal that is in a power domain:

1. Select the signal that you want to trace, and set the primary cursor to the time at which the signal has the interesting value. For example, select the signal TESTBENCH.inst.alu_inst.opcode[7:0] and then move the primary cursor to the point where the value becomes X.



2. Open the Trace Signals sidebar and click Trace Driving Logic, . SimVision traces the driving logic until it reaches the first choice point, as shown in Figure 9-8 on page 226.

The signal tracer sorts the list of possible paths according to the likelihood that the path is the active driver for the signal value. In Figure 9-8 on page 226, PDalu Shutoff Condition and Implicit Isolation Condition are part of the low-power logic in the design. They are listed first, indicating that the signal value is most likely due to a power shutdown.

Figure 9-8 Tracing the Driving Logic in a Power Domain

3. Click one of the choices to continue to trace that path. For example, if you click PDalu Shutoff Condition in Figure 9-8 on page 226, the signal is traced to the next choice point, as shown in Figure 9-9 on page 227.



Figure 9-9 Continuing to Trace the Driving Logic in a Power Domain

The trace shows that the condition was triggered when palu[2] transitioned from 0 to 1.

4. Now move the primary cursor to the point where power is restored to the domain and trace the signal again. At this point, the signal tracer displays the same driving signals, but in a different order, as shown in Figure 9-10 on page 228. The shutoff and isolation conditions are listed last, indicating that they are not the most likely drivers for the signal’s current value.



Figure 9-10 Tracing a Signal Value after Power is Restored to the Domain

In Figure 9-11 on page 229, the port TESTBENCH.inst.b[31:0] is being traced. This port is currently isolated. The driver of the net is shown as the isolation condition. Tracing this driver shows that the condition was triggered when inst.pcu_inst.prf[0] transitioned from 0 to 1.



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.


../SignalTracer/fulltrace.html#firstpage

../SignalTracer/fulltrace.html#firstpage


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.



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

Domain is transitioning from one power mode to a differentpower mode, and the domain has a base domain.

Domain is in standby mode.


../abvsimulate/view.html#firstpage

../abvsimulate/view.html#firstpage


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

Figure 9-14 Power Sidebar with Power Modes

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

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

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 pdA is in transition state.

Icon indicates that power domain pdT is on.

Icon indicates that power domain pdB is off.



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.



Figure 9-16 Waveform Window with Power Domain Groups

3. Click Run, , to simulate the design. SimVision generates the waveforms for the objects.

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



Figure 9-17 Waveform Window with structs Expanded



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.



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.



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.



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



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:

■ -instances–Displays 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_ports–Displays 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_variables–Displays 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.

■ -state–Displays 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



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.

■ -verbose–Adds the following information to the output:

❑ The CPF file and line number of the create_power_domain command for the power domain

❑ The names of any mapped domains for the specified power domain, and the CPF files and line numbers where the mapped domains are defined

❑ The names of any base domains of the specified power domain, and the CPF files and line numbers where the base domains are defined

❑ The name of the power mode control group for the specified power domain, and the CPF file and line number where the control group is defined

❑ The slope defined for the power domain. The slope is displayed as volts per time unit, where the time unit is the time resolution of the simulation.

❍ If both a minimum and maximum slope are defined, the output shows the current, minimum, and maximum slope.



❍ If only the maximum slope is defined, only the current slope is displayed.

❍ If no slope is defined, the current slope is shown as “infinite”.

Examplesncsim> scope dut

ncsim> run 502 ns

Ran until 502 NS + 0

ncsim> power -pdname PD_compress ;# Specify a power domain name. With no;# options, -instances is the default.

Power Domain tb.dut.PD_compress

Top instances:

tb.dut.inst_compress

ncsim>

ncsim> power -pdname PD_compress -verbose ;# -verbose option adds information;# about base domains, power mode;# control group, current slope


Power domain rule: file ./test_mvs.cpf line 31

Base Domains:

tb.dut.PD_default

Power domain rule: file ./test_mvs.cpf line 27

Control Group:

tb.dut (default)

Control group rule : file ./test_mvs.cpf line 9

Current Slope: 0.200000 volt/ns

Top instances:


ncsim>

ncsim> power -pdname PD_compress -instances -isolation_ports


Top instances:


Isolation ports:

tb.dut.inst_compress.out4

Status is: not enabled

Isolation rule: file ./test_mvs.cpf line 63












ncsim>

ncsim> power -pdname PD_compress -sr_variables -state ;# -state option displays;# current state of the;# power domain, and saved;# values of retention;# variables.

Power Domain tb.dut.PD_compress is ON, nominal condition is NC_08, voltage = 0.800000

State Retention variables and registers:

tb.dut.inst_compress.out4 (saved value = 1’h0)

State Retention rule: file ./test_mvs.cpf line 69

Status is: retained



Status is: retained



Status is: retained



Status is: retained

ncsim>

ncsim> power -object TESTBENCH.inst.alu_inst.aui.br \ ;# Specify an object name

> -sr_variables -isolation_ports -state

Power Domain TESTBENCH.inst.PDau is OFF

Isolation ports:

TESTBENCH.inst.alu_inst.aui.z

Status is: enabled

Isolation rule: file ./nano.cpf line 54


TESTBENCH.inst.alu_inst.aui.z (saved value = 32’h0000124e)

State Retention rule: file ./nano.cpf line 44

Status is: retained



In the following example, the CPF file includes a create_power_mode command that defines a power mode called M3. This power mode consists of power domain pdT at nominal condition NC_12 (1.2 V), power domain pdA at nominal condition NC_12 (1.2 V), and power domain pdB at nominal condition NC_08 (.8 V).


-default \


ncsim> power -pwr_mode M3

Power mode top.M3

Domains:

pdT

Nominal condition is (NC_12): voltage = 1.200000

pdA


pdB


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:



■ -pd_off–Stop when the power domain turns off.

■ -pd_on–Stop 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_standby–Stop when the power enters standby mode.

■ -pd_trans–Stop when the power domain transitions. The breakpoint triggers when the specified power domain starts transitioning from one nominal condition to a different nominal condition.

■ -isolation–Stop when any isolation rule associated with the power domain is enabled or disabled.

❑ -iso_disable–Stop when any isolation rule associated with the power domain is disabled.

❑ -iso_enable–Stop when any isolation rule associated with the power domain is enabled.

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

❑ -sr_restore–Stop when any state retention rule associated with the power domain restores its variables.

❑ -sr_save–Stop when any state retention rule associated with the power domain saves its variables.

Example

In this example, the CPF file includes the following CPF commands. The -shutoff_condition option in the create_power_domain command specifies the power switch enable signal.








-from PDau \







The following command sets a breakpoint on power domain PDau. Simulation stops when the power switch enable signal is asserted and the power domain is powered down, or when it is deasserted and power is restored to the domain.

ncsim> scope TESTBENCH.inst

ncsim> stop -pdname PDau

Created stop 1

ncsim> stop -show

1 Enabled Power Domain TESTBENCH.inst.PDau

ncsim> run

15800 NS + 6 (stop 1: Power Domain TESTBENCH.inst.PDau is OFF)

TESTBENCH.inst.PDau ./nano.cpf line 21

ncsim> value pcu_inst.pau[2]

1’h1

ncsim> run

23800 NS + 6 (stop 1: Power Domain TESTBENCH.inst.PDau is ON)



1’h0

ncsim>

The following command creates a breakpoint on power domain PDau. The -pd_off option specifies that simulation will stop when the domain powers down.

ncsim> stop -pdname PDau -pd_off

Created stop 1

ncsim> run



ncsim> run





The following command creates a breakpoint on power domain PDau. The -isolation -iso_enable option specifies that simulation will stop when the isolation rule associated with the domain PDau (PDau_iso) is enabled.

ncsim> stop -pdname PDau -isolation -iso_enable

Created stop 1

ncsim> stop -show

1 Enabled Power Domain Isolation TESTBENCH.inst.PDau_iso (enable)

ncsim> run

13400 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso: is ENABLED)

TESTBENCH.inst.PDau_iso ./nano.cpf line 56

The following stop command creates a breakpoint on power domain PDau. The -retention option specifies that simulation will stop when the state retention rule associated with the domain PDau (PDau_sr) either saves or restores its variables. A subsequent stop command includes the -retention -sr_save option to specify that simulation will stop only when the state retention rule saves its variables.

ncsim> scope inst

ncsim> stop -name PDau_ret -pdname PDau -retention

Created stop PDau_ret

ncsim> run

14200 NS + 6 (stop PDau_ret: State Retention Rule TESTBENCH.inst.PDau_sr)

TESTBENCH.inst.PDau_sr ./nano.cpf line 46


1’h1

ncsim> run

26200 NS + 6 (stop PDau_ret: State Retention Rule TESTBENCH.inst.PDau_sr)



1’h0

ncsim> stop -disable PDau_ret

ncsim> stop -name PDau_ret_save -pdname PDau -retention -sr_save

Created stop PDau_ret_save

ncsim> run

59 US + 6 (stop PDau_ret_save: State Retention Rule TESTBENCH.inst.PDau_sr)



1’h1

In a power mode simulation, you can use the -pd_trans option to stop the simulation when the specified power domain starts to transition from one nominal condition to a different nominal condition. For example:



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




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

top.mt1 ./dut.cpf line 62

ncsim>

The following command includes the -pd_standby option, which stops the simulation when power domain pdB enters standby mode

ncsim> stop -pdname pdB -pd_standby

Created stop 1

ncsim> run

...

...




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

top.pdB ./dut.cpf line 32

ncsim>

Setting a Breakpoint on an Isolation Rule

Use the stop -iso_rule command to stop the simulation when the specified isolation rule becomes enabled or disabled.

You can specify multiple isolation rule names.

The -iso_rule option has two suboptions:

■ -iso_disable–Stop only when the isolation rule becomes disabled.



■ -iso_enable–Stop 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)


ncsim> run

28600 NS + 6 (stop 1: Isolation Rule TESTBENCH.inst.PDau_iso is DISABLED)


Setting a Breakpoint on a State Retention Rule

Use the stop -sr_rule command to stop the simulation when the specified state retention rule saves or restores its variables.

You can specify multiple state retention rule names.

The -sr_rule option has two suboptions:

■ -sr_restore–Stop only when the state retention rule restores its variables.

■ -sr_save–Stop 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



Setting a Breakpoint on a Power Mode Transition

Use the stop -pwr_mode_transition command to stop the simulation when the specified power mode transition starts and ends.

stop -pwr_mode_transition mode_transition_name [mode_transition_name ...]

Example

In this example, the CPF file defines a power mode transition called mt1 with the following create_mode_transition command:


-from M3 -to M1 \

-start_condition pmc.mte[1]

Power modes M3 and M1 are defined with the following two create_power_mode commands:


-default \



-domain_conditions {pdT@NC_08 pdA@NC_08}

The following stop command creates a breakpoint that stops the simulation when power mode transition mt1 starts and ends.

ncsim> stop -pwr_mode_transition mt1

Created stop 1

ncsim> stop -show

1 Enabled Power Mode Transition top.mt1

ncsim> run

0 clk=0 data=000000 ndata=111111

5 clk=1 data=000001 ndata=111110

...

...

95 clk=1 data=001010 ndata=110101




ncsim> run












ncsim>

Displaying the Saved Value of a State Retention Variable

You can display the saved value of a state retention variable:

■ By using the Tcl value -saved command.

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

ncsim> value SR1

The following command returns the saved value.

ncsim> value -saved SR1

■ By using a probe -sr_save command. This option probes both the value of the state retention variables and the saved value of the variables.

You can specify a scope or variable names.

probe -create scope_name -shm -sr_save

probe -create variable_name -shm -sr_save

If you specify a scope, you can use -all -memories (for Verilog) or -all -variables (for VHDL).

Note: In the current release, using the -depth option with -sr_save is not supported. For example, the following command is not supported:

probe -create -depth all -all -sr_save



The name of the saved variable is variable_name_sr. The value of this variable can be viewed in SimVision.

Example

In this example, the CPF create_power_domain command creates a power domain called PDau, which contains instance alu_inst/aui. The create_state_retention_rule command specifies that register alu_inst.aui.z is to be replaced with a state retention cell. The current value of the register is saved when the save_edge expression changes from false to true. The saved value is restored when the restore_edge condition changes from false to true.






-save_edge {pcu_inst/pau[1]} \


ncsim>

;# Set break on state retention save enable

ncsim> stop -object inst.pcu_inst.pau[1]

Created stop 1

ncsim> stop -pdname PDau ;# Set break on power domain PDau

Created stop 2

ncsim> run ;# Run until save enable is active

100 PS + 3 (stop 1: TESTBENCH.inst.pcu_inst.pau[1] = 0)

ncsim> run

14200 NS + 4 (stop 1: TESTBENCH.inst.pcu_inst.pau[1] = 1)

ncsim> run 1 ps

Ran until 14200001 PS + 0

ncsim> power -pdname PDau -sr_variables ;# See if variable is retained

Power domain is (PDau)


TESTBENCH.inst.alu_inst.aui.z

State Retention rule: file ./nano.cpf line 44

Status is: retained

ncsim> value inst.alu_inst.aui.z ;# Display current value

32’h0000124e



ncsim> run ;# Run until power domain is shut off

15800 NS + 6 (stop 2: Power Domain PDau)

ncsim> value inst.alu_inst.aui.z ;# Display current value

32’hxxxxxxxx

ncsim> value -saved inst.alu_inst.aui.z ;# Display saved value

32’h0000124e

ncsim>

Probing Control Expressions

Use the -power option on the probe command to probe all low-power simulation control expressions to the SHM database.

Only SHM probes are supported. VCD, EVCD, and screen probes (using -screen) are not supported. Including the -shm option is not required.

Example

In the following example, the probe -power command probes all of the control expressions shown in Table 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.pau[1]

TESTBENCH.inst.pcu_inst.pau[0]

TESTBENCH.inst.pcu_inst.plu[0]

TESTBENCH.inst.pcu_inst.palu[0]


Number of objects probed : 10

ncsim>



Probing Power Mode Information

Use the -pwr_mode option on the probe command to enable the probing of power mode information for all power domains.

Only SHM probes are supported. VCD, EVCD, and screen probes (using -screen) are not supported. Including the -shm option is not required.

Note: The only other probe command option that can be used with -pwr_mode is the -name option. You cannot specify other objects with the probe -pwr_mode command.

The following information is saved in the SHM database for each power domain:

■ The power domain name

■ The name of the power mode the domain is currently in

■ The state of the power domain (ON, OFF, TRANSITIONING, STANDBY, UNINITIALIZED)

■ The nominal condition name and current voltage of the power domain

Example

In the following example, the probe -pwr_mode command probes power mode information for the three power domains in the design.

ncsim> database -open -shm -into waves.shm waves -default

Created default SHM database waves

ncsim> probe -create -pwr_mode -database waves

Created probe 1

ncsim> probe -show

1 Enabled top.pdT (database: waves) -shm

top.pdA

top.pdB

Number of objects probed : 3

ncsim>

Displaying the Drivers of an Object

The drivers command shows the power drivers, with the corresponding CPF file and line number of the associated CPF command.

In the example design, there are two power domains, defined as follows:









The following create_isolation_rule command is used to illustrate the output of the drivers command:


-to PDrf \



ncsim> ;# Run until isolation is enabled and power is on


Created stop 1

ncsim> run

100 PS + 3 (stop 1: TESTBENCH.inst.pcu_inst.pau[0] = 0)

ncsim> run

13400 NS + 4 (stop 1: TESTBENCH.inst.pcu_inst.pau[0] = 1) ;# Isolation enabled

ncsim> run 1 ps

Ran until 13400001 PS + 0

ncsim> value inst.alu_inst.aui.a ;# Display value of input a

32’h00000dfe

ncsim> drivers inst.alu_inst.aui.a ;# Display drivers of input a

inst.alu_inst.aui.a...input net logic [31:0]

a[31] (wire/tri) = St0

St0 <- low power driver, power domain rule (power domain is on)[File:./nano.cpf, Line:16]

St0 <- (TESTBENCH.inst.rf_inst) assign a = rf[ra]

...

...

a[0] (wire/tri) = St0

St0 <- low power driver, power domain rule (power domain is on)[File:./nano.cpf, Line:16]

St0 <- (TESTBENCH.inst.rf_inst) assign a = rf[ra]

ncsim> value inst.rf_inst.result ;# Display value of input result of rf_inst

32’h00000000 ;# Value is 0 because of isolation rule.



ncsim> drivers inst.rf_inst.result ;# Display drivers of input result

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

result[31] (wire/tri) = St0

St0 <- low power driver, isolation rule (is enabled) [File:./nano.cpf,Line:60]

St0 <- (TESTBENCH.inst) assign result = (opcode == ‘LOAD) ? dinr : alu

...

...

result[0] (wire/tri) = St0

St0 <- low power driver, isolation rule (is enabled) [File:./nano.cpf,Line:60]

St0 <- (TESTBENCH.inst) assign result = (opcode == ‘LOAD) ? dinr : alu

ncsim> ;# Run until PDau powers down


Created stop 2

ncsim> run

Debugging Infinite Loops

Debugging of an infinite loop in a low-power simulation can sometimes be difficult. There are a number of reasons why a simulation can run forever in low power, including the following common cases:

■ You have the following clock generator (or PLL):

always #(DELAY) clk = !clk;

If this code is in a switchable domain, and the domain powers down, DELAY gets set to 0. This causes an infinite loop.

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.



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


Low-Power SimulationAdvanced Low-Power Verification Features

Figure 10-1 Transition Sequence with One Retain Control Signal

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

State retain

Power switch enable

Isolation enabled Isolation disabledState retention enabled. Values are saved.

State retention disabled. Values are restored.

Power down Power up

Isolation

Save

Power switch enable

Isolation enabled Isolation disabled

Save state Restore state

Power down Power up

Restore



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:



-base_domains {PDalu}








-from PDau \




The assertions generated for domain PDau check the control signals in the CPF file for this domain:

■ Power shutoff control pau[2]

■ State retention restore control !pau[1]

■ State retention save control !(!pau[1])

■ Isolation control pau[0]

All assertion names generated for power domain PDau begin with:

LPV_DMN_PDau_

For example:

LPV_DMN_PDau_SHUTOFF_SIGNAL_NOT_X

Automatically-Generated Assertions

The following properties and sequence checks on the low-power control expressions are performed automatically during simulation:

Assertions to Verify That Control Signals Are Not Undefined

A control signal cannot be undefined.

Note: Initial X values at the start of simulation do not result in assertion failures.

The following assertions are generated to verify that control signals are never X:

■ LPV_DMN_DomainName_SHUTOFF_SIGNAL_NOT_X

Power shutoff control signal cannot be X.

■ LPV_DMN_DomainName_ISOLATION_SIGNAL_NOT_X

Isolation control signal cannot be X.



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

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:

Isolation

Shutoff



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:

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:

Restore

Save

Assertion fails here.



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.


LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_1

LPV_DMN_DomainName_SAVE_PRECOND_NOT_FALSE_2


■ LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_number

Restore precondition cannot become false in the restore region.



This assertion is generated for state retention rules that have a restore precondition specified. The assertion fires if the restore precondition becomes false within a restore region.

❑ For an edge-sensitive retention rule, the restore region is the region between power up and the restore edge expression becoming true.

❑ For a level-sensitive retention rule, the restore region is the region between when the restore level expression becomes true until it becomes false.


LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_1

LPV_DMN_DomainName_RESTORE_PRECOND_NOT_FALSE_2


Assertions to Verify Power Mode and Mode Transition Behavior

The following assertions are generated to verify the correct behavior of power modes and power mode transitions:

■ LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_number

Active state condition signal cannot be X.

This assertion is generated for each active state condition defined for a power domain.

If a power domain has multiple active state conditions defined, multiple assertions are generated. To uniquely identify each assertion, a number is appended to the assertion name. For example:

LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_1

LPV_DMN_DomainName_ACTIVE_STATE_SIGNAL_NOT_X_2

■ LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_number

Active state control conditions must be one-hot. This assertion fires when the one-hot property is violated.

This assertion is generated for active state conditions defined for a power domain. A single assertion is generated for each power domain.

To uniquely identify each assertion for power domains with the same name, a number is appended to the assertion label. For example:



LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_1

LPV_DMN_DomainName_ACTIVE_STATES_ONE_HOT_2

■ LPV_PMODE_ModeName_START_SIGNAL_NOT_X

A power mode transition start condition expression cannot be undefined.

This assertion is fired when the start condition expression of a power mode transition goes to a value of X.

This assertion is generated for each power mode transition rule with a -start_condition option specified, and when the -lps_mvs and -lps_pmode options are used.

■ LPV_PMODE_ModeName_END_SIGNAL_NOT_X

A power mode transition end condition expression cannot be undefined.

This assertion is fired when the end condition expression of a power mode transition goes to a value of X.

This assertion is generated for each power mode transition rule with a -end_condition option specified, and when the -lps_mvs and -lps_pmode options are used.

Generating a Coverage Model

CPF specifies detailed information about the signals used to control each power domain, and it is important, as part of a planning-driven verification solution, to analyze coverage data of the control signals and power mode transitions to ensure that they have been fully exercised and to detect any illegal conditions.

Using the -lps_verify command-line option automatically generates a SystemVerilog coverage model for the following low-power data:

■ Power domain shutoff conditions from create_power_domain commands

■ Isolation conditions from create_isolation_rule commands

■ Save/Restore conditions and pre-conditions from create_state_retention_rule commands

■ Active state conditions specified in create_power_domain commands

■ Power modes specified with create_power_mode commands

■ Power mode transitions specified with create_mode_transition commands



■ Power domain states

Coverage is generated for the possible states of the power domain. The possible states of the power domain are:

❑ ON - will always be in the coverage bin.

❑ OFF - will be in the coverage bin only if the domain has a shutoff control signal or if the domain can be in a nominal condition that has the state off.

❑ STANDBY - will be in the coverage bin only if one of the power domain’s 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.


../iccug/iccugTOC.html#firstpage

../iccgui/iccguiTOC.html#firstpage


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



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

...

...



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



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



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


Low-Power SimulationPower-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:



module top;

reg link_pwrdown; // Declare link_register

dut dut1();

initial

begin

link_pwrdown = 0;

/* Link register link_pwrdown to power-down state of domain top.dut1.PD1.

Specify absolute path of power domain using a string constant. */

$lps_link_power_domain_powerdown(link_pwrdown, “top.dut1.PD1”);

end



$lps_get_power_domain(<power_domain_register>[, <instance>]);

Gets the power domain of interest and places its full path name in the power_domain_register. The power_domain_register can then be used as an input argument to subsequent task calls.

Note: The value stored in the power_domain_register is lost when the power domain is powered down. Because the string representing the path to the power domain is no longer available, the register cannot be used as an argument to other system tasks. It is recommended that the $lps_get_power_domain task be always used in an always-on power domain. If the task is used in a switchable domain, the domain must be on when the task is invoked.

Arguments

power_domain_register The register that will contain the full path to the power domain of interest.

The register must be large enough to contain the full path of the power domain. Because each character is 8 bits, a register of 512 characters is defined as:

reg [1:512 * 8] pd;

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



Example 1

CPF commands:

set_design top

create_power_domain -name PD1 -instances dut1 ....

Verilog code:

reg [1:50 * 8] pd_reg;

$lps_get_power_domain(pd_reg); /* In module dut */

$lps_get_power_domain(pd_reg, dut1); /* In module top */

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

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

In this example:

■ Three $lps_get_power_domain tasks get the power domains for instance tb.t1.d1, signal tb.t1.d2.clk (defined as a boundary port in a macro model), and reg tb.t1.d2.ff1 (declared as an instance in the macro model). The procedures place the full path of the power domains into power domain registers pd1, pd2, and pd3.

■ The register pd1 is then used as an input argument to the lps_link_power_domain_powerdown procedure.

CPF commands:

set_cpf_version 1.1

set_macro_model dff4

create_power_domain -name PDMD -default

# Port clk is declared as a boundary port

create_power_domain -name PDM1 \

-boundary_ports {clk rst in1 out1}

# Reg ff1 is declared as an instance in domain PDM2


-instances ff1

end_macro_model

set_design top



-instances d1 \

-shutoff_condition p1.pso \

-base_domains PDD

set_instance d2 -model dff4

create_isolation_rule -name ISO1 ...


end_design



Verilog code:

module tb;

// Declare power domain registers pd1, pd2, pd3

reg [1:512 * 8] pd1;

reg [1:512 * 8] pd2;

reg [1:512 * 8] pd3;

// Declare link register for power down state

reg link_pwrdown;

...

top t1 (clk, rst, in1, in2, out1);

initial

begin

link_pwrdown = 0;

// Put full path of power domain for instance d1 into register pd1

$lps_get_power_domain(pd1, "t1.d1");

// Put full path of power domain of boundary port clk into register pd2

$lps_get_power_domain(pd2, "t1.d2.clk");

// Put full path of power domain for instance ff1 (reg declared as instance in// macro model) into register pd3

$lps_get_power_domain(pd3, "t1.d2.ff1");

$display("Power domain register pd1 = %0s\n", pd1); // Domain tb.t1.PD1

$display("Power domain register pd2 = %0s\n", pd2); // Domain tb.t1.d2.PDM1

$display("Power domain register pd3 = %0s\n", pd3); // Domain tb.t1.d2.PDM2

// Use power domain register pd1 as input argument to specify the domain// in $lps_link_power_domain_powerdown task

$lps_link_power_domain_powerdown(link_pwrdown, pd1);

end

// Execute some code when domain tb.t1.PD1 is about to be shut down.

always @(posedge link_pwrdown)

begin

DO_SOMETHING;

end

endmodule



module top (clk, rst, in1, in2, out1);

...

dff4 d1 (clk, rst, in1, out1);

dff4 d2 (clk, rst, in1, out1);

add4 a1 (in1, in2, out1);

pcm3 p1 (iso, ret, pso);

...

endmodule

module dff4 (clk, rst, in1, out1);

// Ports are specified as boundary ports in the CPF macro model

...

// Reg ff1 is specified as an instance in power domain PDM2 in the CPF macro model

reg [3:0] ff1;

endmodule



$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

Example 1

In this example, the link_register is linked to the power down state of a power domain. The full path of the power domain is specified as an argument. In this example, the power domain of interest is top.dut1.PD1.

CPF commands:

set_design top

create_power_domain -name PD1 -instances dut1 ....

link_register A register of width 1. The register will be linked to the power-down state of the power domain of interest.

[power_domain] The name of the power domain of interest.

This argument is a string constant or a register. It can be:



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.



Verilog code:

module top;

// Declare link_register

reg link_pwrdown;

dut dut1();

initial

begin

link_pwrdown = 0;

// Link register link_pwrdown to power-down state of domain top.dut1.PD1.

// Specify absolute path of power domain using a string constant.

$lps_link_power_domain_powerdown(link_pwrdown, “top.dut1.PD1”);

end

// Execute some code when top.dut1.PD1 is about to be shut down.


begin

DO_SOMETHING;

end

endmodule

Or:

module top;


reg link_pwrdown;

// Declare a register to be used as the power domain name

reg [1:32 * 8] str1 = “top.dut1.PD1”;

dut dut1();

initial

begin

link_pwrdown = 0;


// Specify absolute path of power domain using register str1.

$lps_link_power_domain_powerdown(link_pwrdown, str1);

end





DO_SOMETHING;

endmodule

Example 2

In this example, the power domain of interest is specified using a relative path. The path is specified relative to the scope from which the task is called.

module top;


reg link_pwrdown;

dut dut1();

initial

begin

link_pwrdown = 0;


// Specify relative path of power domain using a string constant.

$lps_link_power_domain_powerdown(link_pwrdown, “dut1.PD1”);

end



DO_SOMETHING;

endmodule

Or:

module top;


reg link_pwrdown;


reg [1:32 * 8] str1 = “dut1.PD1”;

...


// Specify relative path of power domain using register str1.

$lps_link_power_domain_powerdown(link_pwrdown, str1);



Example 3

In this example, the power_domain argument is not used. The power domain of interest is the one that controls instance dut1.

module dut(output reg out, input wire in);

// Declare link register

reg link_pwrdown;

initial

begin

link_pwrdown = 0;

$lps_link_power_domain_powerdown(link_pwrdown);

end


DO_SOMETHING;

endmodule

Example 4

In this example:

■ The $lps_get_power_domain task gets the power domain for instance top.dut1.inst1, and places the full path of this power domain (top.dut1.PD1) into register pd.

■ The register pd is then used as an input argument to the $lps_link_power_domain_powerdown task.

module testbench;

// Declare link register

reg link_pwrdown;

// Declare power domain register for $lps_get_power_domain

reg [1:512 * 8] pd;

initial

begin

link_pwrdown = 0;

// Place full path of power domain for instance top.dut1.inst1 into register pd.

$lps_get_power_domain(pd, top.dut1.inst1);



// Link register link_pwrdown to the power down state of the power domain.

// Use register pd as input argument to specify the domain.

$lps_link_power_domain_powerdown(link_pwrdown, pd);

end


DO_SOMETHING;

endmodule



$lps_link_power_domain_standby(<link_register>[, <power_domain>]);

Links the link_register to the standby state of the power domain of interest.

The link_register becomes 1 when the power domain is about to go into the standby state. You can then execute commands before the power domain is in standby. You cannot use any delays between the time the link_register becomes 1 and when the state change occurs.

The link_register becomes 0 when the power domain changes into another state.


Arguments

Examplemodule top;

// Declare 1-bit reg for link_register

reg link_standby;

topA t1();

link_register A register of width 1. The register will be linked to the standby state of the power domain of interest.








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



$lps_link_power_domain_state(<link_register> [,<power_domain>])

Links the link_register to the current state of the power domain of interest.

The link_register changes when the power domain changes to a different state. The valid states are:

■ ON

■ OFF

■ TRANSITION

■ STANDBY

■ UNINITIALIZED


Arguments

link_register The register that will be linked to the current state of the power domain of interest.

Because state UNINITIALIZED is 13 characters, the minimum register size is 13*8 = 104. Declare the link_register as follows:

reg [1:13*8] link_register








Example 1

CPF commands:

set_design top.t1

create_power_domain -name pdA -instances instA ....

Verilog code:

module top;

// Declare link_register to hold state of domain pdA.

reg [1:13*8] link_pdA_state;

topA t1();

initial

begin

// Link register link_pdA_state to state of domain top.t1.pdA.

// Specify absolute path of power domain using a string constant.

$lps_link_power_domain_state(link_pdA_state, "top.t1.pdA");

$display($stime, " initial pdA top state = %0s\n", link_pdA_state);

end

// Execute some code when link register link_pdA_state changes value.

always @(link_pdA_state)

begin

$display($stime, " change pdA top state = %0s\n", link_pdA_state);

DO_SOMETHING;

end

endmodule

Or:

module top;




reg [1:32*8] str1 = “top.t1.pdA”;

topA t1();



initial

begin


// Specify absolute path of power domain using register str1.

$lps_link_power_domain_state(link_pdA_state, str1);

end



DO_SOMETHING;

endmodule

Example 2

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.


topA t1();

initial

begin


// Specify relative path of power domain using a string constant.

$lps_link_power_domain_state(link_pdA_state, "t1.pdA");


end


string linkStr;


begin

$swrite(linkStr, "%0s", link_pdA_state);

if (linkStr == "TRANSITION")

DO_SOMETHING;

end

endmodule



Or:

module top;


reg link_pdA_state;


reg [1:32 * 8] str1 = “t1.pdA”;

...

// Link register link_pdA_state to state of domain t1.pdA.

// Specify relative path of power domain using register str1.

$lps_link_power_domain_state(link_pdA_state, str1);

Example 3

In this example:

■ The $lps_get_power_domain task gets the power domain for instance top.t1, and places the full path of this power domain (top.t1.pdA) into register pdReg.

■ The register pdReg is then used as an input argument to the $lps_link_power_domain_state task.

module top;

// Declare link_register.


// Declare power domain register for $lps_get_power_domain


topA t1();

initial

begin

// Place full path of power domain for instance top.t1 into register pdReg.

$lps_get_power_domain(pdReg, top.t1);

// Link register link_pdA_state to state of the power domain.

// Use register pdReg as input argument to specify the domain.

$lps_link_power_domain_state(link_pdA_state, pdReg);


end




string linkStr;


begin

$swrite(linkStr, "%0s", link_pdA_state);

if (linkStr == "TRANSITION")

DO_SOMETHING;

end

endmodule



$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

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

link_variable A real variable. The variable will be linked to the voltage of the power domain of interest.








/* Or declare a register big enough to hold the name of the power domain of interest.

Then use the register to specify the name of the power domain.


pdReg = “t1.pdA”;

$lps_link_power_domain_voltage(link_volt, pdReg); */

$display($stime, “ initial pdA top voltage = %f\n”, link_volt);

end

// Do something when the power domain has completed a voltage transition.

always @(link_volt)

$display($stime, “ change pdA top voltage = %f\n”, link_volt);

DO_SOMETHING;

endmodule



$lps_link_power_domain_gnd_voltage(<link_variable>[, <power_domain>]);

Links the link_variable to the ground voltage of the power domain of interest.

The link_variable changes when the transition to the new ground voltage value is complete.


Arguments

Example

See the example in the description of the $lps_link_power_domain_pmos_voltage task.

link_variable A real variable. The variable will be linked to the ground voltage of the power domain of interest.








$lps_link_power_domain_nmos_voltage(<link_variable>[, <power_domain>]);

Links the link_variable to the nmos bias voltage of the power domain of interest.

The link_variable changes when the transition to the new nmos bias voltage value is complete.


Arguments

Example

See the example in the description of the $lps_link_power_domain_pmos_voltage task.

link_variable A real variable. The variable will be linked to the nmos bias voltage of the power domain of interest.








$lps_link_power_domain_pmos_voltage(<link_variable>[, <power_domain>]);

Links the link_variable to the pmos bias voltage of the power domain of interest.

The link_variable changes when the transition to the new pmos bias voltage value is complete.


Arguments

Example

module top;

...

...

// Declare a real variable for the pmos bias voltage link_variable

real linkPMOS;

// Declare a real variable for the nmos bias voltage link_variable

real linkNMOS;

// Declare a real variable for the ground voltage link_variable

real linkGND;

link_variable A real variable. The variable will be linked to the pmos bias voltage of the power domain of interest.








// Declare a real variable for voltage link_variable

real link_volt;

// Declare a power domain register that will store the full path

// name of a power domain


topA t1();

initial begin

// Link variable linkPMOS to the pmos bias voltage of power domain top.t1.pdA.

$lps_link_power_domain_pmos_voltage(linkPMOS, “top.t1.pdA”);

// Link variable linkNMOS to the nmos bias voltage of power domain top.t1.pdA.

$lps_link_power_domain_nmos_voltage(linkNMOS, “top.t1.pdA”);

// Link variable linkGND to the ground voltage of power domain top.t1.pdA.

$lps_link_power_domain_gnd_voltage(linkGND, “top.t1.pdA”);

// Assign power domain name to reg pdReg

pdReg = “top.t1.pdT”;

// Link variable link_volt to the voltage of power domain top.t1.pdT.

// Use pdReg to specify the name of the power domain.

$lps_link_power_domain_voltage(link_volt, pdReg);

$display($stime, “ initial pdA top pmos voltage = %f\n”, linkPMOS);

$display($stime, “ initial pdA top nmos voltage = %f\n”, linkNMOS);

$display($stime, “ initial pdA top gnd voltage = %f\n”, linkGND);

$display($stime, “ initial pdT top voltage = %f\n”, link_volt);

end

// Do something when the power domain has completed a voltage transition.

always @(linkPMOS)

$display($stime, “ change pdA top pmos voltage = %f\n”, linkPMOS);

always @(linkNMOS)

$display($stime, “ change pdA top nmos voltage = %f\n”, linkNMOS);

always @(linkGND)

$display($stime, “ change pdA top gnd voltage = %f\n”, linkGND);



always @(link_volt)

$display($stime, “ change pdT top voltage = %f\n”, link_volt);

endmodule

module topA;

wire [5:0] data, ndata;

reg clk;

...

...

endmodule



$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

link_register The register to be linked to the nominal condition name of the power domain of interest.

The register must be large enough to hold any nominal condition name of the power domain. To hold 50 characters, the register must be defined as:

reg [1:50 * 8] link_register

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

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



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








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



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: Power domain pdA has started transitioning to nominal condition NC_08

At simulation time 0 FS: Power domain pdB has transitioned to nominal condition NC_12

At simulation time 0 FS: Power domain pdT has transitioned to nominal condition NC_12

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

0 NomCond B = NC_12

0 Active state conditions for pdT: aseT08 = 0 aseT12 = 1

0 NomCond T = NC_12


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

2 NomCond A = NC_08

At simulation time 10 NS: Power domain pdA is being powered off

At simulation time 10 NS: Power domain pdA has started transitioning to power off state

At simulation time 12 NS: Power domain pdA has finished transitioning to power off state


12 NomCond A = SHUTOFF




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


20 NomCond A = UNINITIALIZED




20 NomCond B = SHUTOFF

At simulation time 30 NS: Power domain pdB is being powered up

At simulation time 30 NS: Power domain pdB has transitioned to power on state


30 NomCond B = UNINITIALIZED




33 NomCond A = NC_12

...

...

Example 2

In this example, the $lps_get_power_domain task is used to get the power domain of an instance (top.t1.instA) and place its full path name in the power_domain_register pd. The power domain is top.t1.pdA.

$lps_get_power_domain(pd, t1.instA);

The $lps_link_power_domain_nominal_condition task then links the register array NomCond to the current nominal condition of the power domain. The power domain is specified using the value returned by $lps_get_power_domain.

$lps_link_power_domain_nominal_condition(NomCond, pd);



module top;

// Declare a register large enough to hold the full path of any power domain.

reg [1:56 * 8] pd;

// Declare a register large enough to hold the name of any nominal condition.

reg [1:25*8] NomCond;

topA t1();

initial

begin

// Get power domain of top.t1.instA

$lps_get_power_domain(pd, t1.instA);

$display(“Power domain is: %0s”, pd);

/* Link the register NomCond to the nominal condition of the powerdomain of interest.

In this example, the power domain is specified using the value returned by $lps_get_power_domain. The power domain is top.t1.pdA. */

$lps_link_power_domain_nominal_condition(NomCond, pd);

$display($stime, “ Initial nominal condition of %0s is: %0s\n”, pd, NomCond);

end

// Do something when the nominal condition of top.t1.pdA changes.

always @(NomCond)

begin

$display($stime, “ Current nominal condition of %0s is: %0s\n”, pd, NomCond);

DO_SOMETHING;

end

endmodule

module topA;

...

modA instA(clk, data);

modB instB(data, ndata);

...

endmodule

module modA (clock, num);

...

endmodule



module modB (x, y);

...

endmodule



$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

link_register The register to be linked to the power mode name of the power domain of interest.

The register must be large enough to hold any power mode name of the power domain. To hold 32 characters, the register must be defined as:

reg [1:32 * 8] link_register

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

Note: Registers larger than 256 characters may cause problems. If the power mode link register is greater than 256 characters, a warning is generated telling you to decrease the size of the register to 256 or less.








Examplemodule top;

// Declare link register large enough to hold any power mode name

reg [1:25*8] link_pm;

topA t1();

initial

begin

// Link link register to domain top.t1.pdA

$lps_link_power_domain_power_mode(link_pm, “t1.pdA”);

$display($stime, “ Initial pdA power mode = %0s\n”, link_pm);

end

always @(link_pm)

$display($stime, “ Change pdA power mode = %0s\n”, link_pm);

endmodule

module topA;

...

modA instA(clk, data);

modB instB(data, ndata);

...

endmodule

module modA (clock, num);

...

endmodule

module modB (x, y);

...

endmodule



$lps_enabled();

This function returns 1 if low-power simulation has been enabled in the design with the elaborator -lps_cpf option, and if the simulation option -lps_off is not used.

The function returns 0 if the design is not elaborated with low-power simulation enabled, or if the simulator option -lps_off is used.

Examplemodule top;

wire sc1, sc2;

test1 t1();

initial

begin

$display(“\n”);

if ($lps_enabled())

begin

$display(“LPS enabled.\n”);

[DO SOMETHING;]

[DO SOMETHING ELSE;]

end

else

$display(“LPS not enabled.\n”);

end

endmodule



$lps_get_stime();

This function returns the simulation time (a time variable) for the start of low-power simulation.

Examplemodule top;

integer i;

time LPS_stime;

wire sc1, sc2;

reg [1:4] in;

test1 t1(in[1]);

...

initial

begin

$display(“\n”);

if ($lps_enabled())

begin

$display(“LPS enabled.\n”);

end

else

$display(“LPS not enabled.\n”);

LPS_stime = $lps_get_stime();

$display(“LPS_stime = %0d\n”, LPS_stime);

end

endmodule



VHDL Procedures

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

library NCUTILS;

use NCUTILS.LPSUTILITIES.all;

The VHDL procedures are:

lps_get_power_domain (“power_domain_signal”[, “instance_path”]);

lps_link_power_domain_powerdown(“link_signal”[, power_domain]);

lps_link_power_domain_standby(“link_signal”[, power_domain]);

lps_link_power_domain_state(“link_signal”[, power_domain]);

lps_link_power_domain_voltage(“link_signal”[, power_domain]);

lps_link_power_domain_gnd_voltage(“link_signal”[, power_domain]);

lps_link_power_domain_nmos_voltage(“link_signal”[, power_domain]);

lps_link_power_domain_pmos_voltage(“link_signal”[, power_domain]);

lps_link_power_domain_nominal_condition(“link_signal” [, power_domain]);

lps_link_power_domain_power_mode(“link_signal”[, power_domain]);

lps_enabled(“signal_name”);

lps_get_stime(“signal_name”);

Note: The first argument to the VHDL procedures must be passed in by reference. This argument must be enclosed in double quotes.

For the lps_link_* procedures, the second argument is the power domain of interest. This argument is a string constant or the value of a signal of type string that holds the path name of the power domain. If you use a string constant, the argument must be enclosed in double quotes. For example:



-- Declare link signal

signal link_pwrdown : std_logic := ’0’;

...

-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx.

-- Specify absolute path of power domain using a string constant.

lps_link_power_domain_powerdown(“link_pwrdown”, “:adder1:PDEx”);

Or:


signal link_pwrdown : std_logic := '0';

-- Declare a signal of type string for the path of the power domain

signal str1 : string (512 down to 1) := ":adder1:PDEx;

-- Link signal link_pwrdown to power-down state of power domain.

-- Specify path of power domain using signal str1.

lps_link_power_domain_powerdown ("link_pwrdown", str1);



lps_get_power_domain (“power_domain_signal”[, “instance_path”]);

Gets the power domain of interest and places its full path name in the power_domain_signal. The power_domain_signal can then be used as an input argument to subsequent procedure calls.

Note: The value stored in the power_domain_signal is lost when the power domain is powered down. Because the string representing the path to the power domain is no longer available, the signal cannot be used as an argument to other procedures. It is recommended that the lps_get_power_domain procedure be always used in an always-on power domain. If the procedure is used in a switchable domain, the domain must be on when the procedure is invoked.

Arguments

“power_domain_signal” A signal of type string that will contain the full path of the power domain of interest.

The signal must be large enough to contain the full path of the power domain. For example:

signal pwrDA : string (10 downto 1);

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



Example 1

CPF commands:

set_design :

create_power_domain -name pdA -instances instA....

VHDL code:


lps_get_power_domain(“pwrDA”); -- In instance instA

lps_get_power_domain(“pwrDA”, “instA”); -- In design unit top

lps_get_power_domain(“pwrDA”, “:instA”); -- Anywhere

[“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 2

In this example:

■ Three lps_get_power_domain procedures get the power domains for instance :t1:d1, signal :t1:d2:clk (defined as a boundary port in a macro model), and :t1:d2:ff1 (declared as an instance in the macro model). The procedures place the full path of the power domains into signals pd1, pd2, and pd3.

■ The power domain signal pd1 is then used as an input argument to the lps_link_power_domain_powerdown procedure.

CPF commands:

set_cpf_version 1.1

set_macro_model dff4

create_power_domain -name PDMD -default

# Port clk is declared as a boundary port


-boundary_ports {clk rst in1 out1}

# Reg ff1 is declared as an instance in domain PDM2


-instances ff1

end_macro_model

set_design top



-instances d1 \

-shutoff_condition p1.pso \

-base_domains PDD

set_instance d2 -model dff4



end_design



VHDL code:

-- File: tb.vhd

library ieee;


use ieee.std_logic_unsigned.all;

use ieee.std_logic_textio.all;

library ncutils;

use ncutils.lpsutilities.all;

library std;

use std.textio.all;

entity tb is

end tb;

architecture sim of tb is

component top

port (...);

end component;

signal clk, rst : std_logic;

signal in1, in2, out1 : std_logic_vector (3 downto 0);

-- Declare power domain signals for lps_get_power_domain procedures

signal pd1, pd2, pd3 : string (29 downto 1);

-- Declare link signal for power down state


procedure pd is

variable vline : line;

begin

write(vline, string'("Power domain signal pd1 = " ));

write(vline, pd1);

write(vline, string'(" Power domain signal pd2 = " ));

write(vline, pd2);

write(vline, string'(" Power domain signal pd3 = " ));

write(vline, pd3);

writeline (output, vline);

end pd;



procedure pwrdown is


begin

write(vline, string'("Power domain is powering down = " ));

write(vline, pd1);


--DO_SOMETHING;

end pwrdown;

begin

t1 : top port map (clk, rst, in1, in2, out1);

-- Use power domain signal pd1 as an input argument to specify the power domain-- in lps_link_power_domain_powerdown procedure.-- This links signal link_pwrdown to the power-down state of domain :t1:PD1

lps_link_power_domain_powerdown("link_pwrdown", pd1);

-- Execute procedure pd when link signals change value.

process (pd1, pd2, pd3)

begin

pd;

end process;

-- Execute procedure pwrdown when domain :t1.PD1 is about to be shut down.

process (link_pwrdown)

begin

if link_pwrdown = '1' then

pwrdown;

end if;

end process;

process begin

clk <= '0';

...

end process;

-- Put full path of power domain for instance d1 into power domain signal pd1

lps_get_power_domain("pd1", ":t1:d1");

-- Put full path of power domain for port clk into power domain signal pd2

lps_get_power_domain("pd2", ":t1:d2:clk");



-- Put full path of power domain for register instance ff1 into power-- domain signal pd3

lps_get_power_domain("pd3", ":t1:d2:ff1");

rst <= '1',

'0' after 5 ns;

...

process begin

in2 <= "0000";

...

end process;

process begin

wait for 1200 ns;

...

end process;

end sim;

-- File: top.vhd

library ieee;


entity top is

port (...);

end top;

architecture rtl of top is

component dff4

port (clk, rst : in std_logic;

in1 : in std_logic_vector (3 downto 0);

out1 : out std_logic_vector (3 downto 0)

);

end component;

component add4

port (...);

end component;



component pcm3

port (...);

end component;

signal tmp1, tmp2 : std_logic_vector (3 downto 0);

signal iso, ret, pso : std_logic;

begin

d1 : dff4 port map (clk, rst, in1, tmp1);

d2 : dff4 port map (clk, rst, in1, tmp2);

a1 : add4 port map (tmp1, tmp2, out1);

p1 : pcm3 port map (iso, ret, pso);

end rtl;

-- File dff4.vhd

library ieee;


entity dff4 is

-- These ports are declared as boundary ports in the CPF macro model

port (clk, rst : in std_logic;

in1 : in std_logic_vector (3 downto 0);

out1 : out std_logic_vector (3 downto 0)

);

end dff4;

architecture rtl of dff4 is

-- ff1 is declared as an instance in power domain PDM2 in the CPF macro model.

signal ff1 : std_logic_vector (3 downto 0);

begin

...

...

end rtl;



lps_link_power_domain_powerdown(“link_signal”[, power_domain]);

Links the link_signal to the power-down state of the power domain of interest.

The link_signal becomes 1 when the power domain is about to be powered down. You can then execute commands before corruption occurs. You cannot use any delays between the time the link_signal becomes 1 and when corruption occurs.

The link_signal becomes 0 when the power domain is powered up.

If the link_signal exists in a switchable power domain, it is corrupted when the domain is powered down.

Arguments

“link_signal” A signal of type std_logic or std_ulogic of width 1. The signal will be linked to the power-down state of the power domain of interest.


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


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

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 1

In this example, the link_signal is linked to the power-down state of a power domain. The full path of the power domain is specified as an argument, so the procedure can be in the architecture for any entity.

In this example, the power domain of interest is :adder1:PDEx.

CPF commands:

set design :adder1

create_power_domain -name PDEx -instances Add0 ...

VHDL code:

library NCUTILS;


library ieee;


use ieee.std_logic_textio.all;

library std;

use std.textio.all;

entity TOP is

end entity TOP;

architecture RTL of TOP is

..




begin

DO_SOMETHING;

end pwrdown;

begin

adder1 : entity WORK.MID port map (clk);

-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx.

-- Specify absolute path of power domain using a string constant.

lps_link_power_domain_powerdown(“link_pwrdown”, “:adder1:PDEx”);




begin

if link_pwrdown = ’1’ then

pwrdown;

end if;

end process;

...


Or:



-- Declare a signal of type string for the path of the power domain

signal str1 : string (512 down to 1) := ":adder1:PDEx;

-- Link signal link_pwrdown to power-down state of power domain.

-- Specify path of power domain using signal str1.

lps_link_power_domain_powerdown ("link_pwrdown", str1);

Example 2

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 procedure is called.

-- Current scope is :adder1

entity MID is

port(clk : std_logic := ’0’);

end entity MID;

architecture RTL of MID is

-- Declare link_signal



begin

DO_SOMETHING;

end pwrdown;



begin

-- Link signal link_pwrdown to power-down state of domain :adder1:PDEx

-- Specify relative path name of power domain.

lps_link_power_domain_powerdown(“link_pwrdown”, “PDEx”);


begin


pwrdown;

end if;

end process;

Add0 : entity WORK.BOT port map (clk);


Example 3

In this example:

■ The lps_get_power_domain procedure gets the power domain for instance :blk_inst1, and places the full path of this power domain (:dut1:PD1) into signal pd.

■ The signal pd is then used as an input argument to the lps_link_power_domain_powerdown procedure.

CPF commands:

set_cpf_version 1.1

set_design :

create_power_domain -name pdA instances blk_inst1 .....

VHDL code:

-- Declare power domain signal for lps_get_power_domain

signal pd : string (512 downto 1);



-- Get full path of domain that controls :blk_inst1

lps_get_power_domain (“pd”, “:blk_inst1”);

-- Use power domain signal in lps_link_power_domain_powerdown procedure

lps_link_power_domain_powerdown(“link_pwrdown”, pd);

...




begin

DO_SOMETHING;

end pwrdown;


begin


pwrdown;

end if;

end process;



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.


Arguments

Examplelibrary NCUTILS;


...

entity top is

end top;

“link_signal” A signal of type std_logic or std_ulogic of width 1. The signal will be linked to the standby state of the power domain of interest.


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:






architecture top_rtl of top is

...

signal clk : std_logic;

signal data : std_logic_vector (5 downto 0);

...

-- Declare link signal of type std_logic

signal link_standby : std_logic := ’0’;

procedure standby is

begin

DO_SOMETHING;

end standby;

begin

process (link_standby)

begin

-- Execute procedure standby when link_standby is 1 (i.e., when domain-- :pdA is about to enter standby mode)

if link_standby = ’1’ then

standby;

end if;

end process;

instA : modA port map(...);

instB : modB port map(...);

PowerDown : process

begin

-- Link link signal to standby state of power domain :pdA

lps_link_power_domain_standby(“link_standby”, “:pdA”);

mte <= “00000”;

pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’;

wait for 99 ns;

mte <= “00001”;

...

end Process;

end top_rtl;



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


Arguments

“link_signal” A signal of type string that will be linked to the current state of the power domain of interest.

Because state UNINITIALIZED is 13 characters, the minimum width of the link_signal is 13. Declare the link_signal as follows:

signal link_sig : string (13 downto 1);










...

entity top is

end top;


component modA is

port (...);

end component;

component modB is

port (...);

end component;



...

-- Declare link signals for current state of power domains :pdA and :pdB

signal link_pdA_state : string (13 downto 1):="1111111111111";

signal link_pdB_state : string (13 downto 1):="1111111111111";

procedure expect is


begin

write(vline, string'("State of domain pdA = " ));

write(vline, link_pdA_state);

write(vline, string'(" State of domain pdB = " ));

write(vline, link_pdB_state);


end expect;



begin

-- Execute procedure “expect” when a link signal changes value.

process (link_pdA_state, link_pdB_state)

begin

expect;

end process;

instA : modA port map(...);

instB : modB port map(...);

process

begin

clk <= ‘0’;

wait for 5 ns;

clk <= ‘1’;

wait for 5 ns;

end process;

PowerDown : process

begin

-- Link link signal link_pdA_state to the current state of power domain :pdA

lps_link_power_domain_state("link_pdA_state", ":pdA");

-- Link link signal link_pdB_state to the current state of power domain :pdB

lps_link_power_domain_state("link_pdB_state", ":pdB");

mte <= “00000”;

pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’;

wait for 99 ns;

mte <= “00001”;

wait;

end Process;

end top_rtl;



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.


Arguments



...

entity top is

end top;


...



“link_signal” The name or full path name of a signal of type real. The signal will be linked to the voltage of the power domain of interest.








...

-- Declare link signal of type real

signal link_volt_pdA : real := -1.0;

procedure volt is

begin

DO_SOMETHING;

end volt;

begin

process (link_volt_pdA)

-- Execute procedure volt when link_volt_pdA changes value (i.e., when-- domain :pdA has transitioned to a new voltage value)

begin

volt;

end process;

instA : modA port map(clock => clk, num => data);

instB : modB port map(x => data, y => ndata);

PowerDown : process

begin

-- Link link signal to voltage of power domain :pdA

lps_link_power_domain_voltage(“link_volt_pdA”, “:pdA”);

mte <= “00000”;

pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’;

wait for 99 ns;

mte <= “00001”;

...

wait;

end Process;

end top_rtl;



lps_link_power_domain_gnd_voltage(“link_signal”[, power_domain]);

Links the link_signal to the ground voltage of the power domain of interest.

The link_signal changes when the transition to the new ground voltage value is complete.


Arguments

Example

See the example in the description of the lps_link_power_domain_pmos_voltage procedure.

“link_signal” The name or full path name of a signal of type real. The signal will be linked to the ground voltage of the power domain of interest.








lps_link_power_domain_nmos_voltage(“link_signal”[, power_domain]);

Links the link_signal to the nmos bias voltage of the power domain of interest.

The link_signal changes when the transition to the new nmos bias voltage value is complete.


Arguments

Example

See the example in the description of the lps_link_power_domain_pmos_voltage procedure.

“link_signal” The name or full path name of a signal of type real. The signal will be linked to the nmos bias voltage of the power domain of interest.








lps_link_power_domain_pmos_voltage(“link_signal”[, power_domain]);

Links the link_signal to the pmos bias voltage of the power domain of interest.

The link_signal changes when the transition to the new pmos bias voltage value is complete.


Arguments



...

entity top is

end top;

“link_signal” The name or full path name of a signal of type real. The signal will be linked to the pmos bias voltage of the power domain of interest.









component modA is

port (clock : in std_logic;

num : out std_logic_vector (5 downto 0));

end component;

component modB is

port (x : in std_logic_vector (5 downto 0);

y : out std_logic_vector (5 downto 0));

end component;



...

-- Declare link signals of type real

signal link_volt_pdA : real := -1.0;

signal linkPMOS : real := -1.0;

signal linkNMOS : real := -1.0;

signal linkGND : real := -1.0;

signal link_volt_pdB : real := -1.0;

procedure expect is


begin

write(vline, string’(“link_volt_pdA = “ ));

write(vline, link_volt_pdA);

write(vline, string’(“ linkPMOS = “ ));

write(vline, linkPMOS);

write(vline, string’(“ linkNMOS = “ ));

write(vline, linkNMOS);

write(vline, string’(“ linkGND = “ ));

write(vline, linkGND);

write(vline, string’(“ link_volt_pdB = “ ));

write(vline, link_volt_pdB);


end expect;

begin



process (link_volt_pdA, linkPMOS, linkNMOS, linkGND, link_volt_pdB)

-- Execute procedure “expect” when a link signal changes value.

begin

expect;

end process;



process

begin

clk <= ‘0’;

wait for 5 ns;

clk <= ‘1’;

wait for 5 ns;

end process;

PowerDown : process

begin

-- Link link signal link_volt_pdA to the voltage of power domain :pdA

lps_link_power_domain_voltage(“link_volt_pdA”, “:pdA”);

-- Link link signal linkPMOS to the pmos bias voltage of power domain :pdA

lps_link_power_domain_pmos_voltage(“linkPMOS”, “:pdA”);

-- Link link signal linkNMOS to the nmos bias voltage of power domain :pdA

lps_link_power_domain_nmos_voltage(“linkNMOS”, “:pdA”);

-- Link link signal linkGND to the ground voltage of power domain :pdA

lps_link_power_domain_gnd_voltage(“linkGND”, “:pdA”);

-- Link link signal link_volt_pdB to the voltage of power domain :pdB

lps_link_power_domain_voltage(“link_volt_pdB”, “:pdB”);

mte <= “00000”;

pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’;

wait for 99 ns;

mte <= “00001”;

wait;

end Process;

end top_rtl;



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

“link_signal” A signal of type string. The signal will be linked to the nominal condition of the power domain of interest.

The signal must be large enough to hold any nominal condition name of the power domain. To hold 512 characters, the register must be defined as:


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










...

entity top is

end top;


...



...

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



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



wait for 99 ns;

...

end Process;

end top_rtl;



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



...

“link_signal” A signal of type string. The signal will be linked to the power mode of the power domain of interest.

The signal must be large enough to hold any power mode name of the power domain. To hold 512 characters, the signal must be defined as:


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








entity top is

end top;


...



...

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



PowerDown : process

begin

-- Link link signal to power mode of power domain :pdA

lps_link_power_domain_power_mode(“link_pmA”, “:pdA”);

mte <= “00000”;



pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’;

wait for 99 ns;

...

end Process;

end top_rtl;



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



...

entity tb is end;

architecture testtb of tb is

...

signal tclk : std_logic;

signal in1 : std_logic_vector(3 downto 0);

...

-- Signal to hold full path of power domain pdA


-- Signal to hold full path of power domain pdB

signal pwrDB : string (10 downto 1);

-- Signal to hold power-down state of domain pdA

signal link_pwrdownA : std_logic := ‘0’;

-- Signal to hold power-down state of domain pdB

signal link_pwrdownB : std_logic := ‘0’;

-- Signal for lps_enabled procedure

signal enabled : integer := 0;


begin

DO_SOMETHING;

end pwrdown;

“signal_name” A signal of type integer.



-- Link the power-down states of domains pdA and pdB to link signals

procedure enable_pd is

begin

-- Get full path of power domain that controls instance blk_inst1

lps_get_power_domain(“pwrDA”, “blk_inst1”); --

-- Link signal link_pwrdownA to power-down state of power domain.

-- Use output of lps_get_power_domain as argument to-- lps_link_power_domain_powerdown procedure

lps_link_power_domain_powerdown(“link_pwrdownA”, pwrDA);

-- Get full path of power domain that controls instance blk_inst2.

lps_get_power_domain(“pwrDB”, “blk_inst2”);

-- Link signal link_pwrdownB to power-down state of power domain.

-- Use output of lps_get_power_domain as argument to-- lps_link_power_domain_powerdown procedure

lps_link_power_domain_powerdown(“link_pwrdownB”, pwrDB);

end enable_pd;

begin

-- If low-power simulation is enabled, execute procedure enable_pd

process (enabled)

begin

if enabled <= 1 then

enable_pd;

end if;

end process;

-- If signal link_pwrdownA is 1 or link_pwrdownB is 1 (i.e., if domain pdA or-- domain pdB is about to be powered down), execute procedure pwrdown

process (link_pwrdownA, link_pwrdownB)

begin

if link_pwrdownA = ‘1’ OR link_pwrdownB = ‘1’ then

pwrdown;

end if;

end process;

blk_inst1 : blk port map (...);

blk_inst2 : blk port map (...);

...



PowerDown : process

begin

-- Check to see if low-power simulation is enabled

lps_enabled(“enabled”);

mte <= “000000”;

pseA <= ‘0’; pseB <= ‘0’;

aseA12 <= ‘1’; aseB12 <= ‘1’; aseT12 <= ‘1’; aseB05 <= ‘0’;

wait for 99 ns;

...

end Process;

...

end testtb;



lps_get_stime(“signal_name”);

Assigns the low-power simulation start time to the signal.

Arguments

Exampleentity TOP is

end entity TOP;

architecture RTL of TOP is

-- Declare signal of type time

signal lp_start_time : time := 0 ns;

...

procedure print_stime is


begin

write(vline, string’(“lp_start_time = “)); write(vline, lp_start_time);

wrieline(output, vline);

end print_stime;

begin

-- Assign low-power simulation start time to signal lp_start_time

lps_get_stime(“lp_start_time”);

print_stime;


“signal_name” A signal of type time.



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

AAssertion Browser 229Assertions

automatic generation of 196viewing 229

BBack-to-back isolation 117Boundary ports

specifying with -boundary_ports 63-boundary_ports 63

CCells

excluding from state retention 173Constants in shutoff control expression 70Continuous assignments

treating as buffers 172Control signals

generating a coverage model for 265

verifying correct sequence 196Corruption

disabling with set_sim_control 33of top-level ports 73of VHDL user-defined enumerated

types 75Coverage model

automatic generation of 265CPF file

specifying with -lps_cpf 174

DDebugging

infinite loops 256Tcl commands 238with SimVision 215

FFeedthrough wires 41

IIdentifiers in CPF

converting to upper case 191Infinite loops

debugging 256Initial blocks

replaying on powerup 30Isolation

back-to-back 117Isolation information

logging 179

LLog file

specifying a name for 182Logging 192

isolation information 179output of -lps_verbose 181



-lps_alt_srr 172-lps_assign_ft_buf 172-lps_blackboxmm 173-lps_cellrtn_off 173-lps_cpf 174-lps_dtrn_min 174lps_enabled 341-lps_enum_rand_corrupt 175-lps_enum_right 176lps_get_power_domain 311lps_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 181lps_link_power_domain_gnd_voltage 330lps_link_power_domain_nmos_voltage 33

1lps_link_power_domain_nominal_condition

335lps_link_power_domain_pmos_voltage 33

2lps_link_power_domain_power_mode 338lps_link_power_domain_powerdown 318lps_link_power_domain_standby 323lps_link_power_domain_state 325lps_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

-lps_vplan 196

MMacro models 151

black box and gray box 151treating as black box 173

NNon-volatile memory

modeling 33

PPort isolation

turning off 179Power mode simulation

controlling 185suppressing informational

messages 189Power sidebar 215

in Design Browser 219in Schematic Tracer 223in Source Browser 220in Waveform window 220opening 215

Power-aware modeling 271Verilog 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



91VHDL procedures 309

lps_enabled 341lps_get_power_domain 311lps_get_stime 344lps_link_power_domain_gnd_voltage

330lps_link_power_domain_nmos_volta

ge 331lps_link_power_domain_nominal_co

ndition 335lps_link_power_domain_pmos_volta

ge 332lps_link_power_domain_power_mod

e 338lps_link_power_domain_powerdown

318lps_link_power_domain_standby 3

23lps_link_power_domain_state 325lps_link_power_domain_voltage 32

8

Sset_design command

-testbench option 26set_sim_control command 29

disabling corruption 33replaying initial blocks 30

Shutoff control expressionspecifying a constant 70

Signalstracing 225

Simulation-time controlenabling 188

SimVision 215Standby mode

input violation messages 190Start time

specifying with -lps_stime 190State loss

and forced signals 81turning off 191

State retention 82excluding cells from 173selecting targeted registers or

instances 82specifying control conditions 86turning off 188

with save or restore preconditions 89with separate save and restore

controls 88with single retention control 86

TTcl commands

for low power 238-testbench option 26Top-level ports

corruption of 73Tracing signals 225

VVHDL enumerated types

corruption of 75VPlan

automatic generation of 196




Power Forward Ug

Documents