lowpower ref

Encounter® Conformal® Low Power Extended CheckingReference Manual

Product Version 10.1October 2010

© 1997– 2010 Cadence Design Systems, Inc. All rights reserved.Printed in the United States of America.

Cadence Design Systems, Inc., 2655 Seely Avenue, San Jose, CA 95134, USA

Trademarks: Trademarks and service marks of Cadence Design Systems, Inc. (Cadence) 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.

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.

All other trademarks are the property of their respective holders.

Restricted Print Permission: This publication is protected by copyright and any unauthorized use of this publication may violate copyright, trademark, and other laws. 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. This statement grants you permission to print one (1) hard copy of this publication subject to the following conditions:

1. The publication may be used solely for personal, informational, and noncommercial purposes;2. The publication may not be modified in any way;3. Any copy of the publication or portion thereof must include all original copyright, trademark, and other

proprietary notices and this permission statement; and4. Cadence reserves the right to revoke this authorization at any time, and any such use shall be

discontinued immediately upon written notice from Cadence.

Patents: Cadence Product Encounter™ Extended Checks software described in this document, is protected by U.S. Patent [6,842,884], [6,487,704], [7,735,035],[7,669,165], [7,620,918], [7,620,919], and [7,627,842].

Disclaimer: Information in this publication is subject to change without notice and does not represent a commitment on the part of Cadence. The information contained herein is the proprietary and confidential information of Cadence or its licensors, and is supplied subject to, and may be used only by Cadence’s customer in accordance with, a written agreement between Cadence and its customer. 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.

Encounter Conformal Low Power Extended Checking Reference Manual

Contents

1About This Manual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2Low Power Command Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Using UNIX Commands with Conformal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25ADD ALWAYS_ON CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27ADD CELL PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28ADD CLAMP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29ADD DECAP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31ADD DOMAIN MAPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32ADD EQUIVALENT PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33ADD GROUND PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35ADD GROUND SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37ADD ISOLATION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39ADD ISOLATION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42ADD LEVEL SHIFTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45ADD LOWPOWER FILTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48ADD OPEN_SOURCE PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49ADD PATH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50ADD POWER ASSOCIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52ADD POWER CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54ADD POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56ADD POWER_GROUND PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59ADD POWER MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60ADD POWER PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

October 2010 3 Product Version 10.1


ADD POWER SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64ADD RETENTION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66ADD RETENTION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68ADD SWITCH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70ANALYZE INSTANCE CONNECTIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72ANALYZE LIBRARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73ANALYZE POWER ASSOCIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74ANALYZE POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75COMMIT POWER INTENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76DELETE ALWAYS_ON CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77DELETE CLAMP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78DELETE DECAP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79DELETE DOMAIN MAPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80DELETE GROUND PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81DELETE GROUND SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82DELETE ISOLATION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83DELETE ISOLATION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84DELETE LOWPOWER FILTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85DELETE LEVEL SHIFTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86DELETE PATH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87DELETE POWER ASSOCIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88DELETE POWER CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89DELETE POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91DELETE POWER_GROUND PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92DELETE POWER MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93DELETE POWER PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94DELETE POWER SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95DELETE RETENTION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96DELETE RETENTION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97DELETE SWITCH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98DIAGNOSE POWER CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99READ MACRO POWER_INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100READ POWER INTENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101RENAME GROUND DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104RENAME POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105REPORT ALWAYS_ON CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106



REPORT CLAMP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107REPORT CPF LOGIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108REPORT DECAP CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109REPORT DOMAIN MAPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110REPORT EQUIVALENT PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111REPORT GROUND PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112REPORT GROUND SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113REPORT ISOLATION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114REPORT ISOLATION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115REPORT LOWPOWER FILTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116REPORT LEVEL SHIFTER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117REPORT MACRO POWER_INFORMATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118REPORT OPEN_SOURCE PINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119REPORT PATH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120REPORT PIN DRIVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121REPORT PIN LOAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123REPORT POWER ASSOCIATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125REPORT POWER CHECK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127REPORT POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129REPORT POWER_GROUND PORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131REPORT POWER MODE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132REPORT POWER PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133REPORT POWER SWITCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134REPORT RETENTION CELL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135REPORT RETENTION RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136REPORT SWITCH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137SET LOWPOWER OPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138UPDATE POWER DOMAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145VALIDATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147VALIDATE PATH RULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148VALIDATE TRANSISTOR STRUCTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149WRITE POWER_GROUND PORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151WRITE POWER INTENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152



3Low Power Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Introduction to Low Power Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157PDM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159PDM1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160PDM1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161PDM2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162PDM2a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163PDM2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164PDM2c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166PDM3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167PDM3a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168PDM4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169PDM4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170PDM4b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171PDM4c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172PDM4d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173PDM4e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174PDM4f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175PDM5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176PDM6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177PDM7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178PDM7a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179PDM7b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180PDM7c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181PDM8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182PDM8a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183PDM8b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184PDM8c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185PDM_BUF1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186PDM_BUF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187PDM_BUF3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Power Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189PSW1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190



PSW1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191PSW2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192PSW3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193PSW4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194PSW4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195PSW5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196PSW6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197PSW7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198PSW7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199PSW7.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200PSW7.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201PSW7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202PSW7.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203PSW7.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205PSWRULE1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206PSWRULE1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207PSWRULE1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208PSWRULE1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209PSWRULE1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210PSWRULE1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211PSWRULE1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Ground Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213GSW1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214GSW1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215GSW4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216GSW6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217GSW7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218GSW7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219GSW7.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220GSW7.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221GSW7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222GSW7.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223GSW7.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225GSWRULE1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226GSWRULE1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227GSWRULE1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228



GSWRULE1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229GSWRULE1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230GSWRULE1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232ISO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234ISO1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235ISO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236ISO3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237ISO3.1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239ISO3.1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240ISO3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242ISO3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244ISO3.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245ISO4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246ISO4a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247ISO4b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248ISO4c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249ISO4d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250ISO4e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251ISO4f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252ISO5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253ISO5.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254ISO5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255ISO6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256ISO6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257ISO6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258ISO6.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259ISO6.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260ISO6.5a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261ISO6.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262ISO7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263ISO7a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264ISO7b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265ISO8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266ISO9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267ISO10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268



ISO11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269ISO12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270ISO14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271ISO_BUF1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272ISO_BUF2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273ISORULE1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274ISORULE1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275ISORULE1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276ISORULE1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277ISORULE1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278ISORULE1.5a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280ISORULE1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281ISORULE1.6a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282ISORULE1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283ISORULE1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285ISORULE1.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286ISORULE1.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287ISORULE1.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Always-on Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289AON1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290AON2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292AON3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294AON3a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295AON4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296Retention Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297RET1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298RET1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299RET2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300RET2a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301RET3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302RET4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303RET5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304RET6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305RET7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306RET7.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307RETRULE1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308



RETRULE1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309RETRULE1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310RETRULE1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311RETRULE1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312RETRULE1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313RETRULE1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314RETRULE1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315Level Shifter Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316LSH1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317LSH1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318LSH1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319LSH1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320LSH2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321LSH2a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322LSH2b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323LSH2c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324LSH2d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325LSH2e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326LSH3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327LSH4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328LSH4.1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330LSH4.1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331LSH4.1c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332LSH4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334LSH4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335LSH5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337LSH6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338LSH7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339LSH8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340LSH9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341Structural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342CLP_STRC1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343CLP_STRC1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344CLP_STRC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345STRUCT1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346Decoupled Capacitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347



DECAP1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348DECAP1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Path Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350PATHRULE1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351PATHRULE1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352PATHRULE1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Clamp Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354CLAMP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355CLAMP1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356CLAMP2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357Circuit Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358CIR1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359CIR1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360CIR2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361CIR3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362CIR4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363CIR7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364CIR8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366SPICE Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367SPI1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368SPI2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370SPI3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371SPI4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373SPI5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374Macro Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376MACRO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377MACRO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378MACRO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379MACRO4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380Low Power Cell Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381LPC09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382LPC10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383LPC11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384LPC12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385LPC13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386LPC14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387



4Common Power Format Rule Checks. . . . . . . . . . . . . . . . . . . . . . . . . 389

Introduction to Common Power Format Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390CPF Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391CPF_DES1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392CPF_DES2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393CPF_DES4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394CPF_DES5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396CPF_DES7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397CPF_DES8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398CPF Ground Switched Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399CPF_GD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400CPF_GD3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401CPF Hierarchical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402CPF_HIER_MAP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403CPF_HIER_MAP4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404CPF_HIER_MAP5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405CPF_HIER_MAP6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406CPF_HIER_MAP6a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407CPF_HIER_MAP7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408CPF_HIER_MAP8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409CPF_HIER_MAP8a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410CPF_HIER_MAP9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411CPF_HIER_MAP10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412CPF_HIER_MAP11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413CPF_HIER_MAP12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414CPF_HIER_MAP13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415CPF_HIER_MAP14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416CPF_HIER_MODE1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417CPF_HIER_MODE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419CPF_HIER_MODE3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420CPF_HIER_CHK6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422CPF_HIER_CHK7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423CPF Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424CPF_ISO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426



CPF_ISO1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427CPF_ISO1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428CPF_ISO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429CPF_ISO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430CPF_ISO4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431CPF_ISO5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432CPF_ISO6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433CPF_ISO7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434CPF_ISO8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435CPF_ISO13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436CPF_ISO13a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437CPF_ISO15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438CPF_ISO17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440CPF_ISO18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441CPF_ISO19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442CPF_ISO20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443CPF_ISO21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444CPF_ISO22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445CPF_ISO23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446CPF_ISO24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447CPF_ISO25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448CPF_ISO26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449CPF_ISO27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450CPF_ISO28 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451CPF_ISO29 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452CPF_ISO30 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453CPF_ISO32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454CPF_ISO33 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455CPF_ISO34 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456CPF_ISO35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457CPF_ISO37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458CPF_ISO39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459CPF_ISO40 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460CPF_ISO41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461CPF Level Shifter Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462CPF_LS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463



CPF_LS1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464CPF_LS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465CPF_LS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466CPF_LS4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468CPF_LS5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469CPF_LS7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470CPF_LS9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471CPF_LS10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472CPF_LS12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473CPF_LS13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474CPF_LS14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475CPF_LS15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476CPF_LS18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477CPF_LS19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478CPF_LS21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479CPF_LS22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480CPF_LS23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481CPF_LS24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482CPF Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483CPF_LIB1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484CPF_LIB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485CPF_LIB3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486CPF_LIB3a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488CPF_LIB4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489CPF_LIB5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491CPF_LIB6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492CPF_LIB7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494CPF_LIB8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496CPF_LIB9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498CPF_LIB10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500CPF_LIB11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502CPF_LIB12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503CPF_LIB13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505CPF_LIB14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506CPF_LIB15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507CPF_LIB16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509



CPF_LIB17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510CPF_LIB18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511CPF_LIB19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512CPF_LIB20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513CPF_LIB21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514CPF_LIB21a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515CPF_LIB22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516CPF Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517CPF_MACRO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518CPF_MACRO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519CPF_MACRO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520CPF_MACRO4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521CPF_MACRO5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522CPF_MACRO6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523CPF_MACRO7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524CPF_MACRO8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526CPF_MACRO9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527CPF_MACRO10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528CPF_MACRO11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529CPF_MACRO12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530CPF_MACRO15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531CPF_MACRO16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532CPF_MACRO17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533CPF Power and Ground Nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534CPF_PGN1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535CPF_PGN2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536CPF_PGN3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537CPF_PGN4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539CPF_PGN5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540CPF_PGN11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541CPF_PGN13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542CPF Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543CPF_PD1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544CPF_PD2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545CPF_PD3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546CPF_PD4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547



CPF_PD7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548CPF_PD8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549CPF_PD9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551CPF_PD10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552CPF_PD11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553CPF_PD12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554CPF_PD12a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555CPF_PD13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556CPF_PD14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557CPF_PD15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558CPF Power Shut Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559CPF_PSO1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560CPF_PSO1a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561CPF_PSO1b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562CPF_PSO2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563CPF_PSO3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564CPF_PSO4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566CPF_PSO5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567CPF_PSO6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568CPF Power Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569CPF_PSW3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570CPF_PSW4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571CPF_PSW5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572CPF_PSW6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573CPF_PSW7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574CPF Retention Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575CPF_RET1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576CPF_RET2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577CPF_RET3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578CPF_RET5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579CPF_RET6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580CPF_RET7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581CPF_RET8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582CPF_RET9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583CPF_RET10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584CPF_RET11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585



CPF_RET12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586CPF_RET13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587CPF_RET14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588CPF_RET21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589CPF_RET22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590CPF_RET23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591CPF Power Mode Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592CPF_PM1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593CPF Gen Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594CPF_GEN1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595CPF_GEN2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596



1About This Manual

This manual documents commands and low power rule checking messages for the Encounter® Conformal® Low Power software.

Audience

This manual is written for experienced designers of digital integrated circuits who must be familiar with RTL, synthesis, and design verification; as well as having a solid understanding of UNIX and Tcl/Tk programming.

Related Documents

For more information about the Conformal family of products, see the following documents. You can access these and other Cadence documents with the CDSDoc online documentation system. For a complete list of documents provided with this release, see the CDSDoc library.

■ Encounter Conformal Equivalence Checking User Guide

Describes how to install, configure, and use Conformal to verify RTL, gate, or transistor-level designs.


../Conformal_User/Conformal_UserTOC.html#firstpage

Encounter Conformal Low Power Extended Checking Reference ManualAbout This Manual

Conventions

Convention Definition

Bold Case Indicates the command name.

UPPERCASE Indicates the required minimum character entry.

< > Indicates required arguments. Do not type the angle brackets.

[ ] Indicates optional arguments. Do not type the square brackets.

| Indicates a choice among alternatives. Do not type the vertical bar.

\ The backslash character (\) at the end of a line indicates that the command you are typing continues on the next line.

... Indicates multiple entries of an argument.

* Indicates that the entry can use the wildcard (*) to represent zero or more characters.



2Low Power Command Reference

This chapter describes the Conformal Low Power commands. The commands are presented in alphabetical order.

This chapter also includes the following sections:

■ Command Syntax on page 22

■ Wildcards on page 22

■ Using UNIX Commands with Conformal on page 25


Encounter Conformal Low Power Extended Checking Reference ManualLow Power Command Reference

Command Syntax

■ Conformal commands are not case sensitive.

■ For every Conformal ADD command, there are corresponding DELETE and REPORT commands. For example:

ADD ISOLATION CELL

DELETE ISOLATION CELL

REPORT ISOLATION CELL

■ Conformal commands adhere to the “3-2-1” rule, which reduces the number of characters you must type.

❑ 3: Type the leading three characters of the first term.

❑ 2: Then type the leading two characters of the second term.

❑ 1: End with the leading character of the third term.

In some cases, you must use more characters to resolve ambiguity. In this manual, the minimal sets of characters you must type are shown as uppercase letters in the syntax.

When you use the 3-2-1 rule in conjunction with the syntax guide to resolve any possible ambiguity, you reduce the number of characters in a command, as the following example shows:

REPort ISolation Rule

becomes

rep is r

Wildcards

On an as-needed basis, Cadence adds wildcard pattern-matching support to Conformal commands. The syntax convention that alerts you to wildcard support is the asterisk (*).

If you use a pattern where a filename or design object is expected, Conformal Low Power expands the pattern using the same conventions as in the UNIX shell.

■ Triggering pattern matching for filenames

To trigger pattern matching for filenames, a string must include at least one asterisk (*), question mark (?), or a pair of square brackets ( [ ] ).



■ Triggering pattern matching for design objects

To trigger pattern matching for design objects, a string must include at least one asterisk (*) or question mark (?).

In arguments that are considered patterns, the following characters have special meaning: ̂ , {, }, [, ], ?, *. The dash (-) also has special meaning when it falls between square brackets.

Note: When you use wildcards for design objects, a wildcard can match a string that includes the hierarchical delimiter (/). For example, the pattern *[10] matches the design object a/b/c[10].

When you use wildcards for filenames, every wildcard applies to part of a single directory or filename (this convention is the normal UNIX convention). For example, the pattern *.v does not match the filename a/b/c.v.

Special Characters for Filename and Design Object Pattern-Matching

Wildcard Character Definition Example

? Match any single character. a?c matches:

aac, abc, a4c, a?c

* Match any (possibly empty) string. a*c matches the following:

ac, abc, a*c



[ ]

That is, “[” followed by characters and “]”

Match any single character listed between the square brackets: “[” and “]”.

If the first character is “^”, Conformal Low Power matches any single character not listed between the brackets.

If the list shown between the brackets includes x-y, Conformal Low Power matches all characters in the range x–y.

To match square brackets, you must include the escape character immediately preceding the square bracket.

To be matched, the characters “-” and “]” must appear first in the list (possibly after ^).

Note: For design objects, recall that a string triggers pattern matching with an asterisk or question mark. In those cases, this convention applies.

For filenames:

a[145] matches the following:

a1a4a5

For design objects:

a*[145] matches the following:

ab1a34at5

a*\[145\] matches the following:

ab[145]a3[145]at[145]

^ At the beginning of the pattern, the character “^” negates the result of the match:

^a* matches any name that does not begin with a.

\ Matches only the character that follows the “\” character.

a\[10] matches the following:

a[10]

But it does not match:

a1a0





Using UNIX Commands with Conformal

To execute a UNIX command from within the tools or a command script, start the line with an exclamation point “!” or with the SYSTEM command. When you execute commands in this way, they display to the standard output, and are recorded to a log file, if one is active.

Using the -all Option

This option applies within the given defaults. For example, the syntax for this example command is as follows:

REPort ISolation Cell[-ALL | <name*>...][-SUMmary | -VERbose [-NOINStance | -INStance]]

In the above syntax, -summary is a default. Therefore, if you type the command with the -all option, but no other option, this command outputs a reports the in the Summary format.

{p1,p2,…} Matches any string matched by any of the sub-patterns listed.

design/{top,sub{5,11}}/*.v matches the following:

design/top/a.vdesign/sub5/b.vdesign/sub11/c.v

Braces can nest.a/{d{e,f},g{h,i}}_0 matches the following:

a/de_0a/df_0a/gh_0a/gi_0





Saving the Command’s Output to a File

To save the command’s output to a file, Cadence recommends using the command line > operator. This works for all Conformal commands.

For example, to save the default output of the REPORT POWER DOMAIN command to a file named pd.out, you would run the following:

report power domain> pd.out

You can also use the >> operator to append output text to an existing file.

Note: Although some commands include a -file <filename> type option to save the command’s output to a file, Cadence recommends using the command line > operator.



ADD ALWAYS_ON CELLADD ALways_on Cell

<module_name> <-ALWAYS_on_power_pin <power_pin> [-ALWAYS_ON_Ground_pin <ground_pin>]

| -ALWAYS_ON_Ground_pin <ground_pin> [-ALWAYS_on_power_pin <power_pin>]>-ACTIVE_input <pin>(Setup Mode)

Defines a special cell as an always-on cell. The always on cell should have its power and ground connected to always on power and ground, such that even when it is placed in an OFF domain, it receives constant power and ground.

In physical netlists, the power domain of the always-on cell instance is derived from the power and ground connections to its power and ground pins. In logical netlists, if the power domain of the always-on instance is switchable, this assumes that the always-on cell instance is powered by a domain that is an always-on domain and has the same voltage as the switchable domain in which it is placed.

CPF Command Equivalent: define_always_on_cell

Parameters

Related Commands

DELETE ALWAYS_ON CELL

REPORT ALWAYS_ON CELL

<module_name> Specifies the module name of the always-on cell.

-ALWAYS_on_power_pin <power_pin>

Specifies the power pin of the always-on cell.

-ALWAYS_ON_Ground_pin <ground_pin>

Specifies the ground pin of the always-on cell.

-ACTIVE_input <pin>

Specifies the data input pin of the always-on cell.


../cpf_ref/lib_reference.html#define_always_on_cell


ADD CELL PORTADD CEll POrt

< [-POWer <port_name> ...][-GROund <port_name> ...]

><-MODule <module_name*> ... >(Setup Mode)

Adds definitions for power and ground ports.

Parameters

Example

The following command creates a new port VDD, VSS to the module INV and make VDD the power port and VSS the ground port:

add cell port -power VDD -ground VSS -module INV

Related Commands

ADD POWER_GROUND PORT

DELETE POWER_GROUND PORT

REPORT POWER_GROUND PORT

-POWer <port_name> ...

Specifies the names of power ports to be added.

-GROund <port_name> ...

Specifies the names of ground ports to be added.

-MODule <module_name*> ...

Specifies the module, or modules, to which the power and ground port information applies. This accepts wildcards.



ADD CLAMP CELLADD CLamp Cell

<cell_name> -DATa <data_pin> ... -TYPe [POWer | GROund | BOTH ][-VDD <power_pin>][-VSS <ground_pin>](Setup Mode)

Specifies a cell as an antenna diode clamp type, and specifies its power and ground connections.

A diode clamp to VDD cannot be driven high when VDD is turned off so when the driving domain is ON and the diode clamp VDD domain is OFF, the diode clamp input must be isolated to a LOW value. In addition, the voltage of the clamp input driver can not be higher than the voltage of the diode clamp power domain.

For checking:

■ The power pin should be connected to a power domain with a voltage equal to or greater than the voltage of the power domain of the driver of data pin.

■ The power pin domain can be off when power domain of the driver is off.

■ When the power pin domain is off and power domain of the driver is on, then the driver output must be 0, in effect, isolate to zero for a ON to OFF crossing.

■ The ground pin must connect to a net connected to a ground pin that is identified with the ADD GROUND PIN command when the -ground option is specified. If not specified then the cell is only a clamp to power, not to ground also.

CPF Command Equivalent: define_power_clamp_cell

Parameters

<cell_name> Specifies the name of the clamp cell.

-DATa <data_pin> Specifies the name of the data pin.

-TYPe Specifies the type of the clamp cell.


../cpf_ref/lib_reference.html#define_power_clamp_cell


Related Commands

DELETE CLAMP CELL

REPORT CLAMP CELL

POWer Specifies a power clamp cell type. Use this type if the clamp cell clamps the signal voltage to the power net. This is the default.

For a power clamp, the power pin must also be specified with the -VDD option.

GROund Specifies a ground clamp cell type. Use this type if the clamp cell clamps the signal voltage to the ground net.

For a ground clamp, the ground pin must also be specified with the -VSS option.

BOTH Specifies both power and ground clamp cell types. Use this type if the cell is used to clamp the signal voltage to both power and ground nets.

For both power and ground clamps, the power and ground pins must also be specified with the -VDD and -VSS options, respectively.

-VDD <power_pin> Specifies the name of the power pin.

-VSS <power_pin> Specifies the name of the ground pin.



ADD DECAP CELLADD DECap Cell

<cell_name> -VDD <power_pin> -VSS <ground_pin>(Setup Mode)

Specifies a cell as a decoupled capacitor type, and specifies its power and ground connections.

Parameters

Related Commands

DELETE DECAP CELL

REPORT DECAP CELL

<cell_name> Specifies the name of the decoupled capacitor cell.

-VDD <power_pin> Specifies the name of the power pin.

-VSS <power_pin> Specifies the name of the ground pin.



ADD DOMAIN MAPPINGADD DOmain Mapping

-INStance <instance_pathname*> ...-MAPping <<domain> <local_domain>> ...(Setup Mode)

Defines how the domains within the macro are connected to domains outside the macro.

This is required only for logical netlists because they do not have power and ground connections. In physical netlists, the software automatically identifies such relationships through the power and ground net connectivity.

CPF Command Equivalent: set_instance

Parameters

Related Commands

DELETE DOMAIN MAPPING

REPORT DOMAIN MAPPING

-INStance <instance_pathname*> ...

Specifies instance(s) of a macro instance to which the domain mappings are to be applied. This accepts wildcards.

-MAPping <<domain> <local_domain>>

Specifies mapping for the local domain defined within the macro instance to higher-level power domain.


../cpf_ref/reference.html#set_instance


ADD EQUIVALENT PINSADD EQuivalent Pins

-MASter <master_pin>-PINs <pin> ...<-DOMain <domain> | -RULes <rule> ...>(Setup Mode)

Defines multiple pins to be equivalent for low power structural checks. These equivalent pins are used in the following:

■ Isolation control signal checks against user-specified isolation rules

■ Power or ground switch control signal checks against user-specified switch rules

■ Retention control signal checks against user-specified retention rules

CPF Command Equivalent: set_equivalent_control_pins

Parameters

Example

There is an isolation rule r1, where the -isolate is specified to be pin I0/OUT. However, in the design, there is an isolation cell for which this rule is applicable, but its control signal is driven by pin i1/OUT. This would result in the following error:

ISORULE1.1 - Isolation cell control pin is not connected to the specified signal

However, if you define the two pins i0/OUT and i1/OUT to be equivalent by running the command:

add equivalent pins -master i0/OUT -pins i1/OUT -rule r1

then those two pins will be considered equivalent, and the violation is suppressed.

-MASter <master_pin> Specifies the master pin in this group of equivalent pins.

-PINs <pin> ... Specifies other pins that are equivalent to the master pin.

-DOMain <domain> Specifies the domain for which these pins should be treated as equivalent.

-RULes <rule> ... Specifies the rule names for which these pins should be treated as equivalent.


../cpf_ref/reference.html#set_equivalent_control_pins


Related Commands

REPORT EQUIVALENT PINS



ADD GROUND PINADD GRound Pin

<domain_name> <primary_pin* ...> [-NOStandy | -Standby <expression>] > ...

(Setup Mode)

Defines the primary ground pins. This command is only valid for physical netlists.

CPF Command Equivalent: create_ground_nets

This command should not be issued before the ADD POWER DOMAIN or the ADD POWER PIN commands. For example:

add power domain PD1 ...add power domain PD2 ...add power pin ...add ground pin ...

Parameters

<domain_name> Specifies the name to represent the ground domain of the ground pins.

<primary_pin*...> Specifies the name of the primary pin(s). This accepts wildcards.

-NOStandby Specifies that the ground pins are always-on. This is the default.

-Standby <expression>

Specifies the standby expression for this ground domain.

Note: The Conformal Low Power software assumes all ground domains to be at zero voltage.

The expression specified denotes the condition for disabling this ground pin based on a logical expression of top-level input pins. This expression supports parenthesis, (), logical AND, &&, logical OR, ||, and logical NOT, !. Spaces can be used in the expression if the whole expression is quoted by double quotes. The variables of the expression are in terms of inputs pins of the module.


../cpf_ref/reference.html#create_ground_nets


Related Commands

DELETE GROUND PIN

REPORT GROUND PIN



ADD GROUND SWITCHADD GRound Switch

<module_name> <groundinpin> <groundoutpin><-STAGE_1_ENABLE <pin | !pin>"

[-STAGE_1_OUTPUT <pin>]"[-STAGE_2_ENABLE <pin | !pin>][-STAGE_2_OUTPUT <pin>]]

| -STANDBY <expression>>(Setup Mode)

Defines a ground switch. This command is only valid for physical netlists.

CPF Command Equivalent: define_power_switch_cell

Parameters

<module_name> Specifies the module name of the ground switch.

<groundinpin> Specifies the input ground pin of the ground switch.

<groundoutpin> Specifies the output ground pin of the ground switch.

-STAGE_1_ENABLE (-STAGE_2_ENABLE) <pin | !pin>

Specifies when the transistor inside the switch cell driven by this input pin is turned on (enabled) or off.

If only stage 1 is specified, the switch is fully turned on when the expression for the stage_1_enable option evaluates to true.

If both stages are specified, the switch is fully turned on when the expressions for both enable options evaluate to true.

The expression is a pin with an optional polarity value.

-STAGE_1_OUTPUT (-STAGE_2_OUTPUT) <pin>

Specifies the output pin of the switch that is a direct connection or a buffered derivative of the stage_x_input pin of the switch.

Note: Both of these options can be omitted if there is no stage output from the switch.


../cpf_ref/lib_reference.html#define_power_switch_cell


Related Commands

DELETE GROUND SWITCH

REPORT GROUND SWITCH


Specifies the condition in which the output ground pin is switched off. The expression is given in terms of the input pin(s) of the ground switch cell.

The expression supports parenthesis, (), logical AND, &&, logical OR, ||, and logical NOT, !. Spaces can be used in the expression if the whole expression is quoted by double quotes. The variables of the expression are in terms of inputs pins of the module.



ADD ISOLATION CELLADD ISolation Cell

<module_name> [-DEDicated

[-VDD <power_pin> [-VDDISO <power_pin>]-VSS <ground_pin> [-VSSISO <ground_pin>]

][-EXTRA_power_pin <power_pin>...]<-ISOPIN <pin>... | -ISOlate <expression>>

| -NONDedicated[-VDD <power_pin> -VSS <ground_pin>]

](Setup Mode)

Defines an isolation cell.

CPF Command Equivalent: define_isolation_cell

Parameters

<module_name> Specifies the module name of the isolation cell.

-DEDicated Defines a dedicated low power isolation cell. This is the default.

-VDD <power_pin> Specifies the power pin of the isolation cell.

-VDDISO <power_pin> Specifies the second power pin of the isolation cell. The domain of the output pin(s) of the isolation is determined by this power pin.

-VSS <ground_pin> Specifies the ground pin of the isolation cell.

-VSSISO <ground_pin> Specifies the second ground pin of the isolation cell. The domain of the output pin(s) of the isolation is determined by this ground pin.

-EXTRA_power_pin <power_pin> ...

Specifies the power pins that are in the cells but are not for isolation (for example, combined isolation and level-shifter cells).


../cpf_ref/lib_reference.html#define_isolation_cell


-ISOPIN <pin> ... Specifies a list of isolation control pins. The Conformal Low Power software will determine the isolation condition based on the specified control pins. However, if the isolation condition is complex and the software is not able to make a determination, it will request the isolation condition to be specified explicitly with -ISOLATE option.

Note: Specifying both -ISOPIN and -ISOlate in the same command is not allowed. Cadence recommends using -ISOPIN first and using -ISOlate if necessary.

-ISOlate <expression> Specifies the condition in which the data input(s) of isolation cell is isolated. <expression> is given in terms of the input pin(s) of the isolation cell.

The expression specified denotes the condition for enabling the isolation cell. This supports parenthesis, (), logical AND, &&, logical OR, ||, and logical NOT, !. Spaces can be used in the expression if the whole expression is quoted by double quotes. The variables of the expression are in terms of inputs pins of the module.

Note: Specifying both -ISOPIN and -ISOlate in the same command is not allowed. Cadence recommends using -ISOPIN first and using -ISOlate if necessary.

Important

If you specify -ISOPIN, the software attempts to find out the correct isolation expression for this cell. If it cannot, the command is rejected with an error message. If you specify -ISOlate, the isolation expression is taken as is and accepts the command without further checking.

-NONDedicated Defines a cell that can be used as an isolation cell as well as regular logic. This allows the isolation to control any input pin.

The isolation structural and functional checking will ignore any such cells that are not used as isolation, and will not report these as redundant.

Note: For physical netlists, you must specify power and ground pins.



Related Commands





ADD ISOLATION RULEADD ISolation Rule

<rule_name>[ [-SOURce [-ALL | <power_domain> ...] ][-DESTination [-ALL | <power_domain> ...] ][-TYPE [AUTO | ALL | LOw | HIgh | LATch | TRIstate] ...][-LOCAtion [DESTination | SOURce | OTHer | ALL] ...] ][-ISOlate <pin | !pin> ][ [-PIN <pin*> ...] [-EXClude <pin*> ...]

| [-INSTance <inst_name*> ...] ][-OFF_to_on | -ON_to_off][-CELL <cell_name> ...](Setup Mode)

Defines additional rules that must be checked for isolation cells.

CPF Command Equivalent: create_isolation_rule

Parameters

<rule_name> Specifies the name of the isolation rule.

-SOURce [-ALL | <power_domain> ...]

Specifies the source power domain(s) where this isolation rule is applying. The default is all power domains.

-DESTination [-ALL | <power_domain> ...]

Specifies the destination power domain(s) where this isolation rule is applying. The default is all power domains.


../cpf_ref/reference.html#create_isolation_rule


-TYPE [AUTO | ALL | LOw | HIgh | LATch | TRIstate] ...

Specifies the valid isolation cell type(s) for this isolation rule. By default, Conformal Low Power will determine the valid isolation cell type automatically—that is, there is no restriction when the isolation cell is in the destination or global (always-on) domain but only low type is allowed in the source domain.

AUTO Automatically determines the valid type based on the location of the isolation cell. This is the default.

LOw specifies that Iso-Lo is the valid isolation cell type.

High specifies that Iso-Hi is the valid isolation cell type.

LATch specifies that Iso-Latch is the valid isolation cell type.

TRIstate specifies that Tristate is the valid isolation cell type.

-LOCAtion [DESTination | SOURce | OTHer | ALL] ...

Specifies the valid location of the isolation cell.

DESTination specifies that the isolation cell must be placed in the destination domain. This is the default.

SOURce specifies that the isolation cell must be placed in the source domain.

OTHer specifies that the isolation cell must be placed in another domain that is not the source or destination. This domain must be ON whenever either the source or the destination domain is ON.

ALL specifies that the isolation cell can be placed in source, destination, or global domain.



Related Commands

DELETE ISOLATION RULE

REPORT ISOLATION RULE

-ISOlate <pin | !<pin>

Specifies which pin will control the isolation cells for the crossings covered by this rule. Specifying a pin name means that isolation control is active high. Using an exclamation point (!) before the pin name means that isolation control is active low.

Specifying enable condition, active high or low, allow you to determine which isolation cells defined by the ADD ISOLATION CELL command are valid to be used in this crossing. For example, an AND type isolation would be valid to use for the active low isolation enable, while an OR type would be valid for active high isolation enable.

-PIN <pin*> ... Defines the ports which need to be isolated. Used with the -LOCAtion option, this option specifies whether the ports are from the source or destination domain. This accepts wildcards.

-EXClude <pin*> ...

Defines the ports which will be excluded from this isolation rule check. This accepts wildcards.

-INSTance <inst_name*> ...

Defines the instances which need to be isolated. This accepts wildcards.

-OFF_to_on Specifies that this rule is only applied to power domain crossings where the source domain can be switched OFF while the destination domain is ON. This is the default.

-ON_to_off Specifies that this rule is only applied to power domain crossings where the source domain is ON while the destination domain is switched OFF.

-CELL <cell_name> ...

Specifies that the cell of the isolation instance matching this rule is one of the specified cells in this list.



ADD LEVEL SHIFTERADD LEvel Shifter

<module_name><in_voltage> [:<in_voltage_max> [ :<step_size>] ]<out_voltage> [:<out_voltage_max>[ :<step_size>] ] [-VDD_FROM <pin>] [-VDD_TO <pin>][-PATH <-INPUT <pin*> ...> <-OUTPUT <pin*> ...>[-ENABLE_PIN <pin> | -ENABLE_EXPression <expr>][-NOREVerse_direction | -REVerse_direction]] ...[-OUTPUT_VOLTAGE_LEVEL_INPUT <pin*> ...][-LOCAtion [ | SOURce | DESTination] ][-DIRection [BIdir | UP | DOWN](Setup Mode)

Defines the cells that are used to shift voltage signal levels and specifies the input and output voltage-level power pin of the level shifter cell.

CPF Command Equivalent: define_level_shifter_cell

Parameters

<module_name> Specifies the module name of the level shifter cell.

in_voltage [:<in_voltage_max> [ :<step_size> ] ]

Specifies the input voltage value.

To specify a range of input voltage values, use the :<in_voltage_max> option. For example, 1.0:1.2 specifies any voltage from 1.0 to 1.2.

Use <step_size> to specify a step size. If no step size is specified, the voltage is assumed to be a continuous voltage range. If a step size is specified, only the voltages at those steps are included. For example:

0.2 is a fixed voltage value of 0.2.

0.2:0.6 includes all voltages in the range 0.2 to 0.6, including 0.2 and 0.6.

0.2:0.6:0.2 includes the voltages 0.2, 0.4, and 0.6.


../cpf_ref/lib_reference.html#define_level_shifter_cell


out_voltage [:<out_voltage_max> [ :<step_size> ] ]

Specifies the output voltage value.

To specify a range of output voltage values, use the :<in_voltage_max> option. For example, 1.0:1.2 specifies any voltage from 1.0 to 1.2.

Use <step_size> to specify a step size. If no step size is specified, the voltage is assumed to be a continuous voltage range. If a step size is specified, only the voltages at those steps are included. For example:

0.2 is a fixed voltage value of 0.2.

0.2:0.6 includes all voltages in the range 0.2 to 0.6, including 0.2 and 0.6.

0.2:0.6:0.2 includes the voltages 0.2, 0.4, and 0.6.

-VDD_FROM Specifies the input-voltage-level power pin of the level shifter cell.

-VDD_TO Specifies the output-voltage-level power pin of the level shifter cell.

-PATH Specifies the detail of level shifting path. Multiple level shifting paths can be specified for the same level shifter cell.

-INPUT Specifies the input pins of the level shifting path.

-OUTPUT Specifies the output pins of the level shifting path.

-ENABLE_PIN Specifies the enable pin of this level shifting path.

-ENABLE_EXPression Specifies the enable condition of this level shifting path. Use this option if the Conformal Low Power software is not able to derive the enable condition from enable pin.

-NOREVerse_direction Specifies this level shifting path is shifting from input voltage to output voltage, as specified by <in_voltage> and <out_voltage>, respectively.

-REVerse_direction Specifies that the input voltage level of this level shifting path is set by <out_voltage> and output voltage level is set by <in_voltage>.

-OUTPUT_VOLTAGE_LEVEL_INPUT

Specifies the additional input pins which should be driven by logic which operates at output voltage level (for example, <out_voltage>).



Examples

■ The following command defines a typical level shifter cell:

add level shifter LevSh 1.2 0.8 -vdd_from VH -vdd_to VL -path \-input A -output Y

■ The following command defines a level shifter cell with an enable pin:

add level shifter LevSh 1.2 0.8 -vdd_from VH -vdd_to VL -path \-input A -output Y -enable_pin EN

■ The following command defines a level shifter cell with multiple level shifting paths where the path from A1 to Y1 has an enable pin and the path A2 to Y2 does not have an enable pin but its direction is reversed:

add level shifter LevSh 1.2 0.8 -vdd_from VH -vdd_to VL \-path -input A1 -output Y1 -enable_pin EN-path -input A2 -output Y2 -reverse_direction

Related Commands

DELETE LEVEL SHIFTER

REPORT LEVEL SHIFTER

-LOCAtion Specifies the valid location of the level shifter cell. Choose SOURce to specify only source domains, or DESTination to specify only destination domains. By default, this option specifies locations for both source and destination domains.

-DIRection [BIdir | UP | DOWN]

Specifies the direction in which the added level shifter cell can shift voltage values.

BIdir shifts lower to higher, as well as higher to lower voltages.

UP shifts lower to higher voltages.

DOWN shifts higher to lower voltages.



ADD LOWPOWER FILTERADD LOwpower Filter

<filter_name>[-TYPe <isolation | crossing | retention> ... ][-FROm <from_domain>][-TO <to_domain>][-MODule <module_name*> ...> ... ][-INStance <instance_name*> ... ](Setup Mode)

Defines filters for running functional checks from the list of previously added functional checks.

Parameters

Related Commands

DELETE LOWPOWER FILTER

REPORT LOWPOWER FILTER

<filter_name> Specifies the name of the filter.

-TYPe Specifies the type of checks that should not be performed on the cell type. Choose one of the following:

isolation—does not perform isolation checks on the specified instances.

crossing—does not perform crossing checks on the specified instances.

retention—does not perform retention checks on the specified instances.

-FROm Applies the filter only to crossings whose source power domain is <from_domain>.

-TO Applies the filter only to crossings whose destination power domain is <to_domain>.

-MODule Applies the filter to all the instances of the modules <module_name*>.

-INStance Applies the filter to all the instances <instance_name*>.



ADD OPEN_SOURCE PINSADD OPEN_source Pins

-MODules <module_name*>...-PINs <pin_name> ...(Setup Mode)

Defines the open source input pins of cells.

Parameters

Related Commands

REPORT OPEN_SOURCE PINS

-MODules <module_name*> ...

Specifies one or more module. This accepts wildcards.

-PINs <pin_name> ...

Specifies one or more pins of the module(s) that are open source.



ADD PATH RULEADD PAth Rule

<rule_name><-STArt <pin_pathname> ... ><-END <-MODule <module_name*> ... -PIN <pin_name*> ...

| -INStance <instance_path> ... -PIN <pin_name*> ... > ...

>[ | -PASS_through < <module_name*> ... [-IN <name> -OUT <name>]>

| -BUFfer| -INVerter> ...

| -EXClude <module_name*> ...| -INVERSION

][-VALidate [BOTH | STArt | END](Setup / Verify Mode)

Defines a path rule. A path rule defines legal paths between starting and ending point and the design objects that are allowed on the paths. For a given path rule, the following rule checks can be performed:

■ PATHRULE1.1

■ PATHRULE1.2

Parameters

<rule_name> Specifies the name of the path rule to be added.

-STArt Specifies a list of hierarchical pins to be the starting points of the paths.

-END Specifies a list of hierarchical pins to be the ending points of paths.

If -MODule is followed by -PIN, it specifies pins of all instantiations of the modules are ending points.

If -INStance is followed by -PIN, only pins of the specified instances are the ending points.



Related Command

DELETE PATH RULE

REPORT PATH RULE

VALIDATE PATH RULE

-PASS_through Specifies which design objects are allowed on the path.

If module names are specified without input and output ports specifications, the path is allowed to go through any input/output port combination.

If input and output ports are also specified (with -IN and -OUT), then only the path is only allowed to go through the specified input/output port combinations.

If -BUFfer is specified, the path can go through Conformal synthesized buffer primitives; likewise if -INVerter is specified, it can go through Conformal synthesized inverter primitives.

Note: This option cannot be used together with the -EXClude or -INVERSION options.

-EXClude Specifies a list of modules which are not allowed along the path.

Note: This option cannot be used together with the -PASS_through or -INVERSION options.

-INVERSION Specifies that end point must be inverted from the start point.

Note: This option cannot be used together with the -PASS_through or -EXClude options.

When using this option, the software will also ignore the -VALidate option, as it will only check the end points.

The violations for rules with the -INVERSION option are either PATHRULE1.1 or PATHRULE1.3.

-VALidate Specifies either starting points (STArt), ending points (END) or both (BOTH) to be validated. The default is to validate both starting and ending point (BOTH).



ADD POWER ASSOCIATIONADD POwer Association

<module_name> -POWer <power_pin> <data_pin*> ...[-DEFAULT_POWer <power_pin>]

| <mod_name> -GROund <ground_pin> <data_pin*> ...[-DEFAULT_GROund <ground_pin>]

| -PIN <pin> ... -DOMain <domain_name>| -INSTance <instance_path> <pin*>... -DOMain <domain_name>| -ALLINSTance <module_name> <pin*>... -DOMain <domain_name>

>(Setup Mode)

Defines the power association of input and output pins to power pins of a module.

CPF Command Equivalent: define_related_power_pins

Parameters

<module_name> Specifies the name of the module where this association is to be applied.

-POWer <power_pin> <data_pin*> ...

Specifies the associate data pins to a specific power pin in a module.

-DEFAULT_POWer <power_pin>

Specifies the power domain of pins which are not in the power association. <power_pin> must be a power pin of the module.

-GROund <ground_pin> <data_pin*> ...

Specifies to associate data pins to a specific ground pin in a module.

-DEFAULT_GROund <ground_pin>

Specifies the ground association of data pins which are not already associated to a ground pin in this command. <ground_pin> must be a ground pin of the module.

-PIN <pin>... Specifies the power association for primary pins.

The -pin and -domain options are order dependent. The -pin option must be used before the -domain option.


../cpf_ref/lib_reference.html#define_related_power_pins


Related Command

ANALYZE POWER ASSOCIATION

DELETE POWER ASSOCIATION

REPORT POWER ASSOCIATION

-DOMain <domain_name>

Associates the primary pins to an existing (defined) power domain.

The -pin and -domain options are order dependent. The -pin option must be used before the -domain option.

-INSTance <instance_path> <pin*>... -DOMain <domain_name>

Associates the pins of an instance to predefined power domains.

Note: These options are available only for logical netlist.

-ALLINSTance <module_name> <pin*>... -DOMain <domain_name>

Associates the pins of all instances of the module <module_name> to predefined power domains.

Note: These options are available only for logical netlist.



ADD POWER CHECKADD POwer Check

[-ALL| -ISOlation [-ASSERT]

[-ALL | <name*> ... [-MODule | -INStance]]| -Crossing [-SOURce [-ALL | <power_domain> ...]]

[-DESTination [-ALL | <power_domain> ...]]| -RETention [-CLOCK_value | -ASSERT | -ALL_RET_CHECK]

[-ALL | <name*> ... [-MODule | -INStance]]| -LEVel_shifter [-POWER]

[-ALL | <name*> ... [-MODule | -INStance]]](Verify Mode)

Defines which power checks will be performed.

Parameters

-ALL Adds all low power functional checks. This is the default.

-ISOlation Adds isolation cell functional check(s).

If you use -ALL after -ISOlation, this adds all isolation cell checks. This is the default. You can also add specific isolation cell checks by specifying either isolation cell module names or instance names.

-ASSERT (for -ISOlation)

Specifies the isolation control assert check to make sure the isolation cell control pin must be asserted properly to isolate the floating signal from the receiving power domain.

-Crossing Adds power domain crossing functional checks. A power domain crossing functional check is a check for proper isolation where no isolation cell is present between the power domain crossing. By default, all power domain crossing checks are added. You can add specific power domain crossing checks by specifying either source power domains or destination power domains or both.

-SOURce Specifies the source power domain.

-DESTination Specifies the name of the power domain.

<power_domain> Specifies the name power domain(s).



Related Commands

DELETE POWER CHECK

REPORT POWER CHECK

-RETention Adds retention cell functional check(s). If you use the -ALL option after -RETention, this adds all retention cell checks. This is the default. You can add specific retention cell checks by specifying either retention cell module names or instance names.

-CLOCK_value Adds the clock value functional check for retention cells. This ensures that the clock is set to the correct value (based on the clock off expression in the command), while retention control is asserted or de-asserted.

-ASSERT(for -RETention)

Specifies the retention control assert check to make sure retention control pin must be asserted when its retention power is on but the regular power is off.

-ALL_RET_CHECK Includes all retention cell related power checks.

-LEVel_shifter Adds level shifter cell functional check(s). If you use the -ALL option after -LEVel_shifter, this adds all level shifter cell checks. This is the default.

-POWER Specifies the level shifter power pin check to make sure either of the following two conditions must hold true:

When the output voltage level power pin is on the input voltage level power pin must be on

If this is a level shifter with enable pin cell, when input voltage level power pin is off and output voltage power pin is on, the enable pin must be asserted.



ADD POWER DOMAINADD POwer Domain

<domain_name><-VOLtage <voltage_value>

| <-VOLtage <voltage_value> -Condition <expression>> ... >>[-NOStandby | -EXTernal_standby | -Standby [<expression> [-PIN | -SIGnal]]]> ...[<-INStance | -MODule> <module_name*> ...] ...[-POWER <power_pin_name>][-GROUND <ground_pin_name>](Setup Mode)

Defines the power domain of a specified instance or module. If you specify a module, Conformal Low Power will define a different power domain for each instantiation of this module. For physical netlists, you should only use this command to define power domains for blackboxed instances. For logical netlists, you can use this command to define power domains for all instances.

Note: This command defines a virtual power domain if neither -INStance nor -MODule is specified.

Important

Specifying an instance path name with the domain name implies that the outputs of the instance have the same domain as the domain name. All the sub-instances of the instance path name have the domain name unless overridden by running the ADD POWER DOMAIN command again.

Note: When a power switch is a blackbox, do not use this command to assign the power domain to the pins of the blackbox. Instead, use the ADD POWER SWITCH switch command. This is because blackbox pins should be associated to a power pin of the blackbox.

CPF Command Equivalent: create_power_domain

Parameters

<domain_name> Specifies the name to represent the power domain.

voltage <voltage_value>

Specifies the voltage value of the power domain.


../cpf_ref/reference.html#create_power_domain


-Condition <expression>

Specifies that the condition in which the power domain is operated at the specified voltage value. Multiple voltage and condition pairs can be specified for a given power domain. Conditions must be specified if the power domain is expected to operate at different voltage values.

-NOStandby Specifies that the power domain is always-on. This is the default.

-EXTernal_standby Specifies that the power domain being defined is an external switchable power domain.

-Standby <expression> [-PIN | -SIGnal]

Specifies the condition in which the power domain is turned off.

If a domain can operate at multiple voltages, there can be multiple -voltage options specified for a single ADD POWER DOMAIN command, and each voltage must have a standby condition, since two different voltages are not allowed for a domain at the same time.

The standby expression is a logic function of inputs pins of the instance or module associated with this power domain. The module or instance is considered to be powered OFF when the condition of this expression is valid. This expression supports parenthesis, (), logical AND, &&, logical OR, ||, and logical NOT, !. Spaces can be used in the expression if the whole expression is quoted by double quotes.

-PIN specifies that the expression is based on the pins of the specified modules or instances. This is the default for the -Standby <expression> option.

-SIGnal specifies that the expression is any signal in the design.

-INStance <name*> ...

Specifies the name(s) of all the instances that belong to this domain. This accepts wildcards.

-MODule <module_name*> ...

Specifies the name(s) of all the modules that belong to this domain. This accepts wildcards.



Related Commands

DELETE POWER DOMAIN

SET LOWPOWER OPTION

REPORT POWER DOMAIN

UPDATE POWER DOMAIN

-POWer <power_pin_name>

Specifies the power pin of the specified instance or module. You can use this option only for physical netlists.

-GROund <ground_pin_name>

Specifies the ground pin of the specified instance or module. You can use this option only for physical netlists.



ADD POWER_GROUND PORTADD POwer_ground POrt

<-DEFault | <module_names*> ...><-POWER <port_name*> ...><-GROUND <port_name*> ...>[-IGNORE <power_port_name*> ...](Setup Mode)

Defines the power and ground port information of a module or modules. This command takes precedence over the power and ground ports defined with the LEF file.

Parameters

Related Command



-DEFAULT Specifies that the power and ground port information set with this command applies to every module if there is no specific power and ground port information defined for that module.

<module_names*> ... Specifies the modules to which the power and ground port information applies. You can specify multiple modules. This accepts wildcards.

-POWER <port_name*> ...

Specifies that the modules are the names of power ports. This accepts wildcards.

-GROUND <port_name*> ...

Specifies that the modules are the names of ground ports. This accepts wildcards.

-IGNORE <power_port_name*> ...

Specifies that the modules are the names of power cells (defined after -POWER), but they must be ignored from determining the power domain of the module. This accepts wildcards.



ADD POWER MODEADD POwer Mode

<mode_name><-ON_domain_list <domain>[@<voltage>]>... | -OFF_domain_list <domain>...> (Setup Mode)

Defines the various power modes in which the circuit will be operated. If there are power domains in your design that can be shut off, the power modes can specify which domains will be ON in any mode. The tool will then check for failures only in those modes.

If there are no power modes specified, the tool assumes that the various domains can be shut off independently, unless they are powered through dependent switches. This can result in false failures, especially for domain on-off conditions that might never happen in the actual circuit operation. Specifying the power modes in which the circuit will operate can eliminate many such false errors.

CPF Command Equivalent: create_power_mode

Parameters

Example

If there are three domains in the design: A, B and C, and the power of A and B can be shut down, and B operates at either 1.0 or 1.2 volts, the following modes can be specified:

add power mode m1 -on_domain_list A [email protected] C

add power mode m2 -on_domain_list [email protected] C

add power mode m3 -off_domain_list A B

<mode_name> Specifies the power mode name.

-ON_domain_list <domain1>[@voltage]> ...

Specifies the names of all the powered on domains. If this domain operates at multiple voltages, then please specify the voltage value at which it operates in this mode. The voltage is optional for domains that operate only at a single voltage. But for domains that can operate at multiple voltages, this is mandatory.

-OFF_domain_list <domain1> ...

Specifies the names of all the powered off domains.


../cpf_ref/reference.html#create_power_mode


Then the software will not check for isolation failures when C is ON and B is OFF, as that is not one of the specified power modes.

Related Commands

DELETE POWER MODE

REPORT POWER MODE



ADD POWER PINADD POwer Pin

<domain_name> <primary_pin* ...> <-VOLtage <voltage_value>

[-NOStandy | -Standby <expression>] > ...(Setup Mode)

Defines the primary power pins. This command is only valid for physical netlists.

CPF Command Equivalent: create_power_nets

Parameters

<domain_name> Specifies the name to represent the power domain of the power pins.

<primary_pin* ...> Specifies the name of the primary pin(s). This accepts wildcards.

-VOLtage <voltage_value>

Specifies the voltage value at which this domain can operate. The next standby condition specifies when this voltage is turned off for this domain.

-NOStandby Specifies that the power pins are always-on. This is the default.


../cpf_ref/reference.html#create_power_nets


Related Commands

DELETE POWER PIN

REPORT POWER PIN


Specifies the standby condition for the immediately preceding voltage value.

If a domain can operate at multiple voltages, there can be multiple -voltage options specified for a single ADD POWER DOMAIN command, and each voltage must have a standby condition, since two different voltages are not allowed for a domain at the same time.

The expression specified denotes the condition for disabling this power pin based on a logical expression of top-level input pins. This expression supports parenthesis, (), logical AND, &&, logical OR, ||, and logical NOT, !. Spaces can be used in the expression if the whole expression is quoted by double quotes. The variables of the expression are in terms of inputs pins of the module.



ADD POWER SWITCHADD POwer Switch

<module_name> <powerinpin> <poweroutpin><-STAGE_1_ENABLE <pin | !pin>"

[-STAGE_1_OUTPUT <pin>]"[-STAGE_2_ENABLE <pin | !pin>][-STAGE_2_OUTPUT <pin>]]

| -STANDBY <expression>>[-CONtrol_power <ctrl_power_pin>][-ENAble_pin_bias <threshold_voltage> ](Setup Mode)

Defines a power switch.

Note: When a power switch is a blackbox, use this command—not the ADD POWER DOMAIN command—to assign the power domain to the pins of the blackbox. This is because blackbox pins should be associated to a power pin of the blackbox.

CPF Command Equivalent: define_power_switch_cell

Parameters

<module_name> Specifies the module name of the power switch.

<powerinpin> Specifies the input power pin of the power switch.

<poweroutpin> Specifies the output power pin of the power switch.

-STAGE_1_ENABLE (-STAGE_2_ENABLE) <pin | !pin>

Specifies when the transistor inside the switch cell driven by this input pin is turned on (enabled) or off.

If only stage 1 is specified, the switch is fully turned on when the expression for the stage_1_enable option evaluates to true.

If both stages are specified, the switch is fully turned on when the expressions for both enable options evaluate to true.

The expression is a pin with an optional polarity value.


../cpf_ref/lib_reference.html#define_power_switch_cell


Related Commands

DELETE POWER SWITCH

REPORT POWER SWITCH

-STAGE_1_OUTPUT (-STAGE_2_OUTPUT) <pin>

Specifies the output pin of the switch that is a direct connection or a buffered derivative of the stage_x_input pin of the switch.

Note: Both of these options can be omitted if there is no stage output from the switch.


Specifies the condition in which the output power pin is switched off. The expression is given in terms of the input pin(s) of the power switch cell.


-CONtrol_power <ctrl_power_pin>

Specifies the power pin for powering the switch control logic inside the switch.

-ENAble_pin_bias <threshold_voltage>

Sets a higher range of allowable voltage on the enable input pin(s) of the power switch. For example, if the input voltage to the switch is 1.2 V, and enable pins can connect up to 1.7 V, specify this threshold as 0.5.



ADD RETENTION CELLADD Retention Cell

<module_name> <-RETention <expression>

| -SLEep <pin | !pin> -WAKe <pin | !pin>><-CLOck_off <expression>>[-POWer <vdd_pin> <vret_pin>][-DATa <data_pin ...>](Setup Mode)

Defines a retention cell. You can either specify the retention pin, or the sleep and wake pins.

Functional checks are not performed on retention cells having both sleep and wake pins.

CPF Command Equivalent: define_state_retention_cell

Parameters

<module_name> Specifies the retention cell module name.

-RETention <expression> Specifies a single control for both saving and restoring the data value.


-SLEep <pin | !pin> Specifies the condition when the data should be retained if there are separate controls to save and restore the retained data value.

-WAKe <pin | !pin> Specifies the condition when the data should be restored if there are separate controls to save and restore the retained data value.


../cpf_ref/lib_reference.html#define_state_retention_cell


Related Commands

DELETE RETENTION CELL

REPORT RETENTION CELL

-CLOck_off <expression> Specifies the expression for the off state of the clock in terms of the module input pins of the retention cell.


-POWer <vdd_pin vret_pin>

Specifies the VDD and retention power pin of the retention-register cell.

-DATa <data_pin ...> Specifies the data pin for the retention-register cell.



ADD RETENTION RULEADD RETention Rule

<rule_name> <-DOMain <power_domain>] | -INSTance <instance_path> ...

[-REcursive | -NONREcursive] > > [-EXClude_instance <instance_path> ...][-RETention <pin | !pin>

| -SLEep <pin | !pin> -WAKe <pin | !pin>][-CHEck_retention | -DONt_check_retention](Setup Mode)

Defines valid rules for checking retention rules.

CPF Command Equivalent: create_state_retention_rule

Parameters

<rule_name> Specifies the name of the rule.

-DOMain <power_domain> If a power domain is specified, the rule applies to all retention cell instances within that power domain.

-INStance <instance_path> Specifies the instance(s) on which the rule should be applied.

-EXClude_instance <instance_path> ...

Excludes specified instances from the rule. This activates the rule for all retention instances in the domain specified by the -domain option or the instances specified by the -instance option, except the ones excluded by this option.

-REcursive Searches for all DFF and DLAT types recursively within that instance hierarchy, and flags violations if any of them are not state retention flops. This is the default.

-NONREcursive Does not search for all DFF and DLAT types recursively. This checks only the specified instances and flags violations if any of them are not state retention flops.


../cpf_ref/reference.html#create_state_retention_rule


Examples

The following command applies the retention rule to all instances with names i* except instance i0, and specifies to check that their retention control is connected to the hierarchical pin A/B/C:

add retention rule r0 -INSTance i* -EXClude_instance i0 -sleep A/B/C

Note: You must specify all the instances to be controlled by a particular retention control signal in the same rule. Each rule is checked independently, so if you specify multiple rules with the same retention control signal, you might get spurious RETRULE1.2 errors. For example, if you have two retention rules as follows:

add retention rule r1 -instance reg1 -retention pg

add retention rule r2 -instance reg2 -retention pg

Combine them into one:

add retention rule r1 -instance reg1 reg2 -retention pg

Related Commands

DELETE RETENTION RULE

REPORT RETENTION RULE

-RETention <pin | !pin> Specifies the control signal that should connect to the retention pins of retention cells, as specified by the ADD RETENTION CELL command’s -retention option.

-SLEep <pin | !pin> Specifies the condition when the data should be retained, as specified by the ADD RETENTION CELL command’s -sleep option.

-WAKe <pin | !pin> Specifies the condition when the data should be restored, as specified by the ADD RETENTION CELL command’s -wake option.

-CHEck_retention Checks that all state elements within the specified instances or the specified power domain are retention flops. This is the default.

-DONt_check_retention Does not check that all state elements specified by the -domain or -instance options are retention flops.



ADD SWITCH RULEADD SWitch Rule

<rule_name><-DOMain <output_domain> | -POWER_OUT <out_net> | -GROUND_OUT <net>><-ENAble <polarity_signal_pin>

| -STAGE_1_enable <polarity_signal_pin> [-STAGE_2_enable <polarity_signal_pin>]

>[-POWER_IN <in_power_net> | -GROUND_IN <net>][-CELL <cell_name*>... ](Setup Mode)

Defines a switch rule to be verified for the specified output domain. The switch rule specifies the enabling condition of the switches driving the specified domain or the output power or ground net.

CPF Command Equivalent: create_power_switch_rule

Parameters

<rule_name> Specifies the name of the switch rule.

-DOMAIN <output_domain>

Specifies a domain. This rule is applied on all the power or ground switches that drive that domain.

-POWER_OUT <net> Specifies an internal power net. If the internal power net is specified by this option, the rule applies to all the power switches that drive that net.

-GROUND_OUT <net> Specifies an internal ground net. If the internal ground net is specified by this option, the rule applies to all the ground switches that drive that net.

-ENAble <polarity_signal_pin>

Specifies the hierarchical instance pin that should connect to the enable input of the switches that match this rule. If there is an exclamation (!) at the beginning of this path, an odd number of inversions must happen before the signal reaches the enable pins of the switches.


../cpf_ref/reference.html#create_power_switch_rule


Related Commands

DELETE SWITCH RULE

REPORT SWITCH RULE

-STAGE_1_enable <polarity_signal_pin>

Specifies the enable signal that should connect to the stage 1 enable pin of the power or ground switches that match this rule.

If the switch has only one enable pin, the single enable pin is taken as the stage 1 enable pin

-STAGE_2_enable <polarity_signal_pin>

Specifies the enable signal that should connect to the stage 2 enable pin of the power or ground switches that match this rule. This does not apply to any switch that has only one enable pin.

If STAGE_2_enable is not specified in the rule, but there are switches matching this rule that have stage 2 enable pin, then the tool checks that STAGE_1_enable also drives all the stage 2 enable pins of such switches.

-POWER_IN <net> Specifies a power net that is connected to the power inputs of the power switches. If this is specified, the rule is applied on all the power switches that drive the specified output domain or output power net, and whose input power pins connect to the specified POWER_IN net.

-GROUND_IN <net> Specifies a ground net that is connected to the ground inputs of the ground switches. If this is specified, the rule is applied on all the power switches that drive the specified output domain or output ground net, and whose input ground pins connect to the specified GROUND_IN net.

-CELL <cell_name*>...

Specifies cell names of the switch instances to which this rule should apply. If the cell name is specified, the rule is matched with only those switch instances that have the same cell name.



ANALYZE INSTANCE CONNECTIVITYANAlyze INstance Connectivity

<instance_name> ...(Setup / Verify Mode)

Shows the connectivity of instances along with their power and ground domains to help you debug low power violations. If the instance is a special low power cell, this also shows the low power cell specific information to help debug low power structural errors.

Parameters

Related Commands

REPORT PIN DRIVER

REPORT PIN LOAD

<instance_name> ... Specifies the name of the instance(s).



ANALYZE LIBRARYANAlyze LIbrary

[-LOWPOWER][-USED][-SUMmary | -VERbose](Setup Mode)

Analyzes library cells for power and ground pin consistency among their LEF, Verilog or Liberty, and CPF definitions.

Parameters

-LOWPOWER Checks the consistency between library views for information such as ports, cell names, and power/ground port attributes. The Library views supported are CPF, which is the reference for all the checks (and is required for this check), LEF, and Liberty or Library Verilog simulation models.

-USED Applies library consistency checking to the cells used in the design instead of checking every library cell that was read in.

-SUMmary Prints summary results for each library at the end of the analysis. This is the default.

-VERbose Prints detailed information for each library cell at the end of the analysis.



ANALYZE POWER ASSOCIATIONANAlyze POwer Association

[-Module <module_name*> ...>][-OUT_Dofile <dofile_name> | -OUT_CPF <filename>][-REPlace](Setup / Verify Mode)

Analyzes the module’s SPICE netlist and identifies the power pin each input and output pin with which it is associated. Before using this command, make sure the LEF, Library Verilog, and SPICE files have been read in.

Notes:

■ The power pin definition of a module comes from its LEF file.

■ Each input or output pin can have only one associated power pin. Multiple power pin association are ignored with a warning.

Parameters

Related Commands

ADD POWER ASSOCIATION



-Module <module_name*> ...>

Specifies the module(s) to be analyzed. Without this option, all modules in the library are analyzed. This accepts wildcards.

-OUT_Dofile <dofile_name>

Specifies the file to output the ADD POWER ASSOCIATION command.

-OUT_CPF <filename>

Specifies the output CPF file.

-REPlace Replaces the specified -OUT_Dofile file if it already exists.



ANALYZE POWER DOMAINANAlyze POwer Domain

[-FIX_PIN_DIRECTION](Setup / Verify Mode)

Performs power domain analysis. This command calculates the power domain information for the design and performs structural and rule checks afterward.

Parameters

Related Commands

ADD POWER DOMAIN

REPORT POWER DOMAIN

-FIX_PIN_DIRECTION Before power domain analysis, this changes the pin direction to the bi-directional (inout) type when an output port of a module is not driven by any logic inside the module, or when an input port of a module is driven by some logic inside the module.



COMMIT POWER INTENTCOMmit POwer Intent

[-FUNCTIONAL_INSERTION](Setup Mode)

Applies power intent.

Parameters

Related Command

COMMIT POWER INTENT

READ POWER INTENT

WRITE POWER INTENT

-FUNCTIONAL_INSERTION

Retention cells and isolation cells for OFF-->ON crossings only will be inserted for functional verification. Structural checks are disabled. Level shifters or power/ground switches will not be inserted.



DELETE ALWAYS_ON CELLDELete ALways_on Cell

<-ALL | <name> ...>(Setup Mode)

Deletes always-on cell(s) defined by ADD ALWAYS_ON CELL command.

Parameters

Related Commands

ADD ALWAYS_ON CELL

REPORT ALWAYS_ON CELL

-ALL Deletes all defined always-on cells.

<name> Specifies the defined always-on cell name, or names, to delete.



DELETE CLAMP CELLDELete CLamp Cell

<-ALL | <name> ...> (Setup Mode)

Deletes the specified antenna diode clamp cells that were originally added using the ADD CLAMP CELL command.

Parameters

Related Commands

ADD CLAMP CELL

REPORT CLAMP CELL

-ALL Deletes all antenna diode clamp cells.

<name> Specifies the antenna diode clamp cell name, or names, to delete.



DELETE DECAP CELLADD DECap Cell


Deletes the specified decoupled capacitor cells that were originally added using the ADD DECAP CELL command.

Parameters

Related Commands

ADD DECAP CELL

REPORT DECAP CELL

-ALL Deletes all decoupled capacitor cells.

<name> Specifies the decoupled capacitor cell module name, or names, to delete.



DELETE DOMAIN MAPPINGDELete DOmain Mapping

<-ALL | <instance_pathname*> ...(Setup Mode)

Deletes the domain mappings for an instance of a macro cell added with the ADD DOMAIN MAPPING command.

Parameters

Related Commands

ADD DOMAIN MAPPING

REPORT DOMAIN MAPPING

-ALL Deletes all domain mapping information for all macro instances.

<instance_pathname*> Specifies one or more instances of a macro instance to which the domain mappings are to be applied. This accepts wildcards.



DELETE GROUND PINDELete GRound Pin

<name* ...>[-Domain | -Pin] | -ALL]](Setup Mode)

Deletes ground pin(s) that were defined with the ADD GROUND PIN command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD GROUND PIN

REPORT GROUND PIN

<name* ...> Specifies the name of ground domain or ground pin. By default, this is treated as the symbolic ground domain name unless you specify the -Pin option. When this is a ground domain name, this command deletes all ground pins in the specified power domain.

-Domain Deletes the defined ground pins with ground domain names that match <name>.

-Pin Deletes the defined ground pins with pin names that match <name>.

-ALL Deletes all defined ground pins.



DELETE GROUND SWITCHDELete GRound Switch


Deletes ground switches that were defined with the ADD GROUND SWITCH command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD GROUND SWITCH


-ALL Deletes all defined ground switches.

<name> ... Specifies the name(s) of the defined ground switch(es) to delete.



DELETE ISOLATION CELLDELete Isolation Cell


Deletes isolation cells that were originally added with the ADD ISOLATION CELL command.

Parameters

Related Commands

ADD ISOLATION CELL


-ALL Deletes all isolation cells.

<name> ... Specifies the isolation cell module name, or names, to delete.



DELETE ISOLATION RULEDELete ISolation Rule

<-ALL | <rulename>* ...> (Setup Mode)

Deletes isolation rules defined with the ADD ISOLATION RULE command. This command is only valid for logical netlists.

Parameters

Related Commands

ADD ISOLATION RULE

REPORT ISOLATION RULE

-ALL Deletes all defined isolation cells.

<rulename>* ... Specifies the defined isolation rule name(s) to delete. This accepts wildcards.



DELETE LOWPOWER FILTERDELete LOwpower Filter

<<filter_name>... | -ALL>(Setup Mode)

Deletes filters that were defined with the ADD LOWPOWER FILTER command.

Parameters

Related Commands

ADD LOWPOWER FILTER

REPORT LOWPOWER FILTER

<filter_name> Specifies the name of the filter to delete.

-ALL Delete all low power filters.



DELETE LEVEL SHIFTERDELete LEvel Shifter


Deletes level shifters that were defined with the ADD LEVEL SHIFTER command.

Parameters

Related Commands

ADD LEVEL SHIFTER

REPORT LEVEL SHIFTER

-ALL Deletes all level shifters.

<name> Specifies the name of a defined level shifter.



DELETE PATH RULEDELete PAth Rule

<-ALL | <rulename*> ...>(Setup / Verify Mode)

Deletes path rules defined by the ADD PATH RULE command.

Parameters

Related Command

ADD PATH RULE

REPORT PATH RULE

VALIDATE PATH RULE

-ALL Deletes all path rules.

<rulename*> ... Specifies the name(s) of the path rule(s) to be deleted. This accepts wildcards.



DELETE POWER ASSOCIATIONDELete POwer Association

< -ALL| <module_name> [-POWer <power_pin> | <data_pin*>] ...| -PIN [ -DOMain <domain_name> | <primary_pin*>] ...

>(Verify Mode)

Deletes power associations defined by the ADD POWER ASSOCIATION command.

Parameters

Related Command




-ALL Deletes all power associations. This option is the default.

<module_name> Specifies the name of the module where this association is to be deleted.

-POWer <power_pin> <data_pin>

Deletes the associate data pins for a specific power pin in a module.

-PIN Specifies the power association for the primary pins to be deleted.

-DOMain <domain_name> <primary_pin>

Deletes the associate primary pins of an existing (defined) power domain.



DELETE POWER CHECKDELete POwer Check

<-ALL| -ISOlation [-ASSERT]

[-ALL | <name*> ... [-MODule | -INStance]]| -Crossing [-SOURce [-ALL | <power_domain> ...]]

[-DESTination [-ALL | <power_domain> ...]]| -RETention [[-CLOCK_value | -ASSERT | -ALL_RET_CHECK]


[-ALL | <name*> ... [-MODule | -INStance]]](Verify Mode)

Deletes the low power functional checks added with the ADD POWER CHECK command.

Parameters

-ALL Deletes all low power functional checks. This is the default.

-ISOlation Deletes isolation cell functional check(s). If you use -ALL after -ISOlation, this adds all isolation cell checks. This is the default. You can also add specific isolation cell checks by specifying either isolation cell module names or instance names.

-ASSERT(for -ISOlation)

Deletes isolation control assert checks.

-Crossing Deletes power domain crossing functional checks. A power domain crossing functional check is a check for proper isolation where no isolation cell is present between the power domain crossing. By default, all power domain crossing checks are deleted. You can delete specific power domain crossing checks by specifying either source power domains or destination power domains or both.






Related Commands

ADD POWER CHECK

REPORT POWER CHECK

-RETention Deletes retention cell functional check(s). If you use the -ALL option after -RETention, this deletes all retention cell checks. This is the default. You can delete specific retention cell checks by specifying either retention cell module names or instance names.

-CLOCK_value Deletes the clock value functional check for retention cells.


Deletes retention control assert checks.

-ALL_RET_CHECK Deletes all retention cell related power checks.

-LEVel_shifter Deletes level shifter cell functional check(s). If you use the -ALL option after -LEVel_shifter, this deletes all level shifter cell checks. This is the default.

-POWER Deletes the level shifter power pin check.



DELETE POWER DOMAINDELete POwer Domain

<<name* ...> [-Domain | -Instance] | -ALL>(Setup Mode)

Deletes the power domain(s) defined by the ADD POWER DOMAIN command.

Parameters

Related Commands

ADD POWER DOMAIN

REPORT POWER DOMAIN

<name* ...> Specifies the of power domain or instance. By default, this is treated as the symbolic power domain name unless you specify the -Instance option. When this is a power domain name, this command deletes all instances in the specified power domain.

-Domain Deletes all defined power domains that match <name>.

-Instance Deletes specific instances in the defined power domain.

-ALL Deletes all defined power domains.



DELETE POWER_GROUND PORTDELete POwer_ground POrt

<-ALL | -DEFault | <module_name>* ...>(Setup Mode)

Deletes the power and ground ports information defined by the ADD POWER_GROUND PORT command.

Parameters

Related Command



-ALL Deletes all power and ground port information for all modules and default settings.

-DEFAULT Deletes the power and ground ports information for the default settings.

<module_name*> ... Deletes the power and ground ports information for modules. This accepts wildcards.



DELETE POWER MODEDELete POwer Mode

<-ALL | <mode_name*> ...>(Setup Mode)

Deletes the power modes defined by the ADD POWER MODE command.

Parameters

Related Commands

ADD POWER MODE

REPORT POWER MODE

-ALL Deletes all power modes.

<mode_name*> ... Specifies the power mode name(s) to delete. This accepts wildcards.



DELETE POWER PINDELete POwer Pin

<name* ...>[-Domain | -Pin] | -ALL]](Setup Mode)

Deletes power pin(s) that were defined with the ADD POWER PIN command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD POWER PIN

REPORT POWER PIN

<name* ...> Specifies the name of power domain or power pin. By default, this is treated as the symbolic power domain name unless you specify the -Pin option. When this is a power domain name, this command deletes all power pins in the specified power domain.

-Domain Deletes the defined power pins with power domain names that match <name>.

-Pin Deletes the defined power pins with pin names that match <name>.

-ALL Deletes all defined power pins.



DELETE POWER SWITCHDELete POwer Switch


Deletes power switches that were defined with the ADD POWER SWITCH command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD POWER SWITCH

REPORT POWER SWITCH

-ALL Deletes all defined power switches.

<name> ... Specifies the name(s) of the defined power switch(es) to delete.



DELETE RETENTION CELLDELete Retention Cell

<-ALL | <name*> ...>(Setup Mode)

Deletes retention cell(s) defined by the ADD RETENTION CELL command.

Parameters

Related Commands

ADD RETENTION CELL

REPORT RETENTION CELL

-ALL Deletes all retention cells.

<name*> ... Specifies the retention cell(s) to delete. This accepts wildcards.



DELETE RETENTION RULEDELete RETention Rule

<-ALL | <name*> ...>(Setup Mode)

Deletes retention rule(s) defined by the ADD RETENTION RULE command.

Parameters

Related Commands

ADD RETENTION RULE

REPORT RETENTION RULE

-ALL Deletes all retention rules.

<name*> ... Specifies the retention rule(s) to delete. This accepts wildcards.



DELETE SWITCH RULEDELete SWitch Rule

[-ALL | <rulename*> ...](Setup Mode)

Deletes switch rules that were defined with the ADD SWITCH RULE command.

Parameters

Related Commands

ADD SWITCH RULE

REPORT SWITCH RULE

-ALL Deletes all switch rules.

<rulename*> ... Specifies the name(s) of the switch rule(s) to delete. This accepts wildcards.



DIAGNOSE POWER CHECKDIAgnose POwer Check

<-ISOlation [-ASSERT] <instance_name> | -CROssing <from_instance> <to_instance>| -RETention <instance_name> [-ASSERT] [-CLOCK_value]

>(Verify Mode)

Diagnoses failed low power functional checks.

Parameters

Related Commands

ADD POWER CHECK

DELETE POWER CHECK

REPORT POWER CHECK

-ISOlation <instance_name>

Specifies the failed isolation cell functional check.

-ASSERT Specifies that when the source domain is OFF, the isolation cell control pin must be asserted.

-CROssing <from_instance> <to_instance>

Specifies the failed power domain crossing.

-RETention <instance_name>

Specifies the failed retention cell functional check.

-ASSERT Specifies that when the source domain is OFF, the retention cell control pin must be asserted.

-CLOCK_value Specifies the clock value functional check for retention cells.



READ MACRO POWER_INFORMATIONREAd MAcro Power_information

<macro.cpf> [-NOREPlace | -REPlace](Setup Mode)

Reads a macro model definition for a blackboxed hard macro. The macro model definition is consistent with the macro definition in CPF 1.0e, and has the same syntax and semantics for consistency. Each macro model definition should be contained in separate files.

CPF Command Equivalents: set_macro_model, end_macro_model

Parameters

Related Commands

REPORT MACRO POWER_INFORMATION

<macro.cpf> Specifies the name of the macro model file.

-NOREPlace Does not replace existing macro model definitions. This is the default.

-REPlace Replace existing macro models with new definitions.


../cpf_ref/reference.html#set_macro_model

../cpf_ref/reference.html#end_macro_model


READ POWER INTENTREAd POwer Intent

<filename> [-CPF][-PRE_SIMULATION | -PRE_SYNTHESIS | -POST_SYNTHESIS | -PRE_ROUTE | -POST_ROUTE][-NAME_MAPPER_FILE <nmf_filename>][-LEVEL <number>][-REPlace][-APPend][-NOELABORATE][-LIBrary](Setup Mode)

Note: This is a Conformal Low Power command.

Reads and elaborates design power intent. When reading in power intent, all library objects in the intent file cause the library intent to be appended.

Parameters

<filename> Specifies the name of the power intent file.

-CPF Specifies that the file format is CPF.

-PRE_SIMULATION Check the quality of the power intent specification before RTL level simulation. Library related quality control checkers are disabled.

-PRE_SYNTHESIS Check quality of power intent specification and Library (Liberty) before gate synthesis.

-POST_SYNTHESIS Check quality of synthesized gate netlist based on power intent specification. Power intent rules for domain crossings are disabled in the quality check stage. Quality checks for the crossing rules are not needed. The crossing and implementation per rule is checked by the ANALYZE POWER DOMAIN STAGE.

-PRE_ROUTE Check quality of power intent specification and library (Liberty) before place and route.



-POST_ROUTE Checks the quality of the place-and-route gate netlist based on the power intent specification. Power intent rules for domain crossings are disabled in the quality check stage. Quality checks for the crossing rules are not needed. The crossing and implementation per rule is checked by the ANALYZE POWER DOMAIN STAGE.

-LEVEL <number> Defines the number of hierarchical design scope levels in the CPF file

-REPlace Use this option to overwrite elaborated data. This option overwrites hard IP and design power intent.

This option does not overwrite library power intent. If library power intent is defined in a power intent file, this option will overwrite existing objects, append new objects, and preserve existing objects that are not in conflict.

-NAME_MAPPER_FILE <nmf_filename>

Specifies the name mapper file.

During creation of the gate-level netlist, the synthesis tool might change the names of the design objects from their RTL name. The synthesis tool records all the name changes in a name mapper file. Conformal Low Power can use the name mapper file to link between the original design object names specified in the CPF and their new names in the gate-level netlist.

-APPend Appends elaborated data. This option appends hard IP and design power intent.

Individual objects can be replaced by new objects, without resetting existing objects that are not being updated

-NOELABORATE Does not elaborate power intent.

When this option is not specified, power intent is elaborated by default.

-LIBrary When the design is not read in, the command only checks the power intent syntax. Use this option to read the power intent library definitions into the database for library checking when no design is read in.



Related Commands

COMMIT POWER INTENT

READ POWER INTENT

WRITE POWER INTENT



RENAME GROUND DOMAINREName GRound Domain

<old_domain_name> <new_domain_name>(Setup Mode)

Renames an existing ground domain. This command is useful for overriding the automatically generated names of ground switch output domains. Normally, the automatically generated name is the hierarchical net name of the net connected to the output of the ground switch.

You can run the REPORT POWER SWITCH command to see the Power Switch Report that shows the automatically generated name for the input and output ground domains.

Note: The new power domain name cannot be an existing ground domain name.

Parameters

Related Commands


<old_domain_name> Specifies the existing name of the ground domain.

<new_domain_name> Specifies the new name of the ground domain.



RENAME POWER DOMAINREName POwer Domain

<old_domain_name> <new_domain_name>(Setup Mode)

Renames an existing power domain. This command is useful for overriding the automatically generated names of power switch output domains. Normally, the automatically generated name is the hierarchical net name of the net connected to the output of the power switch.

You can run the REPORT POWER SWITCH command to see the Power Switch Report that shows the automatically generated name for the input and output power domains.

Note: The new power domain name cannot be an existing power domain name.

Parameters

Related Commands

ADD POWER DOMAIN

REPORT POWER SWITCH

<old_domain_name> Specifies the existing name of the power domain.

<new_domain_name> Specifies the new name of the power domain.



REPORT ALWAYS_ON CELLREPort ALways_on Cell

[-ALL | <name*> ...][-SUMmary | -VERbose [-NOINStance | -INStance]](Setup / Verify Mode)

Reports the always-on cells defined by the ADD ALWAYS_ON CELL command.

Parameters

Related Commands

ADD ALWAYS_ON CELL

DELETE ALWAYS_ON CELL

-ALL Reports all defined always-on cells.

<name*> ... Specifies the name of the defined always-on cell(s). The wildcard is accepted.

-SUMmary Reports defined always-on cell(s) in a summary table. This is the default.

-VERbose Reports details of each defined always-on cell. The instantiation of each always-on cell is not report unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each always-on cell. This is the default.

-INStance Reports the instantiation of each always-on cell.



REPORT CLAMP CELLREPort CLamp Cell

[-ALL | <name*> ...][-SUMmary | -VERbose [-NOINStance | -INStance]] (Setup / Verify Mode)

Reports the antenna diode clamp cells defined by the ADD CLAMP CELL command.

Parameters

Related Commands

ADD CLAMP CELL

DELETE CLAMP CELL

-ALL Reports all defined antenna diode clamp cells.

<name*> ... Specifies the name of the defined antenna diode clamp cell(s). This accepts wildcards.

-SUMmary Reports defined antenna diode clamp cell(s) in a summary table. This is the default.

-VERbose Reports details of each defined antenna diode clamp cell. The instantiation of each antenna diode clamp cell is not reported unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each antenna diode clamp cell. This is the default.

-INStance Reports the instantiation of each antenna diode clamp cell.



REPORT CPF LOGICREPort CPf Logic

[-ISOlation][-Level_shifter][-RETention][-Verbose](Setup / Verify Mode)

Reports the low power cells that were inserted by the Conformal Low Power software.

Parameters

Note: By default, this command reports all inserted low power cell types.

Example

The following commands read the lib.cpf and design.cpf files, performs low power cell insertion, and reports only the inserted isolation and level-shifter cells:

read power intent lib.cpf design.cpf

commit cpf -insert

report cpf logic -isolation -level_shifter

Related Commands

COMMIT POWER INTENT

READ POWER INTENT

-ISOlation Reports the inserted isolation cells only.

-Level_shifter Reports the inserted level-shifter cells only.

-RETention Reports the inserted state retention cells only.

-VERbose Reports detailed information of each defined CPF cell, including cell types and rules that triggered this cell to be inserted in the design.



REPORT DECAP CELLADD DECap Cell

[-ALL | <name*> ...][-SUMmary | -VERbose [-NOINStance | -INStance]] (Setup / Verify Mode)

Reports the decoupled capacitor cells defined by the ADD DECAP CELL command.

Parameters

Related Commands

ADD DECAP CELL

DELETE DECAP CELL

-ALL Reports all defined decoupled capacitor cells.

<name*> ... Specifies the name of the defined decoupled capacitor cell(s). This accepts wildcards.

-SUMmary Reports defined decoupled capacitor cell(s) in a summary table. This is the default.

-VERbose Reports details of each defined decoupled capacitor cell. The instantiation of each decoupled capacitor cell is not reported unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each decoupled capacitor cell. This is the default.

-INStance Reports the instantiation of each decoupled capacitor cell.



REPORT DOMAIN MAPPINGREPort DOmain Mapping

[-ALL | <instance_pathname*> ... ](Setup Mode)

Reports the domain mappings for instances of macro cells added with the ADD DOMAIN MAPPING command.

Parameters

Related Commands

ADD DOMAIN MAPPING

DELETE DOMAIN MAPPING

-ALL Reports all domain mapping information for all macro instances.

<instance_pathname*> ...

Specifies one or more macro instances whose domain mapping information are to be reported.



REPORT EQUIVALENT PINSREPort EQuivalent Pins

(Setup Mode)

Reports the previously defined groups of equivalent pins defined with the ADD EQUIVALENT PINS command.

Related Commands

ADD EQUIVALENT PINS



REPORT GROUND PINREPort GRound Pin

(Setup / Verify Mode)

Reports all ground pins defined by the ADD GROUND PIN command. This command is only valid for physical netlists.

Related Commands

ADD GROUND PIN

DELETE GROUND PIN



REPORT GROUND SWITCHREPort GRound Switch

[-DOMain](Setup / Verify Mode)

Reports the ground switches defined by the ADD GROUND SWITCH command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD GROUND SWITCH

DELETE GROUND SWITCH

-DOMain Reports only one switch per switched output domain. Use this option to output a concise report of the ground domains that are driven by parallel switches.



REPORT ISOLATION CELLREPort ISolation Cell


Reports the isolation cells defined by the ADD ISOLATION CELL command.

Parameters

Related Commands

ADD ISOLATION CELL


-ALL Reports all defined isolation cells.

<name*> ... Specifies the name of the defined isolation cell(s). This accepts wildcards.

-SUMmary Reports defined isolation cell(s) in a summary table. This is the default.

-VERbose Reports details of each defined isolation cell. The instantiation of each isolation cell is not reported unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each isolation cell. This is the default.

-INStance Reports the instantiation of each isolation cell.



REPORT ISOLATION RULEREPort ISolation Rule

[-ALL | <rule_name*> ...](Setup / Verify Mode)

Reports isolation rules defined by the ADD ISOLATION RULE command. This command is only valid for logical netlists.

Parameters

Related Commands

ADD ISOLATION RULE

DELETE ISOLATION RULE

-ALL Reports all defined isolation rules.

<rule_name*> ... Specifies the name of the defined isolation rule(s). This accepts wildcards.



REPORT LOWPOWER FILTERREPort LOwpower Filter

<<filter_name> ... | -ALL>(Setup / Verify Mode)

Reports filters that were defined with the ADD LOWPOWER FILTER command.

Parameters

Related Commands

ADD LOWPOWER FILTER

DELETE LOWPOWER FILTER

<filter_name> ... Specifies the name of the filter(s) to report.

-ALL Reports all low power filters.



REPORT LEVEL SHIFTERREPort LEvel Shifter


Reports level shifters defined by the ADD LEVEL SHIFTER command.

Parameters

Related Commands

ADD LEVEL SHIFTER

DELETE LEVEL SHIFTER

-ALL Reports all defined level shifter.

<name*> ... Specifies the name of the defined level shifter(s). This accepts wildcards.

-SUMmary Reports defined level shifter(s) in a summary table. This is the default.

-VERbose Reports details of each defined level shifter. The instantiation of each level shifter is not report unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each level shifter. This is the default.

-INStance Reports the instantiation of each level shifter.



REPORT MACRO POWER_INFORMATIONREPort MAcro Power_information

(Setup Mode)

Reports the macro model definitions added with the READ MACRO POWER_INFORMATION command.

Related Command

READ MACRO POWER_INFORMATION



REPORT OPEN_SOURCE PINSREPort OPEN_source Pins

[-ALL | <module_name*> ...](Setup / Verify Mode)

Reports open source pins defined by the ADD OPEN_SOURCE PINS command.

Parameters

Related Commands

ADD OPEN_SOURCE PINS

-ALL Reports all defined open source pins. This is the default.

<module_name*> ... Specifies the name(s) of the module(s) whose open source pins are to be reported. This accepts wildcards.



REPORT PATH RULEREPort PAth Rule

<-ALL | <rule_name*> ...>(Setup / Verify Mode)

Reports path rules defined by the ADD PATH RULE command.

Parameters

Related Command

ADD PATH RULE

DELETE PATH RULE

VALIDATE PATH RULE

-ALL Reports all path rules.

<rule_name*> ... Specifies the name(s) of the path rule(s) to be reported. This accepts wildcards.



REPORT PIN DRIVERREPort PIn DRiver

<<-CELL <cell_name> <pin_name> | -INStance <instance_name> <pin_name>> ...[-PASS <cell_name> <in_pin> <out_pin>]...[-SKIP <BBOX | DFF | PI | PO | PIO | LS | ISO | RET | <cell_name*> > ...][-PATH [-VERbose | -SUMmary] [-LIMIT <number>] ](Setup / Verify Mode)

Reports drivers of cell pins or instance pins.

Parameters

-CELL Reports the drivers of the pins <pin_name> of all the instances of this <cell_name>.

-INSTance Reports the drivers of the pins <pinname> of a specific instance <instance_name>.

-PASS Specifies the names of cells through which the path tracing should continue.

-SKIP Does not report the drivers that match these types. The type can be either some cell name, or certain types of cells or pins, which can be one of the following:

-BBOX black box pins

-DFF D flip-flops

-PI primary input pins

-PO primary output pins

-PIO primary inout pins

-LS level-shifter cell pins

-ISO isolation cell pins

-RET retention cell pins

<cell_name*> Specifies the cell name.

-PATH Reports paths that end at the specified pin.

-VERbose Reports the entire path. This is the default.

-SUMmary Reports only the staring points that drive the specified pin



Related Commands

REPORT PIN LOAD

-LIMIT <number>

Specifies the number of paths to be reported.



REPORT PIN LOADREPort PIn LOad

<<-CELL <cell_name> | -INStance <instance_name> > <pin_name>>...[-PASS <cell_name> <in_pin> <out_pin>] ...[-SKIP <BBOX | DFF | PI | PO | PIO | LS | ISO | RET | <cell_name*> >...][-PATH [-VERbose | -SUMmary] [-LIMIT <number>] ](Setup / Verify Mode)

Reports loads of cell pins or instance pins.

Parameters

-CELL Reports the loads of the pins <pin_name> of all the instances of this <cell_name>.

-INSTance Reports the loads of the pins <pin_name> of a specific instance <instance_name>.

-PASS Specifies the names of cells through which the path tracing should continue.

-SKIP Does not report the loads that match these types. The type can be either some cell name, or certain types of cells or pins, which can be one of the following:

-BBOX black box pins

-DFF D flip-flops

-PI primary input pins

-PO primary output pins

-PIO primary inout pins

-LS level-shifter cell pins

-ISO isolation cell pins

-RET retention cell pins

<cell_name*> Specifies the cell name.

-PATH Reports paths that start from the specified pin.

-VERbose Reports the entire path. This is the default.

-SUMmary Reports only the ending points that are driven by the specified pin



Related Commands

REPORT PIN DRIVER

-LIMIT <number>

Specifies the number of paths to be reported.



REPORT POWER ASSOCIATIONREPort POwer Association

[-UNassociated] [-ALL | -PIN | | -INStance [<instance_name>...] | <module_name*>...](Setup / Verify Mode)

Reports power associations defined by the ADD POWER ASSOCIATION command.

Parameters

Example

The following command reports all primary pins that have no power domain associations:

report power association -unassociated -pin

-UNassociated Reports objects that have no power association.

-ALL Reports all power associations for primary pins and modules. If you also specify the -unassociated option, the command reports all primary pins and black box module pins that have no power association.

-PIN Reports only power associations related to primary pins. If you also specify the -unassociated option, the command reports only primary pins that have no power association.

-INStance [<instance_name>...]

Reports the direct domain associations for pins of specified instances, as added with the command:

add power association {-instance | -allinstance}

If no instance name is specified, this command option reports all existing direct power domain associations.

<module_name*> ... Reports only power associations related to specified module(s). If you also specify the -unassociated option, the command reports pins of the specified black box module(s) that have no power association. This accepts wildcards.



Related Command






REPORT POWER CHECKREPort POwer Check

[-ALL| -ISOlation [-ASSERT]

[-ALL | <name*...> ... [-MODule | -INStance]]| -Crossing [-SOURce [-ALL | <power_domain> ... ]]

[-DESTination [-ALL | <power_domain ...]> ...] ]| -RETention [-CLOCK_value | -ASSERT | -ALL_RET_CHECK]


[-ALL | <name*>... [-MODule | -INStance]]][-SUMmary | -VERbose | -UNIque](Verify Mode)

Reports the information specified by the ADD POWER CHECK command.

Parameters

-ALL Reports all low power functional checks. This is the default.

-ISOlation Reports isolation cell functional check(s). If you use -ALL after -ISOlation, this reports all isolation cell checks except those have been verified as redundant structurally. This is the default. You can also report specific isolation cell checks by specifying either isolation cell module names or instance names.

-ASSERT(for -ISOlation)

Reports isolation control assert checks.

-Crossing Reports power domain crossing functional checks. A power domain crossing functional check is a check for proper isolation where no isolation cell is present between the power domain crossing. By default, all power domain crossing checks are reported. You can report specific power domain crossing checks by specifying either source power domains or destination power domains or both.






Related Commands

ADD POWER CHECK

DELETE POWER CHECK

-RETention Reports retention cell functional check(s). If you use the -ALL option after -RETention, this reports all retention cell checks. This is the default.

You can report specific retention cell checks by specifying either retention cell module names or instance names.

-CLOCK_value Reports the clock value functional check for retention cells.


Reports retention control assert checks.

-ALL_RET_CHECK Reports all retention cell related power checks.

-LEVel_shifter Reports level shifter cell functional check(s). If you use the -ALL option after -LEVel_shifter, this reports all level shifter cell checks. This is the default.

-POWER Reports the level shifter power pin check.

-SUMmary Reports low power functional check(s) in a summary table. This is the default.

-VERbose Reports details of each low power functional check.

-UNIque Reports unique low power functional check(s) in a summary table.



REPORT POWER DOMAINREPort POwer Domain

[-DOMain <domain_name> ... ][ | -LIB

| -PIN <path_name> ... [-DRIver | -LOAd]| -NET <path_name> ... [-DRIver | -LOAd] | -MODule <module_name> ... | -INSTance <instance_pathname> ...

[-NORECursive| -RECursive [ <-MATch| -UNMATch> <power_domain>[-EXClude <instance_pathname> ... ]

]](Setup / Verify Mode)

Reports the power domains specified by the ADD POWER DOMAIN command or reports the power domains found in the design by analyzing the power and ground connectivity of instances. You can also use this command to report specific power domains, or power domains of library cells, nets, or instances. When reporting the power domain of instances, additional options are available to report only those instances that match or do not match a specified domain.

If no argument is specified, this command reports all the power domains in the design.

Note: If you specify any arguments, you must run ANALYZE POWER DOMAIN before running this command.

Parameters

-DOMain <domain_name>

Reports the details of one or more specified power domains.

-LIB Reports the power domain of a library cell after the power domain has been analyzed.

-PIN <path_name> Reports the power domains of the specified hierarchical instance pins after the power domain has been analyzed.

-NET <path_name> Reports the power domains of the specified hierarchical nets after the power domain has been analyzed.

-DRIver Reports the power domain of instance pins driving the specified pins (with the -PIN option) or specified nets (with the -NET option).



Examples

■ The following command reports the power domains of pin VDD1 of instance inst1 and pin VDD2 of instance inst2:

report power domain -pin inst1/VDD1 inst2/VDD2

■ The following command reports the power domains of net abar in the root module and net netA in the instance inst1. In addition, the -load option causes the reporting of the power domains of the instance pins that these nets drive.

report power domain -net abar inst1/netA -load

Related Commands

ADD POWER DOMAIN

ANALYZE POWER DOMAIN

DELETE POWER DOMAIN

-LOAd Reports the power domain of the instance pins that is being driven by the specified pins (with the -PIN option) or specified nets (with the -NET option).

-MODule Reports the number of occurrences of <modulename> in each power domain.

-INSTance <instance_pathname>

Specifies the instance pathname.

-NORECursive Reports only the power domains of named instances.

-RECursive Reports the power domains of all instances inside the named instance.

-MATch Reports only instances whose power domains match <power_domain>.

-UNMATch Reports only instances whose power domains do not match <power_domain>.

<power_domain> Specifies the name of the power domain.

-EXClude <instance_pathname>

When using -RECursive with either -MATch or -UNMATch, this option reporting the domain of specified instances.



REPORT POWER_GROUND PORTREPort POwer_ground POrt

<-ALL | -DEFault | <module_name>* ...>(Setup Mode)

Reports the power and ground ports information specified with the ADD POWER_GROUND PORT command.

Parameters

Related Command



-ALL Reports all power and ground port information for all modules and default settings.

-DEFAULT Reports the power and ground ports information for the default settings.

<module_name>* ... Reports the power and ground ports information for modules. This accepts wildcards.



REPORT POWER MODEREPort POwer Mode

[-All | <mode_name*> ...] (Setup Mode)

Reports the power modes defined by the ADD POWER MODE command.

Parameters

Related Commands

ADD POWER MODE

DELETE POWER MODE

-All Reports all power modes. This option is the default.

<mode_name*> ... Specifies the power mode name(s) to report. This accepts wildcards.



REPORT POWER PINREPort POwer Pin


Reports all power pins defined by the ADD POWER PIN command. This command is only valid for physical netlists.

Related Commands

ADD POWER PIN

DELETE POWER PIN



REPORT POWER SWITCHREPort POwer Switch

[-DOMain](Setup / Verify Mode)

Reports the power switches defined by the ADD POWER SWITCH command. This command is only valid for physical netlists.

Parameters

Related Commands

ADD POWER SWITCH

DELETE POWER SWITCH

-DOMain Reports only one switch per switched output domain. Use this option to output a concise report of the power domains that are driven by parallel switches.



REPORT RETENTION CELLREPort Retention Cell

<-ALL | <name*> ...>[-SUMmary | -VERbose [-NOINStance | -INStance] ](Setup / Verify Mode)

Displays the list of retention-register cells that were created with the ADD RETENTION CELL command.

Parameters

Related Commands

ADD RETENTION CELL

DELETE RETENTION CELL

-ALL Reports all defined retention cells.

<name*> Specifies the defined retention cell(s) to report. This accepts wildcards.

-SUMmary Reports defined retention cell(s) in a summary table. This is the default.

-VERbose Reports details of each defined retention cell. The instantiation of each retention cell is not report unless you specify the -INStance option.

-NOINStance Does not report the instantiation of each retention cell. This is the default.

-INStance Reports the instantiation of each retention cell.



REPORT RETENTION RULEREPort RETention Rule

[-ALL | <rule_name*> ...](Setup / Verify Mode)

Displays the list of retention rules that were created with the ADD RETENTION RULE command.

Parameters

Related Commands

ADD RETENTION RULE

DELETE RETENTION RULE

-ALL Reports all defined retention rules.

<rule_name*> ... Specifies the name of the defined retention rule(s). This accepts wildcards.



REPORT SWITCH RULEREPort SWitch Rule

[-ALL | <rule_name*> ...](Setup Mode)

Displays switch rules that were defined with the ADD SWITCH RULE command.

Parameters

Related Commands

ADD SWITCH RULE

DELETE SWITCH RULE

-ALL Displays all switch rules.

<rule_name*> ... Specifies the name(s) of the switch rule(s) to display. This accepts wildcards.



SET LOWPOWER OPTIONSET LOwpower Option

[-NETLIST_STYLE <PHYsical | LOGical | HYBrid>][-ISOLATION_LOCATION [AUTO | SOURCE]][-RETENTION_LIMIT <limit>][-ISOLATION_LIMIT <limit>] [-LEVEL_SHIFTER_CHECK [COMMAND_value | CONNECTivity]][-IGNORE_HIGH_TO_LOW [<tolerance>] ][-IGNORE_LOW_TO_HIGH [<tolerance>] ][-REPort_file <filename>][-NO_SWITCH_CHAIN_checks | -SWITCH_CHAIN_checks][-MAX_PMOS_stack_depth <<number> | OFF>][-MAX_NMOS_stack_depth <<number> | OFF>][-NO_COALESCE_STACK_VIOLATIONS | -COALESCE_STACK_VIOLATIONS][-LP_CTRL_TREE_CHECK | -NO_LP_CTRL_TREE_CHECK][-NO_LOCAL_constants | -LOCAL_constants][-NO_CLONE_check | -CLONE_check][-PASS_DATA_BUF][-POWER_VOLTAGE_TOLERANCE <min:max>][-GROUND_VOLTAGE_TOLERANCE <min:max>] [-CHECK_FLOATING_OUTPUT_INSTANCE | -NO_CHECK_FLOATING_OUTPUT_INSTANCE][-NO_SKIP_LIB_CELL_VOLTAGE_CHECK | -SKIP_LIB_CELL_VOLTAGE_CHECK](Setup Mode)

Specifies the tool environment or global behavior of low power checks.



Parameters

-NETLIST_STYLE <PHYsical | LOGical | HYBrid>

Specifies the design netlist.

PHYsical (the default) indicates that the design is a physical netlist (netlists with power connectivity).

LOGical indicates that the design is a logical netlist.

HYBrid indicates that the design is a hybrid physical and logical netlist.

Conformal Low Power supports the hybrid netlist style only if the LEF definitions of cells used in the physical netlist portion of the design are also available. The LEF definitions allow Conformal Low Power to identify the power and ground ports of these cells so it can transform the hybrid netlist style into a pure logical netlist by removing the power and ground ports of these cells. The transformation will be performed automatically after running the READ DESIGN command, so the hybrid netlist style must be specified before READ DESIGN in this case.

-ISOLATION_LOCATION [AUTO | SOURCE]

Controls the valid location of the isolation cell.

AUTO (the default) automatically determines the valid location of the isolation cell based on the structure of the cell and the surrounding domains where the isolation cell is used.

SOURCE specifies that the isolation cell can only be used in the source domains.

-RETENTION_LIMIT <limit>

Specifies the global limit on the number of retention control pins driven by the same signal.

For more information on how this option works, see the description for RET6.

-ISOLATION_LIMIT <limit>

Specifies the global limit on the number of isolation control pins driven by the same signal.



-LEVEL_SHIFTER_CHECK [COMMAND_value | CONNECTivity]

Specifies how level shifter structural checks are performed.

COMMAND_value (the default) checks the voltage values that are connected to the input/output port of the level shifter against the voltage values specified by the ADD LEVEL SHIFTER command.

CONNECTivity checks that the power that is connected to the input voltage power pin is the one that supplies the power to the logic gate that drives the data input pin. Similarly, this will also check that the power which connected to the output voltage power pin is the one that supplies the power to the logic gate which is driven by the output pin.

-IGNORE_HIGH_TO_LOW [<tolerance>]

If no tolerance is specified, no check for level shifters from high to low will be done. If a tolerance is specified, only voltage crossings where the difference is greater than the tolerance will be checked for level shifters.

-IGNORE_LOW_TO_HIGH [<tolerance>]

If no tolerance is specified, no check for level shifters from low to high will be done. If a tolerance is specified, only voltage crossings where the difference is greater than the tolerance will be checked for level shifters.

-REPort_file <filename>

Reports additional information related to statistics of power shutoff related logic, power domain crossings, or any issues encountered when processing the design.

-NO_SWITCH_CHAIN_checks

Does not activate additional structural checks on the power and ground switch networks. This is the default.

-SWITCH_CHAIN_checks

Activates additional structural checks on the power and ground switch networks.



-MAX_PMOS_stack_depth <<number> | OFF>

Note: This is only used by transistor level checks when running the Conformal Low Power GXL license.

<number> specifies the maximum allowed length of PMOS transistor stacks comprised of source-drain series connections until they reach a power net.

Specifying OFF disables the check for the PMOS transistors. PMOS stacks exceeding the specified length are reported as SPI3 violations.

-MAX_NMOS_stack_depth <<number> | OFF>

Note: This is only used by transistor level checks when running the Conformal Low Power GXL license.

<number> specifies the maximum allowed length of NMOS transistor stacks comprised of source-drain series connections until they reach a ground net.

Specifying OFF disables the check for the NMOS transistors. NMOS stacks exceeding the specified length are reported as SPI3 violations.

-NO_COALESCE_STACK_VIOLATIONS

Specifies that multiple stack length violations that are fully contained within the same library cell will be reported as multiple SPI3 violations for the same cell, one for each instance of the cell. This is the default.

-COALESCE_STACK_VIOLATIONS

Specifies that multiple stack length violations that are fully contained within the same library cell will be reported as a single SPI3 violation.

-LP_CTRL_TREE_CHECK

Checks all buffers in the path between two power domain functions and flags all buffers that can be OFF or ON when not expected. This is the default.

-NO_LP_CTRL_TREE_CHECK

Disables the path buffer checking.



-NO_LOCAL_constants

Specifies that the constants, such as 1’b0 and 1’b1, be considered to be connected in the instance they appear. For example, if a net is assigned 1’b1 in an instance I0, the power domain of the signal’s driver is considered to be the power domain of instance I0.

This option is the default for physical netlists, which have power and ground connectivity.

-LOCAL_constants Specifies that the constant will be moved to its load. As a result, the physical wiring of this signal will virtually disappear. Its load pins will be connected to the power or ground rail of the load instance. This way, the constant is available when it is needed. This is more efficient as it avoids unnecessary routing and sometimes, unnecessary isolation cells to isolate such signals, when they cross power domains.

This option is the default for logical netlists.

-NO_CLONE_check Disables checking for cloned isolation or level-shifter cells. This is the default.

-CLONE_check Enables checking for cloned isolation or level-shifter cells.

Two isolation cell instances are considered to be clones if they have the same driving net, branch out to the same destination power domain, have the same isolation control signal, and are of the same isolation type. In this case, you can replace a pair of cloned isolation cells with a single isolation cell.

Two level-shifter cells instances are considered to be clones if they have the same driving net, and branch out to the same destination power domain. In this case, you can replace a pair of cloned level shifter cells with a single level shifter cell.



-PASS_DATA_BUF Enables data path buffer checking.

Buffers might be inserted in power domains that are not compatible with the driver or receiving power domains. Incorrect buffer insertion can cause subsequent unnecessary insertion of isolation cells and unnecessary isolation cell insertion can change the desired design function.

This check is designed to catch incorrect buffer insertion. It checks functional crossing (same as before insertion), checks buffering path independently, and makes domain crossing checking compatible between pre- and post- place and route netlists.

-POWER_VOLTAGE_TOLERANCE <min:max>

Specifies that for crossings where the driver power voltage minus the receiver power voltage is below the specified <min>, it requires a shifter which supports low to high power shifting. Crossings where the driver power voltage minus the receiver power voltage is above the specified <max>, it requires a shifter that supports high-to-low power shifting

-GROUND_VOLTAGE_TOLERANCE <min:max>

Specifies that for crossings where the driver ground voltage minus the receiver power voltage is below the specified <min>, it requires a shifter which supports low to high ground shifting. Crossings where the driver ground voltage minus the receiver ground voltage is above the specified <max>, it requires a shifter that supports high-to-low ground shifting.

-CHECK_FLOATING_OUTPUT_INSTANCE

Enables low power checking on the low power instances with floating outputs. Without this option, the software gives a warning message for the low power instance with a floating output, (for example, ISO3.3 for the floating isolation instance) instead of checking the electrical issues on those instances. This is the default.

-NO_CHECK_FLOATING_OUTPUT_INSTANCE

Report low power instances with floating outputs as a warning message without checking the electrical issues on those instances.

-NO_SKIP_LIB_CELL_VOLTAGE_CHECK



Example

With the following command, any crossing from 1.2 to 1.0 will be ignored, but a crossing from 1.2 to 0.8 will be flagged:

set lowpower option -ignore_high_to_low 0.2

Related Commands

ADD ISOLATION CELL

ADD LEVEL SHIFTER

ADD RETENTION CELL

Checks the voltage of library cells while doing low power cell insertion. This is the default.

-SKIP_LIB_CELL_VOLTAGE_CHECK

Skips checking the voltage of library cells while doing low power cell insertion.



UPDATE POWER DOMAINUPDate POwer Domain

<domain_name> [-APPend <-INStance | -MODule> <name*> ... ][-POWer_net <power_net_name>][-GROund_net <ground_net_name>](Setup Mode)

Modifies a power domain previously defined with the ADD POWER DOMAIN command.

CPF Command Equivalent: update_power_domain

Parameters

Note: You must specify at least one of the following options for this command to have any affect.

Related Commands

ADD POWER DOMAIN

DELETE POWER DOMAIN

REPORT POWER DOMAIN

<domain_name> Specifies the name of the power domain to modify.

-APPend <-INStance | -MODule> <name*> ...

Associate instances to this power domain. These instances will be assumed to be part of this power domain.

-POWer_net <power_net_name>

Specify the power net of this power domain. The power net can be an always-on power net or an internally switched power net.

-GROund_net <ground_net_name>

Specify the ground net of this power domain. The ground net can be an always-on ground net or an internally switched ground net.


../cpf_ref/reference.html#update_power_domain


VALIDATEVALidate

(Verify Mode)

For low power:

Verifies low power functional checks.



VALIDATE PATH RULEVALidate PAth Rule


Validates path rules defined by the ADD PATH RULE command.

Related Command

ADD PATH RULE

DELETE PATH RULE

REPORT PATH RULE



VALIDATE TRANSISTOR STRUCTUREVALidate TRansistor Structure

[-PRINTMAPping | -PRINTCELLPOWERPINS](Verify Mode)

Checks several pre-defined rules at the transistor level. Definitions of these rules are:

■ Rule SPI1: Unbuffered input pin

Reports any input pin of a cell which drives non-gate pin(s) of a MOS.

■ Rule SPI3: Max-stacking

Reports any PMOS stack or NMOS stack whose length is greater than the user-specified limit.

A PMOS stack is a pull-up (to power) PMOS stack can only consists of PMOS transistors, starting from power and ending at gate pin of a MOS. An NMOS stack is a pull-down (to ground) NMOS stack can only consists of NMOS transistors, starting from ground and ending at gate pin of a MOS.

You can use the following command to specify the stack length limit:

■ SET LOWPOWER OPTION

❑ -MAX_NMOS_STACK_DEPTH <number> to specify the NMOS stack limit

❑ -MAX_PMOS_STACK_DEPTH <number> to specify the PMOS stack limit

Parameters

Examples

The following shows an example output when the command’s parameters are set:

■ -PRINTMAPping

// Map design module FOO to implementation module FOO// Map design module BAR to implementation module BAR

-PRINTCELLPOWERPINS Lists power pin connection of each instance by cell.

-PRINTMAPping Lists the mapping from design cells to spice cells.

-PRINTCELLPOWERPINS Lists power pin connection of each instance by cell.



// Map design module XYZ_ver to implementation module XYZ_spi// PROGRESS: Mapping complete. Time = 0.00 sec.

■ -PRINTCELLPOWERPINS

// ================= Power Pin Cell Connections =================// Module FOO instace /FOO_inst pin VSS is driven by power/ground net VSS.// Module FOO instace /FOO_inst pin VDD is driven by power/ground net VDD.// ==============================================================

The following is an example dofile:

set undefined cell black_boxset spice option -nobulkread library -verilog foo_lib.vread des top_foo.v -root topread lib -SPICESPACE -spice foo_lib.spi

add power pin VDD_GLOBAL 1.0 VDDadd ground pin GROUND VSS

set lowpower option -LIMIT_SPI3_PATHSset lowpower option -MAX_NMOS_STACK_DEPTH 4 -MAX_PMOS_STACK_DEPTH 3

analyze power domainvalidate transistor structure -printmapping -printcellpowerpinsreport rule check -lp -verbose

Related Command

SET LOWPOWER OPTION

REPORT RULE CHECK -lp



WRITE POWER_GROUND PORTSWRIte POwer_ground Ports

<filename>[-NOReplace | -REPlace](Setup Mode)

Writes out the power and ground ports of library cells as defined by LEF, user commands, or as found by the software to a file.

The power and ground ports are written using the ADD CELL PORT command, so this file can be read back into the software as an additional dofile to define the power and ground ports of library cells in subsequent runs of the software.

Parameters

Related Commands

ADD CELL PORT



<filename> Specifies the name of the file.

-NOReplace Does not overwrite the specified <filename> file if it exists.

-REPlace Overwrites the specified <filename> file if it exists.



WRITE POWER INTENTWRITE POWER INTENT

<filename> [-CPF [-DESign | -LIBrary | -MACRO_model][-INTEGRATED [-NO_OPTIMIZATION] | -HIERarchical][-MODule [<module_name>][-REPlace](Setup Mode)

Writes out power design intent to a specified output file.

Parameters

<filename> Specifies the name of the output file.

-CPF Specifies that the file is in Common Power Format (CPF).

-DESign Writes out design models. This is the default.

-LIBrary Writes out power intent for library cells.

-MACRO_model Writes out macro models.

-INTEGRATED Results in a flattened output power intent file, using the power intent integrator. This is default when power intent design is written out.

-NO_OPTIMIZATION During integration, do not optimize unnecessary level shifters, isolation, or state retention rules when reconfiguring power modes.

Note: Only valid with the -integrated option.

-HIERARCHICAL Results in a hierarchical design power intent file.

[-MODule [<module_name>]

Defines the module for which to write out power intent.

Power intent must be defined for that module; otherwise, this option will not write out power intent for that module.

-REPlace Replaces the specified <filename> file if it already exists.



Related Commands

COMMIT POWER INTENT

READ POWER INTENT

WRITE POWER INTENT


Encounter Conformal Low Power Extended Checking Reference ManualLow Power Rule Checks

3Low Power Rule Checks

Definitions for Conformal low power rules are explained in the following sections. This chapter includes the following topics:

■ Introduction to Low Power Messages on page 156

Rule Categories

■ Power Domains on page 157

■ Power Switches on page 189

■ Ground Switches on page 213

■ Isolation Cells on page 232

■ Always-on Cells on page 289

■ Retention Cells on page 297

■ Level Shifter Cells on page 316

■ Structural on page 342

■ Decoupled Capacitors on page 347

■ Path Rules on page 350

■ Clamp Rules on page 354

■ Circuit Rules on page 358

■ SPICE Rules on page 367

■ Macro Rules on page 376

■ Low Power Cell Rules on page 381



Introduction to Low Power Messages

Low power messages indicate any errors encountered when running the Conformal Low Power software. Low Power Rule Checks are active as the system mode changes from Setup to Verify.

Violation Severity Levels

There are three levels of severity for rule violations. The severity levels are listed below from the most serious to the least serious:

■ Error: Conformal Low Power might not allow you to begin verification until you resolve the error.

■ Warning:Conformal Low Power allows you to begin verification; however, it warns you of potential errors in the design.

■ Note:Conformal Low Power provides information on how the software interpreted the command, and the actions that have been taken in response to the command.

You can run the REPORT RULE CHECK -LP command to view a summary or expanded report (using the -verbose option) of all low power rule violations.

Additionally, you can specify the category of rules you would like to view with the following command. Use the asterisk (*) following a prefix to list rules of the specified category. For example:

report rule check STRC* -summary

To view information for a specific message, use the HELP command followed by the message ID.

HELp [message_id]

For example:

help PDM1



Power Domains

The following lists the Power Domain (PDM) rule checks:

■ PDM1 on page 159

■ PDM1a on page 160

■ PDM1b on page 161




■ PDM2c on page 166







■ PDM4d on page 173

■ PDM4e on page 174

■ PDM4f on page 175













■ PDM_BUF1 on page 186





PDM1

Message

Power domain of the instance is unknown

Default Severity

Error

Description

The power domain of the instance cannot be determined after analyzing the power domain.

In physical netlists, this is likely caused by incorrect power net connections. Check if the power pin of the instance is connected to a power net correctly. Also check if there are missing power pin or power switch definitions.

In logical netlists, this is due to the instance not being covered by any power domain defined using the ADD POWER DOMAIN command. Check if there are any missing power domain definitions.



PDM1a

Message

Primary port has no power domain. Use power association to assign a power domain

Default Severity

Warning

Description

This error is issued when the power domain of a primary I/O port is not defined. Under such a condition, the low power checks cannot be performed accurately. To fix this issue, use the ADD POWER ASSOCIATION command to associate a power domain with each of the reported primary I/O ports. This is the power domain where the signal is connected outside the current design.

Example

In this example, dotted lines represent the portion of the circuit outside the design. Net N connects to an always on domain D_ON outside the design. However, this cannot be determined by the software since the portion outside the current design is not visible to the software. So, the output port O must be associated with D_ON for the software to catch the invalid power domain crossing, from switchable domain D_SW to D_ON, at output port O.

To associate output port O with power domain D_ON, use the following command:

add power association -pin O -domain D_ON

Note: D_ON must be defined before using it in this command.

output port 0

I1

Domain: D_ON

i0

Domain: D_SW

outside the design

net N



PDM1b

Message

Always on cell has multiple drivers from different domains

Default Severity

Error

Description

The input of a cell that is defined as an “always on cell” is driven by multiple drivers that have different domains. The cell’s domain is considered “undefined” when the netlist does not have power/ground connectivity, unless “identify secondary domain” is applied to the instance.

Even if “identify secondary domain” is applied or the domain is derived from power/ground connecitivity, having multiple drivers on the same net can result in a serious electrical issues (such as a power to ground short) and should be analyzed by the designer for appropriate action.

This rule applies to synthesized gate netlists with or without power/ground connectivity. This check is performed by the ANALYZE POWER DOMAIN command.

Example

None.



PDM2

Message

Instance with multiple power domains

Default Severity

Error

Description

The instance is powered by multiple power domains. This rule only applies to physical netlists. This error occurs if there are multiple power nets connected to an instance and the instance has not been defined as a special low power cell and is not a black box.

To correct this problem, check if there is any missing low power cell definition. Also check if the netlists has modules with multiple power net connections and containing explicit primitive instantiations. In the later case those primitive instances will violate this rule.

Example

VDD VDD

OK

PDM2



PDM2a

Message

Black box instance pins have multiple power domains, use power association to assign power domains

Default Severity

Error

Description

The black box has multiple power domains, and there is no power association associating a single power to the pin.

Note: PDM2 is not generated for black boxes. For black boxes, only PDM2a is generated. PDM2 is for library cells only.



PDM2b

Message

Net driven by multiple power domains

Default Severity

Error

Description

A net is driven by instances with different power domains. This means that there are more than one output or inout pins with different power domains driving the same net.

To correct this, check if the net should be connected to the instance of different power domains. In some cases, if the net cannot be driven simultaneously by different domains, this error can be ignored.

Example

In the following example, net pin I0/Y and I1/Y are output pins of instances with power domains D0 and D1, respectively. So, net ‘n’ is driven by two different power domains, and a PDM2b violation will be flagged for this net. ISO7 will also be flagged for the crossing from I1/Y to I2/Y.

I0

Domain: D0

I1

Domain: D1

Y

Y

n I I2

Domain: D0



In the following example, net ‘n’ is driven by two different power domains as in the previous example. However, there is no ISO7 error issued for this case. A PDM2b violation will be flagged for this net.

I0

Domain: D0

I1

Domain: D1

Y

Y

n



PDM2c

Message

Net or Pin tied to 1’b0 or 1’b1

Default Severity

Warning

Description

In a netlist with complete power and ground connectivity, there should be no connections to constant values. Each constant value should be replaced with a connection to a power or ground net, or alternatively to the output of a tie-high or tie-low cell.

Examples

Example 1

In a Verilog netlist, if you have:

wire k;

assign k = 1’b1 ;

You might get an error if net k net drives other logic, because it is not clear which power net will drive the net k.

Example 2

In a Verilog netlist, if you have:

SC_AND2 andCellInst (.VDD(VDD), .VSS(VSS), .A(1’b1), .B(bin), .C(out));

You will get this error because it is not clear which power will drive input pin A.



PDM3

Message

Power input pin of a power domain instance is not connected to a power pin

Default Severity

Error

Description

The power input pin specified by the ADD POWER DOMAIN -power command is not connected to a top-level power pin. The Conformal software looks for the power attribute in the ADD POWER DOMAIN command, and checks for the connectivity of the pin in the design to check that the power pin does not connect to any power signal. This rule only applies to physical netlists.

To fix this problem, check the power pin connections of the instances specified in the ADD POWER DOMAIN command.



PDM3a

Message

Ground input pin of a power domain instance is not connected to a primary ground port

Default Severity

Error

Description

The ground input pin specified by the ADD POWER DOMAIN -ground command is not connected to a top-level power pin. The Conformal software looks for the ground attribute in the ADD POWER DOMAIN command, and checks for the connectivity of the pin in the design to check that the ground pin does not connect to any ground signal. This rule only applies to physical netlists.

To fix this problem, check the ground pin connections of the instances specified in the ADD POWER DOMAIN command.



PDM4

Message

Power net connected to the data pin of a library cell powered by the same power net

Default Severity

Warning

Description

The power net tied directly to a library cell data input and a power net of a circuit inside a cell at that port is the same net. It is not through a tie off cell.

To fix this problem, connect the data input pins to the output of a tie-high cell. For example, the PDM4 message is issued if VDD is the power net and it connects directly to the data pin.

Example

In the following diagrams, Figure 1 shows an incorrect connection where power net VDD1 is connected directly to the data input of the buffer. This will generate a PDM4 error. Figure 2 shows how to drive the data input high using a tie-high cell to fix this error.

Figure 1

VDD1 Y

Figure 2

VDD1

YTIE-HIGHCELL

Data High



PDM4a

Message

Ground net connected to the data pin of a library cell

Default Severity

Warning

Description

The ground net is tied directly to a data pin and not through a special tie cell.

To fix this problem, connect the data input pins to the output of a tie-low cell. For example, the PDM4a message is issued if VSS is the ground net and it connects directly to the data pin.



PDM4b

Message

Power net driven by an output port of a regular library cell

Default Severity

Error

Description

The output port of a regular cell is connected to a power net. This can create functional failures and can potentially create static short circuit current between the power and ground nets through a transistor that is turned on. Only power switch output ports are allowed to drive a power net.

To fix this issue, first check if the cell is a power switch. If it is a power switch, define the cell with the ADD POWER SWITCH command. If it is a regular cell, reconnect the output port properly.



PDM4c

Message

Ground net driven by an output port of a regular library cell

Default Severity

Error

Description

The output port of a regular cell is connected to a ground net. This can create functional issues and can potentially create static short circuit current between the power and ground nets through a transistor that is turned on.



PDM4d

Message

Power pin of a library cell is not connected to a power net

Default Severity

Error

Description

The power pin of a library cell is not connected to a power net. The cell might not function properly if it is not powered correctly.

To fix this issue, see the reported instance’s power pin. Connect the power pin to a power net.



PDM4e

Message

Ground pin of a library cell is not connected to a ground net

Default Severity

Error

Description

The ground pin of a library cell is not connected to a power net. The cell might not function properly if its ground pin is not grounded correctly.

To fix this issue, see the reported instance’s ground pin. Connect the ground pin to a ground net.



PDM4f

Message

Power net of a different domain connected to the data pin of a library cell

Default Severity

Warning

Description

The Power net tied to a library cell data input and a power net of a circuit inside a cell at that port are different.



PDM5

Message

Assigned power domain of instance is different from actual power domain

Default Severity

Warning

Description

The power domain of the power and ground nets, that are connected to a blackbox instance that is not defined as a macro model, is different than the power domain defined by create_power_domain -name <> -instances <bbox_inst_name>. This means that the functional and physical domain of that blackbox is different and can have issues if the blackbox contains state elements (flip flops or latches)

Use the report rule check PDM5 -verbose command to view information on the instance and the conflicting power domains.

Applicability

This check is performed on a place-and-route gate netlist with power and ground connectivity.



PDM6

Message

External shutoff condition can be off

Default Severity

Error

Description

The domain of a driver to a shutoff condition of an externally-switched domain can be OFF when the base domain to the switched domain is ON in one or more power modes.

Use the report rule check PDM6 -verbose command to view information on the power domain, shutoff condition driver, and to review the power modes. From this information, you can determine whether the domains are defined correctly, the power modes are correct, or the control driver is in the incorrect domain.

Applicability

Synthesized and place-and-route gate netlists with low power cells inserted



PDM7

Message

One or more crossings between 2 power domains have same nominal conditions but different ground. They do not have a level shifter inserted. The designer should check to see if a level shifter is required.

Default Severity

Warning

Description

A ground net from one domain drives into another domain. When the ground net of the driver is different than that of the receiver domain, you might need a ground level shifter to protect the crossing from ground-supply variations.

Use report rule check PDM7 -verbose to review the domain crossing and the ground nets for those domains to see if a level shifter is required to protect the crossing.

Applicability

Analysis of design netlists with power and ground connectivity.



PDM7a

Message

One or more crossings between 2 power domains have same nominal conditions but different ground.

Default Severity

Warning

Description

A ground net from one domain drives into another domain and this crossing has a level shifter inserted. When the ground net of the driver is different than that of the receiver domain, you might need a ground level shifter to protect the crossing from ground-supply variations.

Use report rule check PDM7a -verbose to review the domain crossing and the ground nets for those domains to see if the level shifter is required to protect the crossing.

Applicability




PDM7b

Message

One or more crossings between 2 power domains have same nominal conditions but different ground. Their source to tied to 0 and they do not have a level shifter inserted. The designer should check to see if a level shifter is required.

Default Severity

Warning

Description

A tied logic 0 from one domain drives into another domain. When the ground net of the driver is different than that of the receiver domain, you might need a ground level shifter to protect the crossing from ground-supply variations.

Use report rule check PDM7b -verbose to review the domain crossing and the ground nets for those domains to see if a level shifter is required to protect the crossing.

Applicability

Analysis of design netlists without power and ground connectivity



PDM7c

Message

One or more crossings between 2 power domains have same nominal conditions but different ground.

Default Severity

Warning

Description

A tied logic 0 from one domain drives into another domain and this crossing has a level shifter inserted. When the ground net of the driver is different than that of the receiver domain, you might need a ground level shifter to protect the crossing from ground-supply variations.

Use report rule check PDM7c -verbose to review the domain crossing and the ground nets for those domains to see if the level shifter is required to protect the crossing.

Applicability




PDM8

Message

One or more crossings between 2 power domains have same nominal conditions but different power. They do not have a level shifter inserted. The designer should check to see if a level shifter is required.

Default Severity

Warning

Description

A power net from one domain drives into another domain. When the power net of the driver is different than that of the receiver domain, you might need a power level shifter to protect the crossing from power-supply variations.

Use report rule check PDM8 -verbose to review the domain crossing and the power nets for those domains to see if a level shifter is required to protect the crossing.

Applicability




PDM8a

Message

One or more crossings between 2 power domains have same nominal conditions but different power.

Default Severity

Warning

Description

A power net from one domain drives into another domain and this crossing has a level shifter inserted. When the power net of the driver is different than that of the receiver domain, you might need a power level shifter to protect the crossing from power-supply variations.

Use report rule check PDM8a -verbose to review the domain crossing and the power nets for those domains to see if the level shifter is required to protect the crossing.

Applicability




PDM8b

Message

One or more crossings between 2 power domains have same nominal conditions but different power. Their source is tied to 1 and they do not have a level shifter inserted. The designer should check to see if a level shifter is required.

Default Severity

Warning

Description

A tied logic 1 from one domain drives into another domain. When the power net of the driver is different than that of the receiver domain, you might need a power level shifter to protect the crossing from power-supply variations.

Use report rule check PDM8b -verbose to review the domain crossing and the power nets for those domains to see if a level shifter is required to protect the crossing.

Applicability




PDM8c

Message

One or more crossings between 2 power domains have same nominal conditions but different power. Their source is tied to 1.

Default Severity

Warning

Description

A tied logic 1 from one domain drives into another domain and this crossing has a level shifter inserted. When the power net of the driver is different than that of the receiver domain, you might need a power level shifter to protect the crossing from power-supply variations.

Use report rule check PDM8c -verbose to review the domain crossing and the power nets for those domains to see if the level shifter is required to protect the crossing.

Applicability




PDM_BUF1

Message

Power domains of a buffer tree between two functions are not compatible with source or receiving function power domain

Default Severity

Error

Description

A buffer or buffer chain between a driving function and a receiving function is not in a power domain that is consistent with the driving function domain. This can happen when buffer insertion on nets that feedthru domains that are unrelated to the driving domain is performed using normal buffers and not "always on" buffers. Check the verbose message to identify the instances of the buffers.

Example

In this example, two buffers are placed on a feedthru wire in a switchable domain that is between a driver and receiver in the "aon" domain, which is not switchable.

The resulting verbose error report:

PDM_BUF1: Power domains of a buffer tree between two functions are not compatiblewith source or receiving function power domain.Severity: Error Occurrence: 11: Source power domain aon at x1/x01/Y ->Receiving power domain aonLeaf load: YIncompatible buffers/inverters:x3/x01x2/x01



PDM_BUF2

Message

Voltages of a buffer tree between two functions are not compatible with source or receiving function voltage.

Default Severity

Error

Description

Buffering happens in two unrelated domains (unless the buffers are always_on), when the nominal conditions of the unrelated domains are different than that of the driving and receiving domain’s nominal conditions. This can cause a domain crossing situation.

Use report rule check PDM_BUF2 -verbose to get details on the buffer instances and the driver and receiving domains.

Applicability

Synthesized or place and route netlists with low power cells inserted.



PDM_BUF3

Message

Bad power domain crossing between buffers in a buffer tree

Default Severity

Error

Description

There is a bad power domain crossing between two buffers in a buffer tree. It could be that all the buffers are compatible with both the driving and receiving domain, but there is a condition where the domains are at different voltage conditions in one or more power modes; or, the driving buffer is OFF, but the receiving buffer(s) is/are ON.

Review the verbose error report to identify the buffer (or inverter) instances.



Power Switches

The following lists the Power Switch (PSW) rule checks:

■ PSW1 on page 190

■ PSW1a on page 191




■ PSW4a on page 195



■ PSW7.1 on page 198







■ PSWRULE1.1 on page 206









PSW1

Message

Power input pin of power switch is not connected to a primary power port

Default Severity

Error

Description

The input power pin of the power switch instance is not connected directly to a defined power pin. To fix this error, check the input power pin connectivity of the power switch and make sure all power pins are defined correctly.



PSW1a

Message

Ground pin of power switch is not connected to a non-switchable ground net

Default Severity

Error

Description

This error can occur when the ground net connected to the ground port of a power switch is connected to the output of a ground switch or a top-level ground port defined with a standby expression. The internal circuit controlling the power switch will malfunction and cause the power switch output to be unknown.



PSW2

Message

Power port supplying switch internal control logic can be OFF when the primary switch power input port is ON

Default Severity

Error

Description

This error occurs when the power net connected to the power switch power port defined by the ADD POWER SWITCH command’s -control_power <power_port> option is OFF when the input power net of the power switch is ON.



PSW3

Message

Power port supplying switch internal control logic has a lower voltage that the switch input voltage

Default Severity

Error

Description

This error occurs when the power net connected to the power switch power port defined by the ADD POWER SWITCH command’s -control_power <power_port> option has a voltage level higher or lower than the driver of the input port that controls the power switch.



PSW4

Message

Power switch enable pin can be OFF when input power is ON

Default Severity

Error

Description

The power domain of the power switch enable pin can be off when the switch input power is on. This means that the switch enable is driven by an instance whose power can be turned off when the input power of the switch is on.

This is a serious issue and must be corrected. The switch enable must come from a power domain that is ON whenever the switch input power is ON. Typically, it should come from an always-on power domain.



PSW4a

Message

Power switch enable pin is tied to a constant value

Default Severity

Error

Description

The enable pin of the power switch is tied to a constant net—that is, a power or ground net, or it is tied to 1’b0 or 1’b1.



PSW5

Message

Voltage of the power switch enable driver exceeds maximum limit

Default Severity

Error

Description

Indicates that the voltage of the net connected to the power switch enable pin is higher than the voltage of the input power net plus the allowable threshold specified with the ADD POWER SWITCH command’s -max_enable_bias option.

If a higher voltage at the switch enable pin is acceptable for this switch, use the -max_enable_bias option to allow voltages higher than the input voltage up to the desired threshold.

If the ADD POWER SWITCH command’s -control_power option is specified when adding the power switch, the voltage of the net connected to the enable pin is compared against the voltage that is specified with the -control_power option, instead of the voltage of the input power net.



PSW6

Message

Power switch output is floating

Default Severity

Error

Description

The output of the power switch is not connected to any load. This is most likely an error in connection of the power switch output.

To correct this problem, determine the power net that this switch must drive, and connect the power switch output pin to that power net.



PSW7.1

Message

Enable output of power switch fans out to enable pins of multiple power switches

Default Severity

Error

Description

The net connected to the enable output pin of the power switch drives enable pins of multiple power switches. The enable output net should drive only one enable pin in a daisy-chain. This is to ensure that the switches are turned ON one by one in a controlled manner.

Note: This is checked only for the stage 2 enable output.

Example

In the following figure, the enable output from power switch i0 fans out to the enable inputs of power switches i1 and i2. As a result, the software will issue message PSW7.1:

i0

Ei1 Eo1

E02 Eo2i1

Ei1 Eo1

Eo2Ei2

i2

Ei1 Eo1

Eo2Ei2



PSW7.2

Message

Enable input of power switch has multiple drivers

Default Severity

Error

Description

The signal connected to the enable input pin of the power switch has multiple drivers. The enable signal should have a single driver, coming from the power control module or the enable output pin of another power switch in the same switch network.

Example

In the following figure, the enable input of power switch i2 is driven by both enable outputs of power switches i0 and i1. As a result, the software will issue message PSW7.2:

i2

EoEi

PSW

i0

EoEi

PSW

i1

EoEi

PSW



PSW7.3

Message

First power switch in the network cannot be identified

Default Severity

Error

Description

The power switches in a switch network supplying power to a switchable power domain should be daisy chained. The head of such a switch network should have its switch enable connected to a control signal coming from the power control module. The enable pins of other switches in that network should be driven by the enable out pins of the previous switches in the network.

This error indicates that there is a combinational loop in the enable signals, and so the head of the switch network could not be identified by the tool. To correct the error, explore the switches in the network, and connect the enable signal of one switch to a signal coming from the power control module that turns the power ON for the output domain of this switch network.

This error is generated for a network of power switches that have the same input power net and the same output power net.

Example

In the following figure, the enable signals of power switches i0 and i1 form a loop, and there is no head of this power switch network. As a result, the software will issue message PSW7.3:

i0

EoEi

PSW

i1

EoEi

PSW



PSW7.4

Message

Power switch network has multiple stage1 heads

Default Severity

Error

Description

This error is generated for a network of power switches that have the same input power net and the same output power net. The heads of this network are switches whose enable signals are driven by the power control module.

This error is issued if there are multiple heads for such a switch network.

Example

In the following figure, both power switches i0 and i1 have their enable (EN) signals coming from the power control module, so they are both identified as the heads of the power switch network comprised of power switches i0, i1, and i2. As a result, the software will issue message PSW7.4:

i2

EoEi

PSW

i0

EoEi

PSW

i1

EoEi

PSW

EN

PowerControlModule



PSW7.5

Message

Enable pin of power switch is part of a feedback loop

Default Severity

Error

Description

This error indicates that the enable pin of the power switch is in a combinational loop with the other stage 1 or stage 2 enable pins of the same switch network.

Note: This error can occur even when the head of the switch network can be identified.

Example

In the following figure, the enable signals of power switches i1 and i2 form a loop, even though the head of the power switch network i0 could be identified. As a result, the software will issue message PSW7.5 for i1 and i2:

i0

EoEi

PSW

PowerControlModule

i1

EoEi

PSW

i2

EoEi

PSW



PSW7.6

Message

Stage2 enable input of power switch is activated before its stage1 enable input

Default Severity

Error

Description

This error is issued when the stage2 enable pin of a power switch is activated before its stage1 enable pin.

Note: This is checked only if a the control signal for the stage2 enable pin is not specified in a switch rule that matches this power switch network.

The enable signal should pass through its stage1 enable pin, and then feed back into its stage2 enable pin, so that the stage1 switch is enabled prior to enabling the stage2 switch in the switch cell.

Example

In the following figure, the stage2 enable pin of power switch PSW2 is activated before its stage1 enable pin. As a result, the software will issue message PSW7.6:

PSW1

Eo1Ei1

Eo2Ei2

PSW2

Eo1Ei1

Eo2Ei2



The connection should look like this:

PSW1

Eo1Ei1

Eo2Ei2

PSW2

Eo1Ei1

Eo2Ei2



PSW7.7

Message

Enable output of power switch drives enable input of a power switch in a different group

Default Severity

Error

Description

This error is generated when the enable output pin of a power switch drives the enable input pin of a power switch belonging to a switch group that supplies power to a different domain.

The enable signal for the switch that is supplying power to a different switchable power domain should come from the power control module, or the stage enable output pin of some switch in its own switch network, supplying power to the same output power domain.



PSWRULE1.1

Message

Power switch does not match any switch rule

Default Severity

Error

Description

A power switch instance does not match any switch rule. The domain, external power net, and the enable conditions are used to identify the switches associated with a rule and when one or more do not match, this error can result.

Use report rule check PSWRULE1.1 -verbose to get details on the power switch instance and check the switch rules associated with that domain. Use report pin driver -cell <name> <enable> -path -verbose to get a listing of the enable drivers, there might be a scan mux inserted in the control path.

Applicability

Place and route netlists with low power cells inserted.



PSWRULE1.2

Message

Power switch rule does not match any power switch

Default Severity

Error

Description

The switch rule does not match any switch instance in the design. This could mean that the switch rule is not implemented correctly.



PSWRULE1.3

Message

Power switch rule does not have consistent input power and output power

Default Severity

Error

Description

The internal switched domain specified in the switch rule does not have the consistent voltage value with the source power.

Example

In the following figure, PSWRULE1.3 is reported when power net VDD and power net VSW have inconsistent voltage values. The voltage setting for power net VDD which drives the switch cell input power port is 1.0, but power net VSW which is driven by the switch cell output power port voltage value is {1.0:1.2}:

Ri

Ei

Ro

Eo

VIN

VOUT

VDD

VSW

SwitchedDomain



PSWRULE1.4

Message

Acknowledge receiver signal is not driven by the output pin of the last power switch instance

Default Severity

Error

Description

Update power switch rule specifies how the enable of the last switch in the chain is connected to the design through the acknowledge receiver option and the polarity. If the switch as two enables, the rule specifies how each or both is connected.

Use report rule check PSWRULE1.4 -verbose to get a detailed report on the rule and the related design information. Use this command to check the design and switch rule.

Use report pin load on the enable instance’s stage output and determine to which pin(s) it connects. One possible cause for the error could be a name change during the insertion of a scan mux in the acknowledge path.

Applicability

Place and route netlists with power switching



PSWRULE1.5

Message

Acknowledge receiver signal is driven by multiple power switches

Default Severity

Error

Description

An instance pin specified with the UPDATE POWER SWITCH RULE command’s acknowledge receiver option is driven by more than one power switch enable output port.

Use report rule check PSWRULE1.5 -verbose to get details on the receiving pin and the instances driving it.

Applicability




PSWRULE1.6

Message

Acknowledge receiver and power switch output are inverted

Default Severity

Error

Description



The path between the switch output and the acknowledge pin might be unintentionally inverted or the update rule expression polarity might be incorrect.

Applicability




PSWRULE1.7

Message

Acknowledge receiver is driven through buffer/inverter which is not ON

Default Severity

Error

Description



The path between the switch output and the acknowledge pin has an inverter or buffer cell that can be OFF when the domain of the acknowledge receiver is ON.

Applicability

Place and Route netlists with power switching



Ground Switches

The following lists the Ground Switch (GSW) rule checks:

■ GSW1 on page 214

■ GSW1a on page 215

■ GSW4a on page 216

■ GSW6 on page 217

■ GSW7.1 on page 218







■ GSWRULE1.1 on page 226








GSW1

Message

Ground input pin of a ground switch is not connected to a primary ground port

Default Severity

Error

Description

The input ground pin of the ground switch instance is not connected directly to a defined ground pin. To fix this error, check the input ground pin connectivity of the ground switch and make sure all ground pins are defined correctly.



GSW1a

Message

Power pin of ground switch is not connected to a non-switchable power net

Default Severity

Error

Description

This error can occur when the power net connected to the power port of a ground switch is connected to the output of a power switch or a top-level power port defined with a standby expression. The internal circuit controlling the ground switch will malfunction and cause the ground switch output to be unknown.



GSW4a

Message

Ground switch enable pin can be OFF when input ground is ON

Default Severity

Error

Description

The enable pin of the ground switch is tied to a constant net—that is, a power or ground net, or it is tied to 1’b0 or 1’b1.



GSW6

Message

Ground switch output is floating

Default Severity

Warning

Description

The output of the ground switch is not connected to any load. This is most likely an error in connection of the ground switch output.

To correct this problem, determine the ground net that this switch must drive, and connect the ground switch output pin to that ground net.



GSW7.1

Message

Enable output of ground switch fans out to enable pins of multiple ground switches

Default Severity

Warning

Description

The net connected to the enable output pin of the ground switch drives enable pins of multiple ground switches. The enable output net should drive only one enable pin in a daisy-chain. This is to ensure that the switches are turned ON one by one in a controlled manner.

Note: This is checked only for the stage 2 enable output.

Example

In the following figure, the enable output from ground switch i0 fans out to the enable inputs of ground switches i1 and i2. As a result, the software will issue message GSW7.1:

i0

Ei Eo

GSW

i1

Ei Eo

GSW

i2

Ei Eo

GSW



GSW7.2

Message

Enable input of ground switch has multiple drivers

Default Severity

Error

Description

The signal connected to the enable input pin of the ground switch has multiple drivers. The enable signal should have a single driver, coming from the power control module or the enable output pin of another ground switch in the same switch network.

Example

In the following figure, the enable input of ground switch i2 is driven by both enable outputs of ground switches i0 and i1. As a result, the software will issue message GSW7.2:

i2

EoEi

GSW

i0

EoEi

GSW

i1

EoEi

GSW



GSW7.3

Message

First ground switch in the network cannot be identified

Default Severity

Error

Description

The ground switches in a switch network supplying power to a switchable power domain should be daisy chained. The head of such a switch network should have its switch enable connected to a control signal coming from the power control module. The enable pins of other switches in that network should be driven by the enable out pins of the previous switches in the network.

This error indicates that there is a combinational loop in the enable signals, and so the head of the switch network could not be identified by the tool. To correct the error, explore the switches in the network, and connect the enable signal of one switch to a signal coming from the power control module. that turns the ground ON for the output domain of this switch network.

This error is generated for a network of ground switches that have the same input ground net and the same output ground net.

Example

In the following figure, the enable signals of ground switches i0 and i1 form a loop, and there is no head of this ground switch network. As a result, the software will issue message GSW7.3:

i0

EoEi

GSW

i1

EoEi

GSW



GSW7.4

Message

Ground switch network has multiple stage1 heads

Default Severity

Error

Description

This error is generated for a network of ground switches that have the same input ground net and the same output ground net. The heads of this network are switches whose enable signals are driven by the power control module.

This error is issued if there are multiple heads for such a switch network.

Example

In the following figure, both ground switches i0 and i1 have their enable (EN) signals coming from the ground control module, so they are both identified as the heads of the ground switch network comprised of ground switches i0, i1, and i2. As a result, the software will issue message GSW7.4:

i2

EoEi

GSW

i0

EoEi

GSW

i1

EoEi

GSW

EN

PowerControlModule



GSW7.5

Message

Enable pin of ground switch is part of a feedback loop

Default Severity

Error

Description

This error indicates that the enable pin of the ground switch is in a combinational loop with other stage 1 or stage 2 enable pins of the same switch network.

Note: This error can occur even when the head of the switch network can be identified.

Example

In the following figure, the enable signals of ground switches i1 and i2 form a loop, even though the head of the ground switch network i0 could be identified. As a result, the software will issue message GSW7.5 for i1 and i2:

i0

EoEi

GSW

PowerControlModule

i1

EoEi

GSW

i2

EoEi

GSW



GSW7.6

Message

Stage2 enable input of ground switch is activated before its stage1 enable input

Default Severity

Error

Description

This error is issued when the stage2 enable pin of a ground switch is activated before its stage1 enable pin.

Note: This is checked only if a the control signal for the stage2 enable pin is not specified in a switch rule that matches this ground switch network.

The enable signal should pass through its stage1 enable pin, and then feed back into its stage2 enable pin, so that the stage1 switch is enabled prior to enabling the stage2 switch in the switch cell.

Example

In the following figure, the stage2 enable pin of ground switch GSW2 is activated before its stage1 enable pin. As a result, the software will issue message GSW7.6:

GSW1

Eo1Ei1

Eo2Ei2

GSW2

Eo1Ei1

Eo2Ei2



The connection should look like this:

GSW1

Eo1Ei1

Eo2Ei2

GSW2

Eo1Ei1

Eo2Ei2



GSW7.7

Message

Enable output of ground switch drives enable input of a ground switch in a different group

Default Severity

Error

Description

This error is generated when the enable output pin of a ground switch drives the enable input pin of a ground switch belonging to a switch group that supplies ground to a different domain.

The enable signal for the switch that is supplying ground to a different switchable power domain should come from the power control module, or the stage enable output pin of some switch in its own switch network, supplying ground to the same output power domain.



GSWRULE1.1

Message

Ground switch does not match any switch rule

Default Severity

Error

Description

The ground switch instance does not match any of the ground switch rules specified with the ADD SWITCH RULE commands. This could mean that the switch is extraneous or has incorrect connections.



GSWRULE1.2

Message

Ground switch rule does not match any ground switch

Default Severity

Error

Description

The switch rule does not match any switch instance in the design. This could mean that the switch rule is not implemented correctly.



GSWRULE1.4

Message

Acknowledge receiver signal is not driven by the output pin of the last ground switch instance

Default Severity

Error

Description


Use report rule check GSWRULE1.4 -verbose to get a detailed report on the rule and the related design information. Use this command to check the design and switch rule.

Use report pin load on the enable instance’s stage output and determine to which pin(s) it connects. One possible cause for the error could be a name change during the insertion of a scan mux in the acknowledge path.

Applicability

Place and route netlists with ground switching



GSWRULE1.5

Message

Acknowledge receiver signal is driven by multiple ground switches

Default Severity

Error

Description

An instance pin specified with the UPDATE POWER SWITCH RULE command’s acknowledge receiver option is driven by more than one ground switch enable output port.

Use report rule check GSWRULE1.5 -verbose to get details on the receiving pin and the instances driving it.

Applicability




GSWRULE1.6

Message

Acknowledge receiver and power switch output are inverted

Default Severity

Error

Description



The path between the switch output and the acknowledge pin may be erroneously inverted or the update rule expression polarity may be incorrect.

Applicability




GSWRULE1.7

Message

Acknowledge receiver is driven through buffer/inverter which is not ON

Default Severity

Error

Description



The path between the switch output and the acknowledge pin has an inverter or buffer cell that can be OFF when the domain of the acknowledge receiver is ON.

Applicability




Isolation Cells

The following table lists the Isolation Cell (ISO) rule check numbers and messages:

■ ISO1 on page 234

■ ISO1a on page 235


■ ISO3.1 on page 237

■ ISO3.1a on page 239

■ ISO3.1b on page 240






■ ISO4b on page 248

■ ISO4c on page 249

■ ISO4d on page 250

■ ISO4e on page 251

■ ISO4f on page 252











■ ISO6.5a on page 261




■ ISO7b on page 265







■ ISO_BUF1 on page 272

■ ISO_BUF2 on page 273

■ ISORULE1.1 on page 274





■ ISORULE1.5a on page 280


■ ISORULE1.6a on page 282








ISO1

Message

Invalid power pin connection

Default Severity

Error

Description

The net connected to the power pin, specified by the ADD ISOLATION CELL command, is not a valid power domain. For example, this message is flagged if a power pin is floating or not connected to a power net (nets connected to power switches or top-level power pins).



ISO1a

Message

Isolation instance power pins have different voltages

Default Severity

Error

Description

You cannot use a cell defined as an isolation cell with two power pins when both power pins are ON, and at different voltages. This message indicates there is a power mode where the domains of the power nets connected to the power pins are ON and at different nominal conditions.

Review the -verbose error message for the power modes and domain situations. If the power modes are correct, then the domain crossing needs to have both isolation and level shifter rules and the cell needs to be an enabled level shifter instead of an isolation cell.

Applicability

Applies to place-and-route gate netlists with power/ground connectivity.



ISO2

Message

Inputs of isolation cell have different power domains

Default Severity

Error

Description

Some isolation cells have a dedicated power pin which is powered on during the isolation. In such cases, the regular power pin must be connected to the same power net that powers the signals which drives the data input pin of the isolation cell.

Example



ISO3.1

Message

Isolation cell instance is not required in this path

Default Severity

Error

Description

The output of an isolation cell instance can fan out to either a single domain or multiple domains. If there is a path through the isolation cell’s data pin and output pin, where the isolation function is unnecessary, this message is issued.

The isolation function in a particular path can be unnecessary due to various reasons. Two common scenarios are as follows:

■ It is not possible to have the destination domain ON while the source is OFF, and you did not specify to require ON-to-OFF isolation. This likely happens if the destination power domain is a switched domain derived from the source power domain.

■ Power modes are defined and the isolation function is not needed in this path in any of the power modes. The software assumes that the defined power modes are the only modes in which the design operates.

Tip

The software will report more details in the verbose report of this violation (using the command report rule check ISO3.1 -verbose).

Example

The following diagram shows an isolation instance isoInst, whose output fans out to two logic gates i2 and i3 in domains D2 and D3, respectively. If domain D1 is switched and domain D3 is always on, and domain D2 is switched and derived from domain D1, the path i1 to isoInst to i2 does not require an isolation. The output of i1 could directly drive i2, bypassing the isolation instance.



Note: The isolation instance is required in the path i1 to isoInst to i3; therefore, the isolation instance cannot be removed from the circuit. Instead, it might be possible to bypass the isolation cell in the path i1 to isoInst to i2, and drive i2 directly from i1.

control

ISO i2

i3

domain D1

domain D3

domain D2

i1

data

isoInst



ISO3.1a

Message

The isolation function of combination isolation and level shifter cell is unused in this path

Default Severity

Warning

Description

This is a combination isolation and level shifter cell whose isolation function is not used in a path, but its level shifting function is required in the same path.

Note: The isolation function might be required in some other path through this isolation instance.

Example

In the following diagram, both domains D1 and D2 are always on, and isoInst is a combination isolation-level shifter cell. Because both D1 and D2 are always on, the isolation function is not required in the path i0 to isoInst to i1. However, because D1 is 1.0 V and D2 is 1.2 V, the level shifter function is in use. In this case, the isolation control should always be disabled so the data signal value is never isolated. This violation applies to a particular path through the isolation cell. If the isolation output fans out to multiple domains, the isolation function can be necessary in paths from i0 to other domains.

isoInst

ISO-LS

domain D1 = 1.0 V

i0

1.0 V

domain D2 = 1.2 V

i1

1.2 V



ISO3.1b

Message

Isolation instances with same driver and same destination domain

Default Severity

Warning

Description

This message is issued when multiple isolation instances are used for the same power domain crossing. This message is only issued after running the SET LOWPOWER OPTION -clone_check command.

If a power domain crossing signal has the same driver, and has multiple fanouts in another domain, and isolation cells are inserted in the fanout branches rather than the trunk, then this message can be issued.

The multiple isolation cells in the fanout branches must be of the same cell type, Sometimes different fanout target pins have different type of isolation requirement. In such cases, the multiple isolation cells in the branches cannot be combined. So, this message is flagged only for isolation instances in different branches that are also of the same cell type.

To fix this issue, change the connections to move the branching in the signal after the isolation instance.

Note: This is not possible when multiple isolation instances are required for providing additional drive strength.



Example

In the following example, the output net N from instance i0 fans out to two instances i1 and i2, both in domain DEST. The two isolation instances iso1 and iso2 have the same control signal and same module for this signal crossing.

In this case, it is better to combine the two isolation instances into one to save area and power, as shown in the following diagram:

control ISO

i0

data

iso1

net N

control

ISO

data

iso2

isolationcontrol

i1

domainDEST

domainSRC

i2

domainDEST

control ISO

i0

data

iso1

net N

isolationcontrol

i1

domainDEST

domainSRC

i2

domainDEST



ISO3.2

Message

Source and destination domains in this path are the same

Default Severity

Error

Description

The source destination power domains are the same in a path through the isolation cell, so the isolation cell can be bypassed in this path, and the logic driven by the isolation cell output can be directly driven by the input signal of the isolation cell instance.

In general, the isolation cell output can fan out to multiple domains, one of which is the source domain itself. In this case, the isolation cell might be required in some other paths through the isolation cell.

Example

In the following diagram, the path i0 to isoInst to i1 does not require the isolation function. In fact, i1 should be directly driven by i0 for timing reasons, and also for not clamping the



signal value within the same domain. However, the path i0 to isoInst to i2 might still require the isolation cell.

control

ISO i1

i2

domain D1

domain D2

domain D1

i0

data

isoInst



ISO3.3

Message

Isolation cell output is floating

Default Severity

Warning

Description

The isolation cell output is floating.



ISO3.4

Message

Back to back isolation cells detected

Default Severity

Warning

Description

Indicates that back to back isolation cells were detected. An output pin of an isolation cell drives only one input, which is an input pin of another isolation cell.



ISO4

Message

Power of isolation control pin can be OFF while isolation cell is ON

Default Severity

Error

Description

This check ensures that the isolation control signal is powered ON whenever either the receiving domain is ON, or you have specified ON to OFF isolation and the source domain of the signal is ON. If both the source and receiving domains are turned off, the isolation control signal power can be off.

Example



ISO4a

Message

Both inputs of non-dedicated isolation cell can be OFF while isolation cell power is ON

Default Severity

Error

Description

At least one of the inputs of a non-dedicated isolation cell must be ON when the isolation instance power is ON. If both inputs can be OFF while the isolation instance power is ON, then none of the inputs are acting as the control input.



ISO4b

Message

Isolation control signal is tied to a constant value

Default Severity

Warning

Description

The isolation control pin of the isolation cell instance is connected to a constant value. This means that the isolation function of this instance is always enabled or always disabled.

You can use a combination isolation and level-shifter cell as a level shifter only in this manner, by disabling the isolation function with a proper constant value. If this is the case, you can ignore this message.

To allow signal flow through the isolation instance, the constant should disable the isolation function. If this instance is not performing as a level shifter, or is not a combination isolation and level-shifter cell, you can remove the isolation instance.



ISO4c

Message

Control pin is tied to inactive constant value of an isolation instance at the domain crossing

Default Severity

Error

Description

The enable of an isolation cell is tied to a value of inactive through a tied constant, a tie-off cell, or a power/ground net (for a crossing that requires that the isolation function be based on power-mode definitions).

Check the verbose message to identify the isolation instance and to check the driving domains, the receiving domains, and the power modes. Correct as needed.

Applicability

Any design netlist that includes isolation cells.



ISO4d

Message

Control pin is tied to active constant value of an isolation instance with output load

Default Severity

Error

Description

The enable of an isolation cell is tied to a value of inactive through a tied constant, a tie-off cell, or a power or ground net (for a crossing). This means isolation is always ON.

Check the verbose message to identify the isolation instance and the logic driving the isolation control. Correct as needed.

Applicability




ISO4e

Message

Control pin is tied to inactive constant value of an isolation instance whose driver and receiver are ON/OFF together

Default Severity

Warning

Description

The enable of an isolation cell is tied to a value of inactive through a tied constant, a tie-off cell, or a power or ground net (for a crossing). This means isolation is always OFF, but because the isolation function is not required in this path, it is not an electrical or functional error; it is only inefficient.

Check the verbose message to identify the isolation instance and the logic driving the isolation control. Correct as needed.

Applicability




ISO4f

Message

Control pin is tied to inactive constant value of an output floating isolation instance

Default Severity

Error

Description

When the isolation control pin ties to an inactive value it can cause electrical issues in the isolation instance when this isolation instance is ON and its input is OFF.

Check the -verbose message to identify the isolation instance and its control pin connection

Applicability

Applies to synthesized or place-and-route netlists with low power cells inserted.



ISO5.1

Message

Unable to determine isolation function based on isolation cell structure

Default Severity

Error

Description

The logic in the isolation cell cannot isolate properly. The isolation cell does not have logic gate whose value can be controlled directly by the isolation control pin.

Example



ISO5.2

Message

Isolation pin connects to invalid logic inside isolation cell

Default Severity

Error

Description

The isolation control pin is connected to a logic gate whose value cannot be determined by only setting the value at the isolation control pin.

Note: This rule is flagged only if at least one valid isolation gate is found in the cell. If no valid isolation gates are found, ISO5.1 rule is flagged.

Example



ISO5.3

Message

Data pin connects to invalid logic inside isolation cell

Default Severity

Error

Description

A valid isolation gate in an isolation cell is a gate whose value can be determined by only setting the value at the isolation control pin. This check is flagged if the data input pin of the isolation cell is not connected to a valid isolation gate.

Example



ISO6.1

Message

Isolation cell domain can be OFF when it is required to be ON

Default Severity

Error

Description

The isolation cell instance is not in the source, destination or global (always-on) domain.

Example



ISO6.2

Message

Invalid instance for isolation because the control pin is buffered within the isolation cell

Default Severity

Error

Description

The isolation cell instance is in the OFF power domain, and isolation control pin is connected to buffers or inverters before reaching a valid isolation gate in the cell.

Example



ISO6.3

Message

Isolation instance in receiving domain with internal data pin buffered

Default Severity

Error

Description

The isolation cell instance is in the ON power domain, and the data pin is connected to buffers or inverters before reaching a valid isolation gate in the cell.

The buffer or inverter in the ON domain is not protected against floating data input, and thus causes leakage problems. The buffer or inverter can be inside or outside the isolation cell and its domain is the same as the ON domain.

Example



ISO6.4

Message

Isolation cell output is buffered in switchable source domain

Default Severity

Error

Description

The isolation cell instance is in the OFF power domain and the output pin is driven by buffers or inverters.

Example



ISO6.5

Message

Isolation cell structure is invalid in the domain it is placed

Default Severity

Error

Description

The type of isolation cell (Iso-HI, Iso-LO, or Iso-Latch) is not valid based on user-specified isolation rules or the location of the isolation cell instance.



ISO6.5a

Message

Isolation cell structure is invalid in the domain it is placed

Default Severity

Error

Description

Reported when an isolation cell with valid location -from is placed in the wrong domain—a domain that is different than that of the driver.

Review the -verbose message for the isolation cell instance name and the related power domains. Review any isolation rules associated with the domain crossing to see if the insertion rule is incorrect or the insertion was not according to specification.

Applicability

Applies to synthesized or place-and-route netlists with low power cells inserted.



ISO6.6

Message

Isolation cell type is invalid for constant data input

Default Severity

Error

Description

Indicates that a constant data input is isolated to an opposite value. If the constant net is isolated to an incorrect value, it might result in incorrect operation of the destination domain when the domain driving the constant is OFF, and isolation is enabled. The constant is determined only by looking for any immediate constant drivers (such as power or ground nets, or tied signals) and by tracing back through buffers or inverters.



ISO7

Message

Invalid power domain crossing

Default Severity

Error

Description

There is a crossing between two power domains that does not have a user-defined isolation cell.



ISO7a

Message

ON-to-OFF power domain crossing with open-source input at receiver

Default Severity

Error

Description

This message is issued when there is a signal going from an ON domain to an OFF domain, and the receiving pin is an open source pin. The receiving pin must be specified as an open source with the ADD OPEN_SOURCE PINS command.

This violation is equivalent to the SPI2 violation, except SPI2 is flagged when SPICE netlists are provided, and in that case, the open source pins are automatically determined from the SPICE netlist of the cells.

To fix the issue, make sure that the signal is isolated properly when it goes to an OFF domain open-source pin. If the destination domain is power switched, use a low-type isolation. If the destination domain is ground switched, use a high-type isolation on this signal path.



ISO7b

Message

There is no isolation cell for a crossing that is excluded in an isolation rule for an ON domain to OFF domain crossing

Default Severity

Error

Description

An isolation rule for an ON->OFF crossing excludes one or more crossings and there is no isolation cell on that crossing.

Use report rule check ISO7b -verbose to view the crossing name and determine if the crossing needs to be isolated or not.

Applicability




ISO8

Message

Isolation control signal fanout to isolation instances exceeds specified limit

Default Severity

Error

Description

The user-specified limit was exceeded for some isolation control signal. You can set a limit on the number of isolation instances that can be controlled by an isolation control signal with the SET LOWPOWER OPTION -isolation_limit command.



ISO9

Message

Cannot find keeper cell at the output of a tristate type isolation cell

Default Severity

Error

Description

Cannot find keeper cell at the output of a tristate type isolation cell.



ISO10

Message

Secondary domain of an isolation cell might be off when its receiving domain is on

Default Severity

Error

Description

A secondary domain of an isolation cell might be off when its receiving domain is on. You can specify secondary domain for an isolation cell for logical netlist by specifying an isolation rule with the following CPF command:

create_isolation_rule -name <rule_name> -secondary_domain <power_domain>

When receiving domain of the isolation cell is ON, the specified secondary domain should be ON.

If you do not specify -secondary_domain for this rule, and the isolation cell has more than one power pin, the default secondary domain is the driving domain of the control pin.



ISO11

Message

Sequence of back to back isolation between domain boundaries is incorrect

Default Severity

Error

Description

A domain crossing has an isolation cell to protect the crossing in an OFF->ON state and an isolation cell to protect the crossing in an ON->OFF state, but the order of the isolation cells is not correct.

Use report rule check ISO11 -verbose to get information about the isolation cells, the isolation rules, and the specified location.

Applicability




ISO12

Message

Valid location of back to back isolation cells is not consistent with domain crossing and isolation definition

Default Severity

Error

Description

A domain crossing has an isolation cell for protecting the crossing in an OFF->ON state and an isolation cell for protecting the crossing in an ON->OFF state, but the location of one or more of these cells is not valid based on the cell and the usage.

Use report rule check ISO12 -verbose to get information about the isolation cells, the isolation rules, and the specified location.

Applicability




ISO14

Message

Isolation latch asynchronous set/reset pin driver can be OFF when latch cell is ON

Default Severity

Error

Description

When the power domain of the isolation latch cell is ON, the drivers of any asynchronous set or reset pins need to be ON; otherwise, you will have an unprotected OFF->ON domain crossing.

Use report rule check ISO14 -verbose to get information about the cell instance and check the power domains of the set/reset logic related to the power domain the isolation latch is in and the power modes for those 2 domains to determine how to fix it.

Applicability




ISO_BUF1

Message

Special control buffer defined as isolation cell with –no_enable option has the wrong type for the control polarity

Default Severity

Error

Description

This check is for a specific customer and is enabled with:

set lowpower option -iso_no_enable_is_control_buffer

This command specifies buffers that can drive active low or active high control signals in the domain that is switched OFF. This error means the type of buffer is not valid for the polarity of the control signal.

Use report rule check ISO_BUF1 -verbose to get information about the cell. Review the isolation rule and the receiving isolation cell’s enable polarity. You might need to change the polarity or the buffer type.

Applicability




ISO_BUF2

Message

Special control buffer defined as isolation cell with –no_enable option is not buffering any defined power control signals

Default Severity

Error

Description

This check is for a specific customer and is enabled with

set lowpower option -iso_no_enable_is_control_buffer

This is used to specify buffers that can drive active low or active high control signals in the domain that is switched OFF. This error means the signal is not buffering the enable to an isolation cell.

Use report rule check ISO_BUF2 -verbose to get information on the cell instance. Make sure the isolation rules that define isolation control signals are defined correctly. Also, if the buffered signal is not an isolation control, use another type of buffer.

Applicability




ISORULE1.1

Message

Isolation cell control pin is not connected to the specified signal

Default Severity

Error

Description

This checks that the control pin of the specified isolation instances are connected to the specified instance port. The isolation control pin of an isolation instance specified by the ADD ISOLATION RULE command’s -pins in an isolation rule does not connect to the instance port specified by the command’s -isolate argument in the same isolation rule. This check is only applied in the presence of an isolation rule.

To fix this problem, verify that the isolation rule reported in the message is correct. If so, reconnect the control input of the isolation instance correctly.



ISORULE1.2

Message

Isolation cell does not match cells specified in the isolation rule

Default Severity

Error

Description

The isolation instance is not one of the cells specified by the ADD ISOLATION RULE command’s -cell option of the matching isolation rule.

To fix this problem, check that the rule is correct. If so, change the cell of the reported isolation instance.



ISORULE1.3

Message

Domain crossing with isolation has multiple isolation rules specified

Default Severity

Warning

Description

There are multiple isolation rules that match the same isolation instance. There should be only one isolation rule that matches an isolation rule.

To fix this problem, check that there is no overlap in the isolation rules.



ISORULE1.4

Message

Isolation not found for domain crossing as specified by isolation rule

Default Severity

Error

Description

There is an isolation rule specified by the ADD ISOLATION RULE command for this domain crossing, and no isolation instance is found for this crossing. Every crossing that is specified by this command, and not excluded by the command’s -exclude option in the same rule, must have an isolation instance associated with it.

To fix this problem, check that the isolation rule is correct



ISORULE1.5

Message

Isolation instance control polarity is different than that specified by isolation rule

Default Severity

Error

Description

This rule is violated only if there is an isolation rule that specified the isolation control pin for the isolation instances. If the isolation control is connected to the correct pin but with a wrong polarity, then this error is generated.

Example

The following isolation rule isolation rule implies that the isolation is asserted when iso_ctrl/O has a high value:

add isolation rule r0 -type low -isolate isoctrl/O

This means that:

■ The isolation control of the isolation cell used is active high and the isolate signal specified connects to the isolation control pin of the isolation instance in a non-inverted manner, or

■ The isolation control of the isolation cell used is active low and the isolate signal specified connected to the isolation pin of the isolation instance in an inverted manner.

For the example rule, the following are good connections:

O

iso_ctrl

OR_ISOActive high isolation control

Data

O

iso_ctrl

AND_ISOActive low isolation control

Data



But the following are not:

O

iso_ctrl

Bad polarityConnected signal is inverted

Data

O

iso_ctrl

Bad polarityActive high isolation connects to active low isolation cell

Data



ISORULE1.5a

Message

Macro model isolation control polarity error

Default Severity

Error

Description

The software detected a macro model isolation control polarity error. To resolve this, determine if the macro model or the higher scope isolation rule polarity is incorrect, and make the proper adjustments.



ISORULE1.6

Message

Domain crossing with isolation does not have an isolation rule

Default Severity

Warning

Description

The isolation instance does not match any isolation rule. The rule-based checking cannot be performed for this isolation instance.

To check for isolation type or isolation control connection and polarity, make sure that there is an isolation rule that applies to this instance.



ISORULE1.6a

Message

Domain crossing to a macro model does not have any upper scope isolation rule

Default Severity

Warning

Description

Indicates that a domain crossing to a macro model does not have any upper scope isolation rule. If a crossing is between a macro’s pin and other pin outside the macro, specify an isolation rule outside the macro for this crossing.



ISORULE1.7

Message

Isolation instance cell type does not match isolation rule

Default Severity

Error

Description

The type of isolation cell (Low or High) does not match the type specified in the isolation rule matching this domain crossing through the isolation instance. If an isolation cell has multiple source or destination domains, each pair of source and destination domains is checked separately. The type of the isolation cell must be the same in the matching isolation rule between each of these source-destination pairs.

Example

In the following example, isolation instance isoInst is of type Low—that is, when the isolation control is asserted, the output of the isolation cell is clamped to logic level zero. If the following isolation rules are specified:

add isolation rule r0 -source D1 -destination D2 -type high

add isolation rule r1 -source D1 -destination D3 -type low

the path i1 to isoInst to i2 matches rule r0, but the isolation type low does not match the specified type high in the rule. As a result, ISORULE1.7 is issued for this path through the isolation cell.



The path i1 to isoInst to i3 matches rule r2, and the specified type low also matches the isolation cell type. Therefore, there is no ISORULE1.7 error issued for this path starting in domain D1 and ending in domain D3.

control

ISO i2

i3

domain D1

domain D3

domain D2

i1

data

isoInst



ISORULE1.8

Message

Isolation instance location does not match isolation rule

Default Severity

Error

Description

The location of the isolation cell instance is not valid based on user-specified isolation rules.



ISORULE1.9

Message

Invalid isolation type in isolation rule for constant signal

Default Severity

Error

Description

Indicates that the isolation rule matching a constant data input crossing power domains has an opposite type specified for the isolation cell. If the constant net is isolated to an incorrect value, it might result in incorrect operation of the destination domain when the domain driving the constant is OFF, and isolation is enabled. The constant is determined only by looking for any immediate constant drivers (such as power or ground nets, or tied signals) and by tracing back through buffers or inverters.



ISORULE1.10

Message

Isolation rule specified with valid type for constant signal

Default Severity

Warning

Description

This message indicates that the isolation rule matching a constant data input crossing power domain has a correct type specified for the isolation cell. This is a warning because the destination domain operation will not be affected when the isolation is enabled. But the constant value could have been moved to the destination domain to eliminate this isolation instance. The constant is determined only by looking for any immediate constant drivers (such as power or ground nets, or tied signals) and by tracing back through buffers or inverters.



ISORULE1.11

Message

Isolation instance is not directly in the specified instance or under the hierarchy which has the same domain of the specified instance

Default Severity

Error

Description

The insertion location of the isolation cell instance is not valid based on the specified isolation rule. The isolation cells can be placed in the specified instance or under the specified instance hierarchy which has the same domain as the specified instance.

Review the verbose message to identify the name of the violated isolation instance, isolation rule, specified insertion hierarchy/domain, isolation instance placed hierarchy/domain.

Applicability

Synthesized and place and route gate netlists with low power cells inserted.



Always-on Cells

The following lists the Always-on Cell (AON) rule checks:

■ AON1 on page 290



■ AON3a on page 295




AON1

Message

Supply power or ground pin of always-on cell instance can be OFF when its receiver power is ON

Default Severity

Error

Description

Indicates that the always-on power (ground) pin of the always-on instance is connected to a power (ground) net that can be off while any of the instances that receive the output of the always-on instance are powered ON. In such cases, the signal received by the load instances of the always-on instance can be invalid.

To fix this problem, check the input power or ground pin connectivity of the always-on instance and make sure all power pins are defined correctly. You can also use the ANALYZE INSTANCE CONNECTIVITY command to look at the connections of this instance.

Example

The following diagram shows a portion of a physical netlist with an always-on instance aonInst. The always-on instance aonInst has an always-on power pin P and a switchable power pin PS. It drives instance destInst that is always on, and has its power and ground pins connected to VDD and GND respectively, that are always ON power and ground nets. However, the always-on power pin P of aonInst is connected to VDD_SW, which is switched.



If VDD_SW is OFF. This results in an illegal power domain crossing from the output pin of aonInst to its load destInst. The software will issue an AON1 message for this situation.

Similar reasoning applies to netlists without power and ground connectivity. Instead of power and ground nets, the check is based on power domains of the instances. In the following diagram, power domain PD_SW is switched, whereas power domain PD is an always-on domain. The software will also issue an AON1 message for this situation.

GND

I

PPS

O

VDD_SW VDD

destInstaonInst

n1

destInstaonInst

PDPD_SW

n1



AON2

Message

Active input of always-on cell instance can be OFF when its supply power and ground is ON

Default Severity

Error

Description

An always-on cell can have input pins that are allowed to be turned off, and other input pins that must be driven by always on logic. The input pins of the always-on cell that should be driven by always-on logic are called the active inputs of the always-on cell. The signal that connects to the active input pins are called the active signals for this always-on instance. The logic driving the active input pins of an always on cell should always be powered on.

This error indicates that the power (ground) of the active signal of the always-on instance is connected to a power (ground) that can be OFF while the power and ground of the always-on instance is ON.

To fix this problem, check the power and ground of the logic driving the active input pin of the always-on instance and make sure those power and ground sources are ON whenever the always-on cell instance is ON.

Example

The following diagram show a portion of a physical netlist with an always-on instance aonInst. The always-on instance aonInst has an always-on power pin P and a switchable power pin PS. Its active input pin is I, which is driven by instance srcInst. The power net VDD_SW connected to instance srcInst is a switched power net. So, when the always-on power of aonInst is ON, the signal value of net n1 can become invalid if VDD_SW is switched



OFF. This essentially results in an illegal power domain crossing at input I of the instance aonInst. The software will issue an AON2 message to flag this invalid condition.

Similar reasoning applies to netlists without power and ground connectivity. Instead of power and ground nets, the check is based on power domains of the instances. In the following diagram, power domain PD_SW is switched, whereas power domain PD is an always on domain. The software will issue an AON2 message for input I of instance aonInst.

GND

I

PPS

O

VDD_SW VDD

destInstaonInstsrcInst

n1 n2

destInstaonInst

PD

srcInst

PD_SW PD

n1



AON3

Message

Always-on cell instance with floating output(s)

Default Severity

Warning

Description

Indicates the output of the always-on instance is not driving any logic.

To fix this problem, check if the floating output is intended.



AON3a

Message

Always-on cell instance is used in an always-on domain

Default Severity

Note

Description

An always-on buffer should be placed in switchable power domains. Placing always on cells in switchable power domain area is inefficient.

To fix the problem, replace the always-on buffer in the always-on domain with a regular buffer.



AON4

Message

Always-on instance drives regular cell in switchable domain

Default Severity

Warning

Description

Always On buffers should not be used to drive logic that can be switched off. An always on cell driving a regular cell that is switched off can increase leakage.

If you define buffer cells with two power pins (one for regular power grid routing via abutment and a special power pin for routing over the cell), the Conformal Low Power software will report any use of this cell if it is used to drive logic that can be powered down.

The Conformal Low Power software will automatically determine and check the power domain of buffering to ensure power control signal buffering is ON when it is needed to be ON, such as when a receiving low power cell is ON or retention or isolation is asserted, and when it is driving any non low power cell that is powered ON.



Retention Cells

The following lists the Retention Cell (RET) rule checks:

■ RET1 on page 298

■ RET1a on page 299


■ RET2a on page 301





■ RET7.1 on page 306

■ RET7.2 on page 307

■ RETRULE1.1 on page 308










RET1

Message

Retention power of state retention cell is not ON more often than its normal power

Default Severity

Error

Description

This rule check messages indicates that the VRET pin (specified with the ADD RETENTION CELL command’s -power vret_pin option) is not connected to a top-level power pin power pin.

This rule check message indicates that the connectivity of retention cell VRET pin is not connected to the global VDD signal.

The VRET pin drives the retention flops when the power domain containing this instance is turned off. If this pin is not driven by an always on power, the retention function does not assert properly, and this will cause functional failure. Check netlist for proper connectivity.



RET1a

Message

State retention cell retention power can be OFF when the receiving power domain is ON

Default Severity

Warning

Description

This rule check messages indicates that the state retention cell retention power can be OFF when the receiving power domain is ON.



RET2

Message

State retention cell retention control signal power can be OFF when retention power is ON

Default Severity

Error

Description

This rule check messages indicates that the power control pin (pins specified in the ADD RETENTION CELL command’s -retention <expression> option) is not driven by an always-on power domain.

This rule check message indicates that the connectivity of retention cell RET pin is not connected to an always-on power domain signal.

The RET pin drives the retention flops when the power domain containing this instance is turned off. If this pin is not driven by an always on domain, the retention function does not assert properly, and this will cause functional failure. Check netlist for proper connectivity.



RET2a

Message

Retention signal is tied to a constant value

Default Severity

Warning

Description

This violation is flagged when the retention control pin of a retention instance is tied to a constant value, either directly or through a chain of buffers or inverters. In such cases, the retention functionality is either always enabled or always disabled.

To correct the issue, connect the retention control signal to a power controller module, which should control when retention is activated.



RET3

Message

State retention cell normal power and data driving power are from different domains

Default Severity

Error

Description

This rule check messages indicates that the power pin specified by the VDD pin (specified with the ADD RETENTION CELL command’s -power vdd_pin option) has a different power domain than the power domain which drives the data pin.

This rule check message indicates that the connectivity of retention cell A pin and the VDD pin are not connected to the same power domain.

This check is similar to the ISO2 check, and having the inputs from different power domains will result in the wrong analysis of power domains. Make sure the connectivity is proper, and rerun the check again.



RET4

Message

State retention cell non-control input power is ON whenever retention power is ON

Default Severity

Warning

Description

This rule check messages indicates that the non-power control inputs, such as pin A and the clk pins, are connected to an always on power domain.

This rule is important because it checks for the condition when the retention cell should go off. If the non power control signals are connected to an always on power domain, the retention cell will not turn off, even if the module containing these instances are turned off, and this will cause erroneous results.



RET5

Message

Output of retention cell is floating

Default Severity

Warning

Description

This is related to reporting cells with floating outputs as floating instead of redundant.



RET6

Message

Retention control signal fanout to retention instances exceeds specified limit

Default Severity

Error

Description

The user-specified limit was exceeded for some retention control signal. You can set a limit on the number of retention instances that can be controlled by a single retention control signal through the SET LOWPOWER OPTION -retention_limit command.

If the design has retention instances with separate sleep and wake pins, they are counted separately, as follows.

■ count of sleep pins on a net (number of retention pins plus number of sleep pins) driven by this net

■ count of wake pins on a net (number of retention pins plus number of wake pins) driven by this net

Both counts are compared against the global limit set by -retention_limit. If the design does not have any retention instances with both sleep and wake pins, only one RET6 error is generated. Otherwise, both violations are reported separately.



RET7.1

Message

Logic gate in set control for retention cell is in a switchable power domain

Default Severity

Error

Description

The set control signal of the sequential element in a retention cell is driven by an instance in a switchable power domain.

If a state retention cell set control can be driven by a switchable domain without issue, use set rule handling RET7.1 -ignore command to disable this message.

Applicability

This check applies to synthesized and place-and-route gate netlists with low power cells inserted.



RET7.2

Message

Logic gate in reset control for retention cell is in a switchable power domain

Default Severity

Error

Description

The reset control signal of the sequential element in a retention cell is driven by an instance in a switchable power domain.

If a state retention cell reset control can be driven by a switchable domain without issue, use set rule handling RET7.2 -ignore to disable this message.

Applicability




RETRULE1.1

Message

Retention cell control pin is not connected to the specified signal

Default Severity

Error

Description

This rule check message indicates that the retention cell control pin is not connected to the specified signal.

To fix this problem, locate the retention instances that are reported, and see which signal controls their retention input pin, and verify that the specified retention connectivity rule is correct. If the rule is correct, reconnect the control pin of the retention instance to the correct signal. This error is flagged only if you specified a retention rule to check for this.

Example

If you specify a rule with the following command:

add retention rule rule1 -retention a1/Y -instance i0 i1

And there is a situation such as in the following illustration:

the Conformal software will issue a RETRULE1.1 message for retention cell instance i1 because its retention control RET is not connected to a1/Y.

Y

RET

i0

RET

i1

RET

i2

a0

a1



RETRULE1.2

Message

Retention control signal controls unspecified retention cell instance

Default Severity

Error

Description

To fix this problem, verify if those extra retention instances are indeed to be controlled by this signal. If not, reconnect the retention instances. This error is flagged only if the you specified a retention rule to check the retention control connectivity.

Example

If you specify a rule with the following command:

add retention rule rule1 -power_gating a1/Y -instances i0 i1

And there is a situation such as in the following illustration:

the Conformal software will issue a RETRULE1.2 message for retention cell instance i2 because it was not specified to be controlled by a1/Y.

Y

RET

i0

RET

i1

RET

i2

a0

a1



RETRULE1.3

Message

Retention control polarity is different than that specified by retention rule

Default Severity

Error

Description

The retention control pin of the retention cell instances does not match in polarity to its specification in the retention rule. The retention control pin of the cell is either the pin specified with the ADD RETENTION CELL command’s -retention option, or one of the sleep or wake pins specified with the command’s -sleep or -wake options.

For example, if you added the following retention cell:

add retention cell C1 -retention !RET -clock_off CLK_OFF

And this rule:

add retention rule r1 -DOMain pd -retention x0/ret_ctrl_inst/Y

The software checks that the pin x0/ret_ctrl_inst/Y drives the RET pins of all instances of C1 in power domain pd, through a chain of buffers or inverters. This is flagged by violation RETRULE1.1.

In addition, the software checks that the number of inversions (including the inversion in the retention control signals in the rule and the cell) is even. In this case,

■ Inversion for the RET signal of the cell C1 : 1

■ Inversion for the retention control signal in the rule: 0

So there should be an odd number of inversions between x0/ret_ctrl_inst/Y and the RET pins of all instances of C1 in power domain pd, to make the total number of inversions even.



RETRULE1.4

Message

State element is not a retention cell as specified by retention rule

Default Severity

Error

Description

This rule checks that all the flip-flops and latches in the specified domain in a retention rule are mapped to retention instances. For example, if you have the following retention rule:

add retention rule r1 -domain pd

The software checks if all flip-flops and latches in power domain pd are retention cells.

Note: At this point, retention rules of this form alone triggers this check. Retention rules with enable signals trigger checking for retention cell control signal connectivity checks. So to check for retention of each domain, this rule should be specified for each power domain.



RETRULE1.5

Message

Overlapping retention rules for retention cell

Default Severity

Error

Description

This violation is flagged for retention cell instances that match multiple retention rules for checking the retention control signals. For example, if there are the following two retention rules:

add retention rule r1 -DOMain pd -retention x0/ret_ctrl/Y

add retention rule r2 -instance ret_inst0 -retention x0/ret_ctrl1/Y

and instance ret_inst0 is in power domain pd, then both rules match this retention instance, and this violation will be flagged for this instance.



RETRULE1.6

Message

Retention cell instance does not match any retention rule

Default Severity

Error

Description

An instance of a cell defined in Liberty or CPF format as a state retention cell cannot be matched to any power intent rule for inserting state retention cells. The cell instance needs to be defined by being defined directly by instance name, in the hierarchy of a defined instance, or in the domain defined in a rule.

Causes of this can include but are not limited to the following: the name of the instance was changed by the implementation tool, the cell was hand instantiated and a rule did not exist, or the state retention cell was inserted incorrectly by the implementation tool.

Check the verbose messages to identify all errors which share common information like domain or hierarchical instance name and correct the power intent specification.



RETRULE1.7

Message

Retention cell does not match the cell type specified in retention rule

Default Severity

Warning (You can use set rule handling to change severity)

Description

An update to a state retention insertion rule specifies a list of cells to use for insertion and the cell inserted does not match any cell name in that list.

Use the report rule check RETRULE1.7 -verbose to get information on the rule name and the inserted cell instance. Use this information to check whether you need to modify the cell or retention rule cell list.

Applicability

This rule applies to synthesized and place-and-route gate netlists with low power cells inserted.



RETRULE1.8

Message

Retention cell is placed in a domain with multiple base domains and there is no secondary domain defined in the state retention rule for this cell

Default Severity

Error

Description

A retention rule is applied to a state element in a domain that has multiple base domains, but there is no -secondary_domain option specified to select one of the base domains as the domain for which the retention function resides.This can happen when a region has multiple power or ground switches with different input sources.

Use the report rule check RETRULE1.8 -verbose command to retrieve the switched domain name and base domains. Then, add the base domain to the retention rue using the -secondary_domain option that is required.

Applicability

This rule applies to synthesized and place-and-route gate netlists with low power cells inserted



Level Shifter Cells

The following lists the Level Shifter (LSH) rule checks:

■ LSH1.1 on page 317




■ LSH2 on page 321

■ LSH2a on page 322

■ LSH2b on page 323

■ LSH2c on page 324

■ LSH2d on page 325

■ LSH2e on page 326



■ LSH4.1a on page 330

■ LSH4.1b on page 331

■ LSH4.1c on page 332










LSH1.1

Message

Level shifter input voltage value is different than specified by level shifter definition

Default Severity

Error

Description

The voltage level connected to the data input is not the same as that specified with the ADD LEVEL SHIFTER command. The voltage level is checked only if the voltage values are specified in the ADD LEVEL SHIFTER command.



LSH1.2

Message

Level shifter output voltage value is different than specified by level shifter definition

Default Severity

Error

Description

The voltage level that the output pin is connected to is not the same as that specified with the ADD LEVEL SHIFTER command. The voltage level is checked only if the voltage values are specified in the ADD LEVEL SHIFTER command.



LSH1.3

Message

Level shifter voltage connections are different than specified by level shifter definition

Default Severity

Error

Description

The input-output voltage combination is incorrect for the level-shifter cell.

Example

If you have specified voltages for a level-shifter as follows:

add level cell LH_LS 1.0 1.2 -Data_in A -Data_out Y -VDD_IN VL -VDD_OUT VH

add level cell LH_LS 0.8 1.0 -Data_in A -Data_out Y -VDD_IN VL -VDD_OUT VH

Then an attempt to shift 0.8V to 1.2V using LH_LS will be flagged by LSH1.3.

Note: This will not be flagged by LSH1.1 or LSH1.2 because the input and output voltages are valid on the input and output sides, respectively. It is the combination that is invalid in this case.



LSH1.4

Message

Level shifter is not defined to shift in this direction

Default Severity

Error

Description

If the level shifter is specified to shift voltages in only one direction, such as low-to-high or high-to-low, and any instance of this level shifter has an input and output voltage combination that violates the specified direction, this error is reported.

Example

The following command specifies a level shifter that only shifts voltages from lower to higher values, as follows:

add level shifter LH_LS 1.0:1.5:0.1 1.0:1.5:0.1 -vdd_in VL \-vdd_out VH -data_in A -data_out Y -direction up

If any instance of this level shifter has a source voltage of 1.5 and a destination voltage of 1.2, it violates the specified direction of ’up’, because it is down shifting its input voltage. In such cases, this error will be reported.



LSH2

Message

Incorrect level shifter power connectivity

Default Severity

Error

Description

The voltage domains of Pin A and Pin VDDIN pair, or the Voltage domains of Pin Y and Pin VDDOUT pairs do not match. Check the connectivity of these pins in the netlist. This check is similar to the ISO2 check, except that it checks the voltage domains instead of power domains.



LSH2a

Message

Incorrect power domain for level shifter data pin

Default Severity

Error

Description

This error is issued for a level shifter data pin under the following conditions:

■ The level shifter cell is not an isolation cell as well.

■ The power domains of the power pin and the data pin of the level shifter are different.

■ The two power domains can be OFF to ON or ON to OFF structurally. If power modes are defined, these conditions are checked for each mode.

Each of the input and output sides of the level shifter are checked separately.

This error catches a power domain crossing at the level shifter input or output pin because the signal changes its power domain at the level shifter cell due to a different power domain being connected to the level shifter cell’s power pin.



LSH2b

Message

Power pin of level shifter can be OFF while the other power is ON

Default Severity

Error

Description

This error is triggered when one power pin of the level shifter can be OFF when the other power pin is ON, and the level shifter is not an isolation cell as well, or it is not a level shifter cell that has an enable pin to isolate data signals. If the level shifter cannot function as an isolation cell, then both of its power pins should be ON and OFF simultaneously.



LSH2c

Message

Level shifter’s driving domain can be OFF when level shifter’s input domain is ON

Default Severity

Error

Description

Indicates that a level shifter’s input power domain, which is assigned by location in a preplace and route netlist or by explicit supply connections in a place and route netlist, can be off ON when the driving domain is OFF in one or more power modes. This creates an unprotected OFF->ON crossing.

Use report rule check LSH2c -verbose to get details about the level shifter instance and review the driving and receiving domains. If the driving domain can be OFF when the receiving domain is ON, you need to place an enabled level shifter such that the driving supply can be connected to the level shifter input supply. If the receiving domain cannot be ON when the driving domain is OFF, then place the level shifter such that the driving supply can be connected to the level shifter input supply.

Applicability




LSH2d

Message

Level shifter’s driving domain can be OFF when level shifter’s input domain is ON

Default Severity

Warning

Description

Indicates that a level shifter’s output power domain, which is assigned by location in a preplace and route netlist or by explicit supply connections in a place and route netlist, is different than one or more receiving domains. This is not a structural or functional problem, because the crossing is at the same nominal condition in all ON modes and the crossing is not defined to be in an OFF->ON state in any mode.

Use report rule check LSH2d -verbose to get details on the level shifter instance if more analysis is desired.

Applicability




LSH2e

Message

Driving domain of level shifter is ON when input domain of level shfiter is OFF and output domain of level shifter is ON

Default Severity

Error

Description

The input data of a level shifter is driven by a power domain that can be ON when the input domain of the level shifter is OFF and the output domain of the level shifter is ON. This will create both an electrical and a functional problem. The cause of this error is usually that the input power pin of the level shifter is connected to a power net that is different than the driving domain.

Check the verbose message to identify the level shifter instance and for logical mode check the power domain of the instance the level shifter is in, it may be inserted in the wrong domain or if this is a physical netlist and the level shifter location is "to" domain, check the power net connection of the input power pin of the level shifter.

Example

In this example, a level shifter is defined with a valid_location of "from". It the level shifter is placed in a switched, low-voltage domain that is between an unswitched, low-voltage domain and an unswitched, high-voltage domain you will get an error message similar to the following:

LSH2e: Driving domain of level shifter is ON when input domain of level shfiter is OFF and output domain of level shifter is ONSeverity: Error Occurrence: 11: Level shifter: x2/x2Driving domain: dlInput domain: dsOutput domain: dh



LSH3

Message

Signal voltage is different than its receiver(s)

Default Severity

Error

Description

If you run the SET LOWPOWER OPTION command with -ignore_high_to_low, this is flagged only for voltage crossings from a lower voltage domain to a higher voltage domain.

The signal comes from another voltage domain, and there is no defined level shifter cell detected between this domain and the source domain.



LSH4.1

Message

Source and receiver signal voltages of level shifter cell are the same in this path

Default Severity

Error

Description

The voltage of the logic driving the data input pin of the level shifter is the same as the voltage of the logic in the destination domain of this level shifter. In such a case, the destination logic could be driven directly by the logic gate in the source domain, bypassing the level shifter. Note that there can be multiple paths through this level shifter, and the level shifter may be necessary for some other paths through this cell. The verbose report of this violation will report if it is required in some other path through the cell.

Example

In the following diagram, the source instance i0 is connected to 1.0 V, whereas the two destination instances i1 and i2 are connected to 1.0V and 1.2 V, respectively. The level shifter instance lsInst shifts the input data signal voltage from 1.0 V to 1.2 V. If all the power nets are always on, the level shifter is not required in the path i0 to lsInst to i1, so i1



could be directly driven by i0. However, the level shifter is required in the path i0 to lsInst to i2, and so this level shifter instance cannot be removed from the circuit.

To fix this issue, check if the path i0 to lsInst to i1 requires this level shifter. If not, bypass the level shifter and shorten this path to i0 to i1.

lsInst

LSi1

i2

1.2 V

i0

1.0 V

1.2 V1.0 V1.0 V



LSH4.1a

Message

Level shifting function of combination isolation and level shifter cell is unused in this path

Default Severity

Warning

Description

The voltage of the logic driving the data input pin of the level shifter is the same as the voltage of the logic in the destination domain of this level shifter. So, the level shifting function is unnecessary in this path. However, this cell is a combination isolation-level shifter cell, and the source domain is switched whereas the destination domain is always on. So, the cell is functioning as an isolation cell only.

Note: A combination isolation-level shifter cell has a larger area and higher delay and power consumption. If there are cells in the library that function only as isolation cells, this instance can be replaced with an isolation-only cell to reduce delay, area and power.

Example

In the following diagram, all power nets have the same voltage value of 1.0 V; however, the power net connected to instance i0 is switched. Although the level shifting function of lsInst is not required, its isolation function is in use.

lsInst

ISO- LS

i0

1.0 V, switched1.0 V, always on

i1



LSH4.1b

Message

Data pin of level shifter is connected to ground

Default Severity

Warning

Description

The data input of the level-shifter instance is connected to ground. This level shifter is redundant, and the cells driven by the level shifter can be connected directly to the ground net at the input of the level shifter.

This does not hold if this cell is a combination isolation - level shifter cell and the design uses ground switching.



LSH4.1c

Message

Level shifter instances with same driver and same destination domain

Default Severity

Warning

Description

This message is issued when multiple level shifter instances are used for the same power domain crossing. This message is only issued after running the SET LOWPOWER OPTION -clone_check command.

If a power domain crossing signal has the same driver, and has multiple fanouts in another domain, and level shifter cells are inserted in the fanout branches rather than the trunk, then this message is issued.

The multiple level shifter cells in the fanout branches must be of the same cell type. To fix this issue, change the connections to move the branching in the signal after the isolation instance.

Note: This is not possible when the multiple level shifter instances are required for drive strength.



Example

In the following example, the output net N from instance i0 fans out to two instances i1 and i2, both in domain DEST. There are two level shifter instances ls1 and ls2, of the same module type, for this signal crossing.

In this case, it is better to combine the two level shifter instances into one to save area and power, as shown in the following diagram:

LS

i0

data

ls1

net N

LS

data

ls2

i1

domainDEST

domainSRC

i2

domainDEST

LS

i0

data

ls1

net N

i1

domainDEST

domainSRC

i2

domainDEST



LSH4.2

Message

Output of level shifter is floating

Default Severity

Warning

Description

The output of the level shifter is floating.



LSH4.3

Message

Back-to-back level shifters detected

Default Severity

Warning

Description

The output of a level shifter cell directly drives the input data pin of another level shifter cell. One or both could be redundant in some cases.

Example

In Figure 1, both LSH1 and LSH2 are redundant since net A and net O are both 1.2 V, and so net A could directly drive the loads of net O.



If VDDOUT of LSH2 was connected to 1.4 V, then only one level shifter is redundant. The pair could be replaced by a single level shifter cell as shown in Figure 2.

OUT

VDDOUT

IN

VDDIN

LSH1

1.2V 1.0V

1.2VOUT

VDDOUT

IN

VDDIN

LSH2

1.0V

1.2V1.0V

1.2V

A O

OUT

VDDOUT

IN

VDDIN

LSH2

1.2V 1.4V

1.2V 1.4VA O

Figure 1

Figure 2



LSH5

Message

Level shifter location is different than defined for this cell

Default Severity

Error

Description

A level shifter is placed in an instance with a voltage that is different than the voltage of the domain that is defined to be the valid location of the level shifter (driving domain for ‘from’ valid location or receiving domain for ‘to’ valid location).

Check the verbose message to identify the level shifter instance, the level shifter cell name, the domain it is in, and the domain it is expected to be in based on the CPF definition of the valid location for that cell and the signal crossing.

Example

In this example, a level shifter is defined with valid_location of ‘to,’ but is placed in the instance of the ‘hi’ driving domain and therefore inherits the power domain of the ‘from’ domain. This results in the following error report:

LSH5: Level shifter location is different than defined for this cellSeverity: Error Occurrence: 1 1: Level shifter ’xh/x1’ (LevLH) is in voltage domain 1.2V

It is expected to be in source voltage domain 1V



LSH6

Message

The power domain of the netlist placement of the level shifter is not correct based on the defined valid location of the level shifter cell

Default Severity

Error

Description

The CPF definition of a level shifter cell has a valid_location option to define if the level shifter should be placed in the driving domain of the signal or the receiving domain (from or to). This error flags level shifter instances that are not in correct location in the design netlist based on the CPF power domain definition and instance hierarchy defined to be in that domain.

Check the verbose message to identify the level shifter instance, the level shifter cell name, the domain it is in, and the domain it is expected to be in based on the CPF definition of the valid location for that cell and the signal crossing.

Example

In this example, a level shifter is placed on a feedthrough in power domain 2 (dom2) for a crossing between power domain 1 and power domain 3 (dom3). Power domain 2 is not consistent with power domain 3 voltage and operating condition. This results in the following error report:

LSH6: The power domain of the netlist placement of the level shifteris not correct based on the defined valid location of the levelshifter cell

Severity: Error Occurrence: 11: Level shifter ’x2/x2’ (LevHL) Domain ’dom2’

It is expected to be in destination domain ( dom3 )



LSH7

Message

Interface domain between back to back level shifters cannot be determined

Default Severity

Error

Description

A level shifter with a valid location “from” that drives a level shifter with valid location “to” creates a situation where the output domain of the driving level shifter and the input domain of the receiving level shifter cannot be determined. This type of level shifting placement is not supported (except for post place-and-route netlists).

This check applies to pre place-and-route netlists.



LSH8

Message

Level shifter input is driven by multiple sources in different domains

Default Severity

Error

Description

A netlist cannot have an input with multiple drivers, unless they are tristate drivers that are not simultaneously enabled. When a design has different power domains, you should not have multiple drivers from different domains for tristate drivers; this can create a leakage path from the driving domains if the power domains are at different nominal conditions in any power mode—regardless whether the driver is on or off.

Use circuit analysis (available with Conformal Low Power GXL) to verify the correctness of open drain and open source connections at power domain boundaries.

Use report rule check LSH8 -verbose to get details on the level shifter instance and review the driver types and driver domains to understand and fix if necessary.

Applicability




LSH9

Message

Level shifter output drives multiple receivers in different domains

Default Severity

Error

Description

When a level shifter drives multiple receivers in different domains, the power domain assignment of the level shifter output domain cannot be determined. In this case, you need to use identify_secondary_domain to assign an output domain for the level shifter that is compatible with all receiving domains.

Use report rule check LSH9 -verbose to get details on the level shifter instance and the receiving domains.

Applicability




Structural

The following lists the structural rule checks:

■ CLP_STRC1.1 on page 343

■ CLP_STRC1.2 on page 344

■ CLP_STRC2 on page 345

■ STRUCT1 on page 346



CLP_STRC1.1

Message

Low power cell in strong combinational loop

Default Severity

Error

Description

The low power cell (such as isolation, retention, always-on, level shifter, and power switch) is in a strong combinational loop.

This rule check message indicates that the design includes a combinational loop that does not contain any weak devices. This could cause signals to oscillate and reflects a potential error in the design.

Conformal Low Power does this check in addition to the STRC1.1 checks, which checks for combinational loop across non-low power standard cell instances. Combinational loops are to be resolved the same as normal standard cell instances.



CLP_STRC1.2

Message

Low power cell in weak combinational loop

Default Severity

Error

Description

The design includes a combinational loop that contains weak devices.



CLP_STRC2

Message

Input to low power cell is undriven

Default Severity

Error

Description

The input pin of a low power cell is floating (undriven, unconnected).

This rule check message indicates any undriven inputs at the low power cells like retention, isolation, and level shifters. It is very important to check the undriven signals because the power domain analysis depends on the connectivity. If the Conformal Low Power software cannot determine the power domain properly, the whole purpose of low power verification is defeated.

It is very important for the Conformal Low Power software to be able to properly propagate and analyze the power domains. Failing to do so will result in missing floating nodes and functional failures. Undriven signals will lead to failure in analyzing power domains properly. Check for the connectivity in netlist and make changes accordingly.



STRUCT1

Message

Isolation cell drives the set, reset, or clock pin of a latch or flip flop

Default Severity

Warning

Description

Set, reset, or clock pin of a latch or flip-flop is driven by an isolation cell. Check that the isolation cell outputs an isolated value that does not cause the clock, set, or reset to be applied when the isolation is asserted.

Applicability




Decoupled Capacitors

The following lists the decoupled capacitor (DECAP) rule checks:

■ DECAP1.1 on page 348

■ DECAP1.2 on page 349



DECAP1.1

Message

Decoupled capacitor power pin not connected to power net

Default Severity

Error

Description

This error is issued if the power pin of the decoupled capacitor as specified by the ADD DECAP CELL command is not connected to a power net.

To fix this problem, verify that the ADD DECAP CELL command specification is correct, then connect the power pin to a power net.



DECAP1.2

Message

Decoupled capacitor ground pin not connected to ground net

Default Severity

Error

Description

This error is issued if the ground pin of the decoupled capacitor as specified by the ADD DECAP CELL command is not connected to a ground net.

To fix this problem, verify that the ADD DECAP CELL command specification is correct, then connect the ground pin to a ground net.



Path Rules

The following lists the path rule (PATHRULE) checks:

■ PATHRULE1.1 on page 351





PATHRULE1.1

Message

End point is not driven by a valid start point

Default Severity

Error

Description

This rule checks that for each ending point specified in the path rule, it must be driven only by starting points without going through any illegal design object.



PATHRULE1.2

Message

Start point drives an invalid end point

Default Severity

Error

Description

This rule checks that for each starting point specified in the path rule, it must only drive ending points without going through any illegal design object.



PATHRULE1.3

Message

End point is not inverted from start point

Default Severity

Error

Description

This rule checks that when an end point is driven by a start point, it must be inverted from the start point.

Note: This rule is only applicable when the end point is driven by the start point through buffers and inverters; otherwise, PATHRULE1.1 will be flagged.



Clamp Rules

The following lists the clamp rule (CLAMP) checks:

■ CLAMP1 on page 355

■ CLAMP1a on page 356

■ CLAMP2 on page 357



CLAMP1

Message

Power of clamp cell can be OFF when its data power domain is ON

Default Severity

Error

Description

If a signal has a diode clamp to the power net of the destination domain, and is driven from another domain whose power net is ON while the destination power net is OFF, there can be a leakage path from the power net of the source domain to the power net of the destination domain.

To avoid such issue, the signal should be isolated with a low type isolation cell in the source domain.



CLAMP1a

Message

Ground of clamp cell can be OFF when its data ground domain is ON

Default Severity

Error

Description

if a signal has a diode clamp from the ground net of the destination domain, and is driven from another domain whose ground net is ON while the destination ground net is OFF, there can be a leakage path from the power net of the destination domain to the ground net of the source domain.

To avoid such issue, the signal should be isolated with a high type isolation cell in the source domain.



CLAMP2

Message

Clamp cell data pin voltage is higher than the power pin voltage

Default Severity

Error

Description

This message is issued when the voltage of the power domain driving the data pin of the clamp cell is higher than the voltage of the clamp cell’s power pin. In such a scenario, the diode within the clamp cell can become forward biased, and cause current to sink to the power net of the clamp cell, causing significant power dissipation.

Example

In the following example, if VDD1 > VDD2 + Vth, where Vth is the threshold voltage of the diode, the diode in the clamp cell conducts from VDD1 to VDD2. This shorts the two power nets at different voltages and causes significant power dissipation.

VDD1

GND

Source

A

Destination

+

-

GND

O

VDD2



Circuit Rules

The following lists the circuit rule (CIR) checks:

■ CIR1a on page 359

■ CIR1b on page 360

■ CIR2 on page 361







CIR1a

Message

On to Off power domain short through PMOS source/body junction

Default Severity

Error

Description

When an ON domain can drive a high value to an OFF domain with an open source PMOS input with the body connected to the switched power net, the P+/N- junction can be forward biased. This causes excessive power consumption.

You can fix this by buffering the TO domain input, or by inserting a low type isolation in either the FROM or TO domain.



CIR1b

Message

On to Off ground domain short through NMOS source/body junction

Default Severity

Error

Description

When an ON domain can drive a low value to an OFF domain with an open source NMOS input with the body connected to the switched power net, the P+/N- junction can be forward biased. This causes excessive power consumption.

You can fix this by buffering the TO domain input, or by inserting a high type isolation in either the FROM or TO domain.



CIR2

Message

Higher to lower voltage domain short through PMOS source/body junction

Default Severity

Error

Description

A higher voltage driving a PMOS source with the body connected to a lower voltage creates a forward biased P+/N- diode junction. This causes excessive power consumption.



CIR3

Message

PMOS body of power switch is connected to the switched power net

Default Severity

Error

Description

The N- body of the PMOS in the power switch must be connected to the input power supply of the switch, and not to the output switched power net. Connecting the body to the output switched net creates a forward biased diode between the P+ Source terminal and the N- body, which is connected to the P+ Drain terminal.



CIR4

Message

NMOS body of ground switch is connected to the switched ground net

Default Severity

Error

Description

The P+ body of the NMOS in the ground switch must be connected to the input ground supply of the switch, and not to the output switched ground net. Connecting the body to the output switched net creates a forward biased diode between the N- Source terminal and the P+ body, which is connected to the N- Drain terminal.



CIR7

Message

Incorrect PMOS body terminal bias net connection

Default Severity

Error

Description

The PMOS body terminal of the functional gate must connect to the bias net specified in the -pmos_bias_net option of the update_power_domain command in the placed power domain. If the bias net is not defined with the -pmos_bias_net option, the primary power net is the default.

The verbose message lists the instance and the bias net; use this information to determine if the bias net is correctly defined and connected.

Example

In this example the OR_1_0 cell has a PMOS body terminal VDDB:

.SUBCKT OR_1_0 A B Y VDD VSS VDDB VSSBMP1 x B VDD VDDB PCHMP2 n A x VDDB PCHMN3 n A VSS VSSB NCHMN4 n B VSS VSSB NCHMN5 Y n VSS VSSB NCHMP6 Y n VDD VDDB PCH.ENDS

In the design netlist, this VDDB terminal is connected to net VDD, instead of net VDDB which is defined as a CPF bias net:

OR_1_0 u_1 (.A(in[0]), .B(in[1]), .Y(out[1]), .VDD(VDD), .VSS(VSS), .VDDB(VDD), .VSSB(VSS));


CIR7: Incorrect PMOS body bias net connection Severity: Error Occurrence: 11: 1 instance(s) in power domain DHI have PMOS incorrect bias net connectionExpected connected bias net: /VDDBError instance : 1 of 1Instance: u_0/u_1



PMOS bias net: /VHI



CIR8

Message

Incorrect NMOS body terminal bias net connection

Default Severity

Error

Description

The NMOS body terminal of the functional gate must connect to the net specified in the -nmos_bias_net option of the update_power_domain command. If the option is not used, the primary ground net is the default.

The verbose message lists the error instance and the bias net; use this information to determine if the bias net is correctly identified or the instance is correctly connected.

Example

In this example the OR_1_0 cell has NMOS body terminal VSSB:

.SUBCKT OR_1_0 A B Y VDD VSS VDDB VSSBMP1 x B VDD VDDB PCHMP2 n A x VDDB PCHMN3 n A VSS VSSB NCHMN4 n B VSS VSSB NCHMN5 Y n VSS VSSB NCHMP6 Y n VDD VDDB PCH.ENDS

In the design netlist, this VSSB terminal connected to net VSS, instead of net VSSB which is defined as a CPF bias net:

OR_1_0 u_1 (.A(in[0]), .B(in[1]), .Y(out[1]), .VDD(VDD), .VSS(VSS), .VDDB(VDDB), .VSSB(VSS));


CIR8: Incorrect NMOS body bias net connection Severity: Error Occurrence: 11: 1 instance(s) in power domain DHI have NMOS incorrect bias net connectionExpected connected bias net: /VSSBError instance : 1 of 1Instance: u_0/u_1NMOS bias net: /VSS



SPICE Rules

The following table lists the SPICE rule (SPI) checks:

■ SPI1 on page 368







SPI1

Message

Unbuffered input pin

Default Severity

Error

Description

Note: This is a Low Power GXL check. The SPICE netlist views must be read in to perform this check.

This is a cell level message. It indicates that there is an open source or drain at the input pin of a library cell. If a cell has this type of input pin(s), there might be a problem if it is placed at a power domain boundary because the driver of the pin might be driving the body bias net of the cell when the body bias net is turned OFF. This situation can also happen if the body bias net of the PMOS is at a lower voltage than the voltage at the open source input pin, or when the NMOS body bias net is at a higher voltage than the open source input pin.

Example

The following diagram shows the cause of the violation, where there is an open source or drain at the input pin of a library cell.

This second diagram shows that when power net SRC_PWR is ON and power net DEST_BIAS is OFF, there is a path from the source power net SRC_PWR to DEST_BIAS through the forward biased p-n junction. So there is constant leakage, where the driving cell continuously

SRC_PWR

SRC_GND

DEST_BIAS



charges the bias net of the destination domain when the input pin is driven to a high value. If it is isolated to a low value, this issue is avoided.

Similar to first diagram, if it is an NMOS open source pin, the input should be isolated to a high value to avoid leakage.

SRC_PWR

DEST_BIAS turned offV(DEST_BIAS) < V(SRC_PWR)

P P

n-type substrate



SPI2

Message

Unbuffered input pin at power domain crossing

Default Severity

Error

Description


This is a design level message and points to every occurrence of such issue. This indicates that there is an open source or drain at the input pin of a library cell, and this pin is at power domain crossing.

See SPI1 on page 368 for a description of the leakage issues related to placing these types of open source/drain inputs at power domain boundaries.



SPI3

Message

Mos stack is too long

Default Severity

Error

Description


This message points to long source-drain series paths in the circuits.

The software reports all transistor stacks longer than a certain length, as specified with the SET LOWPOWER OPTION command’s -MAX_NMOS_STACK_DEPTH <nmos_max_len> and -MAX_PMOS_STACK_DEPTH <pmos_max_len> options.

If the series paths to power or ground are very long, charging and discharging the output nodes can take longer, unless the gate widths are made wider to compensate for longer series resistive paths.

It can also be a serious issue in pass transistor logic if PMOS is used to conduct a low value or NMOS is used to conduct a high value.



Example

The following diagram shows the cause of the violation, where there is long source-drain series paths in the circuits.

The following example shows how the SPI3 check excludes stacks that have transistor gates driven by inverted signals. The stack in this illustration is not reported, as transistors M1 and M3 are driven by inverted signals X_inv and x, respectively.

GND

PWR

output

NMOS stack length is 4.Transistor widths must be increased tocompensate for increased resistance.

M1 falseX_inv

M2

M3

y

VDD

x

false



SPI4

Message

Port does not have MOS path to power or ground

Default Severity

Error

Description


This message indicates that there is a node that has no path to either ground or power.

This is a serious error. It implies that the output node cannot be discharged or charged.



SPI5

Message

Mos transistor creates a short between power and ground

Default Severity

Warning

Description


This message indicates that there is a MOS transistor with the source/drain diffusion region connected to power, and the other side (drain/source) connected to ground. If this transistor is turned on, it will result in a short between the power and ground rails.

Note: If the gate input of the NMOS is connected to ground net (at or lower voltage than the ground net connected to the source/drain), then this message is not reported. Similarly, if the gate input of a PMOS transistor is connected to the power rail, this message is not reported.

Example

The following diagram shows the cause of the violation, where there is a MOS transistor with the source/drain diffusion region connected to power, and the other side (drain/source) connected to ground.

The following diagram shows examples of when this message is not reported, where the gate input of the NMOS is connected to ground net (at or lower voltage than the ground net

In

VSS

VDD

Reported as SPI5



connected to the source/drain), or where the gate input of a PMOS transistor is connected to the power rail.

VSS

Not reported as SPI5

VDD

VSS

VDD



Macro Rules

The following lists the macro rule checks:

■ MACRO1 on page 377






MACRO1

Message

Inconsistent domain mapping due to incorrect power net connection

Default Severity

Error

Description

A macro-model domain can be mapped to a design-level domain, but the power pin of the macro domain should connect to the power net of the design-level domain. This error reports situations where the power pin to power net connection is inconsistent with macro to design domain mapping.

Use the report rule check MACRO1 -verbose command to review domain mapping and power-net to power-pin connections of the macro model instance reported in the-verbose error report; compare this to the related create_global_connection command.

Applicability

Applies to post place-and-route netlists with power/ground connectivity.



MACRO2

Message

Inconsistent domain mapping due to incorrect ground net connection

Default Severity

Error

Description

A macro-model domain can be mapped to a design-level domain, but the ground pin of the macro domain should connect to the ground net of the design-level domain. This error reports situations where the ground pin to ground net connection is inconsistent with macro to design domain mapping.

Use the report rule check MACRO2 -verbose command to review domain mapping and ground-net to ground-pin connections of the macro model instance reported in the-verbose error report; compare this to the related create_global_connection command.

Applicability

Applies to post place-and-route netlists with power/ground connectivity.



MACRO3

Message

Incorrect PMOS bias net connection in macro model

Default Severity

Error

Description

The PMOS bias net of a power domain in a macro model is not connected to the PMOS bias net of the mapped power domain in upper block.

Applicability




MACRO4

Message

Incorrect NMOS bias net connection in macro model

Default Severity

Error

Description

The NMOS bias net of a power domain in a macro model is not connected to the NMOS bias net of the mapped power domain in upper block.

Applicability




Low Power Cell Rules

The following lists the low power cell rules:

■ LPC09 on page 382








LPC09

Message

Library cell power and related nwell pins specified in add related supply are connected to different nets. Define a design add related supply command for the power and nwell nets if this is expected.

Default Severity

Error

Description

The cell power pins and related nwell pins of library cells specified with the add related supply command must be connected to the same net when the power pins are not connected to a power net a design level add related supply rule and that the cell power pins are not connected to a power switch cell output. This can help detect potential electrical issues.

Applicability

This applies to place-and-route gate netlists with low power cells inserted



LPC10

Message

Library cell ground and related pwell pins specified in add related supply are connected to different nets. Define a design “add related supply” command for the ground and pwell nets if this is expected.

Default Severity

Error

Description

The cell power pins and related pwell pins of library cells specified with the add related supply command must be connected to the same net when any ground pin is not connected to a ground net in a design level add related supply rule and the cell ground pin is not connected to ground switch cell output. This can help detect potential electrical issues.

Applicability

This rule applies to place-and-route gate netlists with low power cells inserted



LPC11

Message

Library cell power and related nwell pins of add related supply rule have inconsistent connections. Define a design related supply rule for the power and nwell nets if connections are okay.

Default Severity

Error

Description

For library cells specified with the add related supply command, if any power pin is not connected to a power net in a design add related supply rule and connects to a power switch output, the related nwell pin must connect to the power net or the power switch source net. This can help detect potential electrical issues.

Applicability




LPC12

Message

Library cell ground and related pwell pins of add related supply rule have inconsistent connections. Define a design related supply rule for the ground and pwell nets if connections are okay.

Default Severity

Error

Description

For library cells specified with the add related supply command, if any ground pin is not connected to a ground net in a design add related supply rule and connects to a ground switch output, the related pwell pin must connect to the ground net or the ground switch source net. This can help detect potential electrical issues.

Applicability

This rule applies place-and-route gate netlists with low power cells inserted



LPC13

Message

Library cell power and related nwell pins are not connected to design power and related nwell nets as specified by cell and design add related supply rules.

Default Severity

Error

Description

If any library cell pin defined as -power in add related supply (for that cell) connects to a design-level port defined as -power in add related supply (for that design module), the related nwell pin in the cell rule must connect to related nwell port in the design rule. This can help detect potential electrical issues.

Applicability




LPC14

Message

Library cell ground and related pwell pins are not connected to design ground and related pwell nets as specified by cell and design add related supply rules.

Default Severity

Error

Description

If any library cell pin defined as -ground in add related supply (for that cell) connects to a design-level port defined as -ground in add related supply (for that design module), the related pwell pin in the cell rule must connect to related pwell port in the design rule. This can help detect potential electrical issues.

Applicability



Encounter Conformal Low Power Extended Checking Reference ManualCommon Power Format Rule Checks

4Common Power Format Rule Checks

Definitions for the Common Power Format (CPF) rules are explained in the following sections. This chapter includes the following topics:

■ Introduction to Common Power Format Messages on page 390

Rule Categories

■ CPF Design on page 391

■ CPF Ground Switched Domain on page 399

■ CPF Hierarchical on page 402

■ CPF Isolation Cells on page 424

■ CPF Level Shifter Cells on page 462

■ CPF Library on page 483

■ CPF Macro on page 517

■ CPF Power and Ground Nets on page 534

■ CPF Power Domains on page 543

■ CPF Power Shut Off on page 559

■ CPF Power Switches on page 569

■ CPF Retention Cells on page 575

■ CPF Power Mode Rule on page 592

■ CPF Gen Rules on page 594



Introduction to Common Power Format Messages

The purpose of Common Power Format (CPF) checks is to ensure the consistency within CPF files only and in the design where CPF is applied. This chapter describes the semantics of each CPF quality checks supported in the Conformal Low Power software. The CPF checks that do not depend on reading the design are not described in this chapter.

Violation Severity Levels

There are three levels of severity for rule violations. The severity levels are listed below from the most serious to the least serious:

■ Error: Conformal Low Power might not allow you to begin verification until you resolve the error.

■ Warning:Conformal Low Power allows you to begin verification; however, it warns you of potential errors in the design.

■ Note:Conformal Low Power provides information on how the software interpreted the command, and the actions that have been taken in response to the command.

You can run the REPORT RULE CHECK -LP command to view a summary or expanded report (using the -verbose option) of all low power rule violations.

Additionally, you can specify the category of rules you would like to view with the following command. Use the asterisk (*) following a prefix to list rules of the specified category. For example:

report rule check CPF_PD* -summary

To view information for a specific message, use the HELP command followed by the message ID.

HELp [message_id]

For example:

help CPF_PD1

Changing the Severity Levels

You can change the level of severity for CPF rule violations with the SET RULE HANDLING command.


../Verify_Ref/Verify_Commands.html#setrulehandling


CPF Design

The following lists the CPF Design (CPF_DES) rule checks:

■ CPF_DES1 on page 392








CPF_DES1

Message

Design instance defined in power domain does not exist

Default Severity

Warning

Description

An instance defined with the ‘create_power_domain -instances’ command does not exist in the design. This is checked on all netlists but is only an issue with preplace and route netlists.

This can happen when the instance name is spelled incorrectly, is missing in the netlist, or the instance name was changed by synthesis or place and route. Source code diagnostics are not available for this result.

Example

In the following example, there is no instance named ih in the design module named TopMod.

set_design TopMod

create_power_domain -name hi -instances { xh ih ) -boundary_ports { C D Z }

This results in the following error report:

CPF_DES1: Hierarchical instance does not exist in designSeverity: Warning Occurrence: 11: Data/Des.cpf:8 Hierarchical instance ih cannot be found

in the design



CPF_DES2

Message

Design instance pin defined in power domain does not exist

Default Severity

Warning

Description

A top or lower module pin defined in CPF as data or control for a power domain or rule must exist in the design or be defined by the -ports option of set_design command.

Check to make sure the reported pin name is correct and is in the design netlist or is defined with the ‘set_design -ports’ command.

Example

In the following example, there is no pin named Out2 in the design module named TopMod.

set_design TopMod

create_power_domain -name sw -instances { xS ) -boundary_ports { Out2 }


CPF_DES2: Hierarchical instance pin does not exist in designSeverity: Warning Occurrence: 11: Data/Des.cpf:8 Hierarchical instance pin Out2 cannot be found

in the design



CPF_DES4

Message

Design net in power intent definition does not exist

Default Severity

Warning

Description

A Conformal Low Power post place-and-route netlist verification session (physical mode) has encountered a CPF defined hierarchical power or ground net name that does not exist in the design.

This can occur when the netlist does not have power and ground nets. To fix this, change the mode to a pre place-and-route application (logical mode).

This can also occur when the name is incorrect. To fix this, check the verbose error report for the name and check the design data and compare. Correct the CPF name.

Example

In the following example, a post place-and-route netlist has a power net named VSW in instance xS, this is the output net of a power switch cell in that block. The power net name in the design is ‘xS/VSW.’

module SwMod (LP_PSW x0 (.Vo(VSW), .Vi(VDD), .Ei(Pwr), .Eo(nc), .VSS(VSS));

module TopModSwMod xS (

In the CPF file, this net is defined incorrectly with instance identifier as xR and not xS, as in the design data.

create_power_nets -nets xR/VSW -voltage 1.0 -internal

update_power_domain -name sw -primary_power_net xR/VSW


CPF_DES4: Hierarchical net does not exist in designSeverity: Warning Occurrence: 2



1: Data/Des.cpf:17 Hierarchical net xR/VSW cannot be found in the design2: Data/Des.cpf:22 Hierarchical net xR/VSW cannot be found in the design



CPF_DES5

Message

Design instance net defined in power intent definition does not exist

Default Severity

Warning

Description

A Conformal Low Power post place-and-route netlist verification session (physical mode) has encountered a CPF defined power or ground net name that does not exist in the design.

This can occur when the netlist does not have power and ground nets. To fix this, change the mode to a pre place-and-route application (logical mode).

This can also occur when the name is incorrect. To fix this, check the verbose error report for the name and check the design data and compare. Correct the CPF name.

Example

In the following example, post place-and-route netlist has a power net named VSW in instance xS that is the internal switched net generated in module SwMod:

module SwMod (Pwr, A, B, C, D, X, Y, VDD, VSS);LP_PSW xS (.Vo(VSW)

In the CPF file, this net is defined incorrectly as xS/VSO.

create_power_nets -nets xS/VSO -voltage 1.0 -internal

update_power_domain -name sw -primary_power_net xS/VSO


CPF_DES5: Net does not exist in moduleSeverity: Warning Occurrence: 21: Data/Des.cpf:17 Net VSO cannot be found in module SwMod [Data/Phy.v:1]2: Data/Des.cpf:22 Net VSO cannot be found in module SwMod [Data/Phy.v:1]



CPF_DES7

Message

Bus definition is not allowed in expression

Default Severity

Error

Description

Expressions in CPF format cannot be defined to include a bus notation with a range. It is valid to express the object as a single bus index.

Example

Example of legal expression:

-isolation_condition "Iso1 && Icont[4]"

Example of illegal expression:

-shufoff_condition "PSO[1:0] && pwrenable2"



CPF_DES8

Message

Object specified with update isolation or level shifter rule -within_hierarchy option is not valid for insertion

Default Severity

Error

Description

An instance specified in -within_hierarchy must be an existing design module that is not blackboxed and not a hard IP block.

Review the -verbose message for the rule to verify that the design instance name is correct and whether the design instance is blackboxed. Fix the design instance name or remove the blackbox definition (if it is legal).

Applicability

Applies to behavioral models or design netlists that will have low power features added during future implementation.



CPF Ground Switched Domain

The following lists the rule checks for ground switched domain information. The following lists the rule checks for ground switched domains:

■ CPF_GD2 on page 400

■ CPF_GD3 on page 401



CPF_GD2

Message

Switch rule is missing for switched domain

Default Severity

Warning

Description

When an internally ground switched domain (that is not a pure virtual power domain in the design scope) is defined, a corresponding switch rule is required for a CPF file that contains the physical information. A pure vir tual power domain is a power domain that is not specified as the default power domain, and for which no instances or boundary ports are defined.

Use the verbose message to identify the internally ground switched domain that does not have a switch rule. The domain might be incorrectly defined, or the switch rule is not correctly specified.

Example

The following CPF description defines DSW as an internally ground switched domain, but does not specify a switch rule:

create_power_domain -name DSW -instances {u_1} -shutoff_condition {!pe} \-base_domains DON create_power_nets -nets VDD -voltage 1.0create_ground_nets -nets GSW -internalupdate_power_domain -name DSW -internal_power_net VDD -internal_ground_net GSW

Resulting verbose report:

CPF_GD2: Internally ground switched domain which is virtual has no switch ruleSeverity: Error Occurrence: 11: Data/top.cpf:8 Internally ground switched domain DSW has no power switch rule.

An example fix, which defines a switch rule for this power domain:

create_power_switch_rule -name SR1 -domain DSW -external_ground_net VSS



CPF_GD3

Message


Default Severity

Warning

Description

With CPF 1.0 and CPF 1.0e versions, when an internally ground switched domain is defined, a corresponding switch rule is required for a CPF file containing physical information.

Use the verbose message to identify the ground switched domain that does not have a switch rule. The domain might be incorrectly defined and it is an externally switched domain that should not have a shutoff condition, or the switch rule is not specified.

Example

The following CPF description defines DSW as an internal switch domain (shutoff_condition is specified), but a switch rule is not defined:

create_power_domain -name DSW -instances {u_1} -shutoff_condition {!pe} \-secondary_domains DON create_ground_nets -nets GSW -voltage 1.0 -internalupdate_power_domain -name DSW -internal_power_net VDD -internal_ground_net GSW


CPF_GD3: Internally ground switched domain has no power switch rule.Severity: Error Occurrence: 11: Data/top.cpf:8 Internally ground switched domain DSW has no power switch rule.

An example fix - define a switch rule for this ground switched domain:

create_power_switch_rule -name SR1 -domain DSW -external_ground_net VSS



CPF Hierarchical

The following lists the rule checks for hierarchical CPF information:

■ CPF_HIER_MAP3 on page 403





■ CPF_HIER_MAP8a on page 410







■ CPF_HIER_MODE1 on page 417



■ CPF_HIER_CHK6 on page 422

■ CPF_HIER_CHK7 on page 423



CPF_HIER_MAP3

Message

Internal switched domain is mapped to a higher scope domain

Default Severity

Error

Description

A domain defined in a macro model or a hierarchical block-level CPF that is defined as internally switchable cannot be mapped to any domain during higher level instantiation via a domain mapping option.

Lower scope internally switched domains can be referenced in power modes directly. When multiple instances have this same type of domain which are ON and OFF at the same time, specify all those domains individually in the power mode definitions and remove the illegal mapping from the domain mapping list and correct the power modes.

Example

In the following example, PD2 is defined as an internal switched domain in block level CPF and mapped illegally to a higher level block domain and used in a higher block power mode:

create_power_domain -name LP2 -instances {x2} \-shutoff_condition {!pe} \-secondary_domains {LP1}

set_instance u_2 -domain_mapping {{LP1 D1} {LP2 D2}}

create_power_mode -name M1 -domain_conditions { D2@nom ...

This can be fixed with the following commands:

set_instance u_2 -domain_mapping {LP1 D1}

create_power_mode -name M1 -domain_conditions { u_2/D2@nom ...



CPF_HIER_MAP4

Message

External switched domain is not mapped to a higher scope domain

Default Severity

Error

Description

A power domain defined in a lower scope that is not defined as internally switchable must be mapped to a higher scope power domain.

Use the set_instance command to define the instance of the lower scope module with the -domain_mapping option to map external switchable and non switchable domains to domains at the higher scope.

Example

In the following example, in a design scope named ‘top’ with two power domains, D1 and D2 have instance u_2 of module block2, which has CPF defined with two power domains, LP1 and LP2, always ON and externally switchable type.

In the CPF, set_instance in ‘top’ scope, only LP1 is mapped to top domain D1. LP2 is not mapped and this is results in the following error report:

CPF_HIER_MAP4: An externally switched lower scope domain is not mapped to any higher scope domain

Severity: Error Occurrence: 11: Data/top.cpf:38 Lower scope domain: u_2/LP2 in instance u_2

This can be fixed with the following command:




CPF_HIER_MAP5

Message

An unswitchable domain is not mapped to any higher scope domain

Default Severity

Error

Description

A power domain defined in a lower scope that is not defined as internally switchable must be mapped to a higher scope power domain.

Use the set_instance command to define the instance of the lower scope module with the -domain_mapping option to map external switchable and non switchable domains to domains at the higher scope.

Example

In the following example, in a design scope named top with two power domains, D1 and D2, has instance u_2 of module block2 which has CPF defined with two power domains, LP1 and LP2, always ON, and externally switchable type. In the CPF set_instance in top scope, only LP2 is mapped to top domain D2. LP1 is not mapped and this results in the following error report:

CPF_HIER_MAP5: A non switchable lower scope domain is not mapped toany higher scope domainSeverity: Error Occurrence: 11: Data/top.cpf:38 Lower scope domain: u_2/LP1 in instance u_2





CPF_HIER_MAP6

Message

A block scope internal switched domain is not mapped to a higher scope internal switched domain or not referenced in power mode definition in the scope instantiating the lower scope block

Default Severity

Error

Description

You can map an internally switched lower-scope domain to only an internally switched upper-scope domain. If it is not mapped, then you must refer to it in the top scope power modes as <instance>/domain or using group modes as <instance>@<block_mode_name>.

Review the -verbose message to identify the lower scope domain name and the mapping, or the top scope power modes to identify and correct the CPF.

Applicability




CPF_HIER_MAP6a

Message

An unmapped macro scope internal switched switched domain is not referenced in power mode definition in the scope instantiating the macro model

Default Severity

Error

Description

An internally switched lower scope domain can only be mapped to an upper scope internal switched domain. If it is not mapped, then you must refer to it in the top scope power modes by <instance>/domain or by group modes option such as <instance>@<macro_mode_name>.

Review the -verbose message to identify the lower scope domain name and the mapping, or top scope power modes to identify and correct the CPF error.

Applicability




CPF_HIER_MAP7

Message

A macro or lower scope internal switched domain with multiple based domain is illegally mapped to a higher scope domain.

Default Severity

Error

Description

A lower design or macro scope domain that is internally switched must have the base domain of that scope mapped to the applicable base domains of the upper scope domain for which it is mapped.

Use the report rule check CPF_HIER_MAP7 -verbose command to view the lower scope domain name and instance, and to review the CPF domain definitions, base domains, and the mapping and correct any errors.

Applicability




CPF_HIER_MAP8

MessageA upper level internally switched domain with more than one base domain is mapped

with lower block level internally switched domain

Default Severity

Error

Description

An internal switchable domain from a lower scope can be mapped only to an internal switchable domain of a higher scope (internal switchable domains have either power or ground switching) with a single base domain.

Use report rule check CPF_HIER_MAP8 -verbose for more information on the power intent scopes and the domains involved.

Applicability

Applies to RTL, synthesized, and place and route netlists with hierarchical power intent



CPF_HIER_MAP8a

MessageA upper level internally switched domain with more than one base domain is mapped

with macro scope internally switched domain

Default Severity

Error

Description

An internal switchable domain from a macro model instance can be mapped only to an internal switchable domain of a higher scope (internal switchable domains have either power or ground switching) with a single base domain.

Use report rule check CPF_HIER_MAP8a -verbose for more information on the power intent scopes and the domains involved.

Applicability




CPF_HIER_MAP9

MessageBase domain of lower scope domain does not map to base domain of the mapped upper

scope domain.

Default Severity

Error

Description

The base domain of a macro model instance’s internally-switched domain must be mapped to the base domain of a design-switched domain that is consistent with the macro to design switched domain mapping.

When macro and design-switchable domains are mapped together, their base domains must be mapped together to avoid conflict in power intent.


Applicability




CPF_HIER_MAP10

MessageMapped lower and upper scope domains have shutoff condition conflict.

Default Severity

Error

Description

The lower scope of a macro or design model instance’s internal switchable domain must have a shutoff condition that is equivalent to the shutoff condition in the domain of the upper scope to which it is mapped.


Applicability




CPF_HIER_MAP11

MessageIllegal internal switched domain type mapping

Default Severity

Error

Description

The switch rule type (power or ground) must be the same between the higher scope of a design instance’s internal switchable domain and any lower design scopes that map to it. A switch rule type is defined by the option -external_power_net for power, or-external_ground_net for ground. The switch rules for both lower and higher scope domains must be compatible with the supply net option.


Applicability




CPF_HIER_MAP12

MessageMacro model internally switched domain is mapped to a higher unswitched domain and

the shutoff condition is not disabled.

Default Severity

Error

Description

When a macro model instance’s internally switched domain is mapped to a design scope domain that is not defined as OFF in any power mode, the macro shutoff condition must be disabled.


Applicability




CPF_HIER_MAP13

MessageUpper scope unswitched domain which is mapped with a macro scope internally switched

domain is not mapped with the base domain of the macro scope internally switched domain

Default Severity

Error

Description

When the design domain is defined as non-switchable, the macro model instance’s internally switched domain and base domain must be mapped to the same design domain.


Applicability




CPF_HIER_MAP14

Message

A macro scope internally switched domain has internal signal for its shutoff condition. It maps to an unswitched domain which is not virtual or never off.

Default Severity

Error

Description

Reported when a macro model internally-switched domain with a shutoff condition internal to the macro cell is mapped to a power domain that exists for objects in the top scope (not virtual) or is mapped to a virtual domain that is ON is all power modes. A macro model with an internally-switched domain must be mapped to a virtual top-level domain that is defined as OFF in 1 or more power modes.

Use the report rule check CPF_HIER_MAP14 -verbose command to view information on macro model and domain and correct the power intent.

Applicability




CPF_HIER_MODE1

Message

Conflict between power modes of mapped higher and lower scope domains

Default Severity

Warning

Description

This message warns that a new lower scope power mode is created by hierarchical domain mapping using the set_instance CPF command.

Check the verbose error message to see if this is expected. If not, then refine the power mode definition of the higher scope.

Example

In the following example, a design has an instance of a lower scope CPF module which has two power modes:

create_power_mode -name PM0 -domain_conditions {LP1@ON LP2@ON} -default

create_power_mode -name PM1 -domain_conditions {LP1@OFF LP2@ON}

An instance of this block is defined in higher scope block CPF and lower scope domains are mapped to higher scope domains. Based on the higher scope power modes, one additional lower scope mode is created, LP1@ON and LP2@OFF.


create_power_mode -name M1 -domain_conditions {D1@on D2@on D3@on} -default

create_power_mode -name M2 -domain_conditions {D1@on D2@on D3@off}

create_power_mode -name M3 -domain_conditions {D1@on D2@off D3@on

This results in the following report:

CPF_HIER_MODE1: Higher scope power mode does not exist in the lower scope power mode for the lower scope domains they are mapped with

Severity: Warning Occurrence: 11: Data/top.cpf:43 The relationships and voltage conditions

of the following higher scope modes between the higher scope domains do not have an identical mode for the lowerscope power domains they are mapped with.Lower scope instance ’u_2’, higher scope modes: M3



To fix this, add a new power mode in the block-level CPF with the following command:

create_power_mode -name PM2 -domain_conditions {LP1@ON LP2@OFF}



CPF_HIER_MODE2

Message

Lower scope power modes are unused in higher scope due to domain mapping

Default Severity

Warning

Description

This message warns that a lower scope power mode is removed by hierarchical domain mapping using the set_instance CPF command.

Check the lower scope mode name in the verbose report to see if removal of this lower scope mode is expected.

Example

In the following example, a lower scope block has three CPF defined power modes:

create_power_mode -name PM0 -domain_conditions {LP1@ON LP2@ON } -default

create_power_mode -name PM1 -domain_conditions {LP1@ON LP2@OFF}

create_power_mode -name PM2 -domain_conditions {LP1@OFF LP2@OFF}

An of this block is defined in higher scope block CPF and lower scope domains are mapped to higher scope domains and based on the higher scope power modes, one lower scope power mode, PM1, is not valid.


create_power_mode -name M1 -domain_conditions {D1@on D2@on D3@on} -default

create_power_mode -name M2 -domain_conditions {D1@on D2@off D3@off}


CPF_HIER_MODE2: Some modes in block are unused in the designSeverity: Warning Occurrence: 11: Data/top.cpf:42 These modes in block are not used in the

design Lower scope instance ’u_2’, lower scope modes: PM1

To fix this, add a power mode in a higher scope CPF with the following command:

create_power_mode -name M3 -domain_conditions {D1@on D2@off D3@on}



CPF_HIER_MODE3

Message

An internal switched domain is not specified in any upper mode

Default Severity

Error

Description

A domain defined in a macro model or a hierarchical block level CPF that is defined as internally switchable cannot be mapped to any domain during higher level instantiation via the domain mapping option.

Lower scope internally switched domains can be referenced in power modes directly. When multiple instances have this same type of domain which are ON and OFF at the same time, specify all those domains individually in the power mode definitions and remove the illegal mapping from the domain mapping list and correct the power mode.

Example

In the following example, LP2 is defined as an internal switched domain in block level CPF:

create_power_domain -name LP2 -instances {x2} \-shutoff_condition {!pe} \-secondary_domains {LP1}

In the higher scope CPF, LP2 is not specified in any power mode:

set_instance u_2 -domain_mapping {{LP1 D1}}

create_power_mode -name M1 -domain_conditions {D1@on D2@on} -default

create_power_mode -name M2 -domain_conditions {D1@on D2@off}


CPF_HIER_MODE3: An internal switched domain is not specified in anyupper power modeSeverity: Error Occurrence: 21: Data/block2.cpf:7 Internal switched domain u_2/LP2 is not

specified in up per mode M1.2: Data/block2.cpf:7 Internal switched domain u_2/LP2 is not

specified in upper mode M2



This can be fixed with the following commands:

create_power_mode -name M1 -domain_conditions {D1@on D2@on u_2/LP2@on} -default

create_power_mode -name M2 -domain_conditions {D1@on D2@on u_2/LP2@off}



CPF_HIER_CHK6

Message

Specifying mapping of power and ground nets is an error

Default Severity

Error

Description

Port mapping maps lower scope ports to upper scope ports. It is an error to specify power and ground ports for mapping.

To fix this, remove all power and ground ports from the port mapping list. Power and ground pin connections to lower scopes are either done through automatic power/ground net connection by the place-and-route tool, or by the create_global_connection CPF command.

Example

In the following example, the CPF description is:

set_instance u_1 -domain_mapping { LP1 PD1 } -port_mapping { VDD VDD1 }


CPF_HIER_CHK6: A power or ground object is specified by -port_mappingSeverity: Error Occurrence: 21: Data/top1.cpf:39 Port VDD specified in -port_mapping of

set_instance u_1 is a power net (pin) in block (module) block12: Data/top1.cpf:39 Port VDD1 specified in -port_mapping of

set_instance u_1 is a power net (pin) in block (module) top



CPF_HIER_CHK7

Message

Low scope instance port connection and port mapping conflict

Default Severity

Error

Description

A lower scope port defined with the -ports option in set_design command should connect to the specified port or instance pin. This error is generated whenever that is not true and the cause may be an incorrect specification due to spelling error, specifying the wrong upper scope port or pin, or connecting the lower scope port to the wrong port or pin in the upper scope.

Example

In the following example, a block has an isolation control pin named iso that is connected to a design top level port named iso2:

block2 u_2 (.in(out_1), .out(out_2), .iso(iso2));

The CPF instantiation of this block maps block port iso to a top-level port named iso1. This is different than what is implemented in the netlist:

set_design top

set_instance u_2 -domain_mapping { LP1 PD2 } -port_mapping { iso iso1 }


CPF_HIER_CHK7: A port of a module instance defined in set_instance is connected to a different object than specified by -port_mapping

Severity: Error Occurrence: 11: Data/top.cpf:40 The lower scope port iso and the upper

scope port iso1 specified in -port_mapping of set_intanceu_2 are not connected



CPF Isolation Cells

The following lists the Isolation Cell (CPF_ISO) rule checks:

■ CPF_ISO1 on page 426

■ CPF_ISO1a on page 427

■ CPF_ISO1b on page 428








■


■ CPF_ISO13a on page 437














CPF_ISO1

Message

Domain crossing has no isolation rule

Default Severity

Error

Description

When a crossing between two domains which can be in a mode defined by create_power_mode where the driving domain can be OFF when the receiving domain is ON and that crossing is not that the object of an isolation rule, this error is reported.

Review the verbose message identify the name of the driving (from) domain and the receiving (to) domain. The domain conditions or power modes might be specified incorrectly or the isolation rule needs to be specified.

Example

In this example a crossing from a switchable domain d2 (instance x1) to domain d1 (default) which is specified to be always ON does not have an isolation rule. This results in the following error report:

CPF_ISO1: No isolation rule specified for power domain crossingSeverity: Error Occurrence: 11: No isolation rule specified for power domain crossing

from x1/y (domain d2)to x2/B (domain d1)



CPF_ISO1a

Message

Domain crossing driven by tied constant has no isolation rule.

Default Severity

Error

Description

A power domain crossing is driven by a tied 1’b0 or 1’b1 in a domain that can be OFF when the receiving domain is ON.

Use report rule check CPF_ISO1a -verbose to get information related to the domains and the driving pin. If the power modes are correct, then ensure that an isolation rule with isolation output that is compatible with the constant value is added for this crossing.

Applicability

Behavioral models or design netlists that will have low power features added during future implementation.



CPF_ISO1b

MessageThere is no isolation rule for a crossing that is excluded in an isolation rule for

an ON domain to OFF domain crossing.

Default Severity

Error

Description

When a crossing is specified between two domains (using the -exclude list of an ON -> OFF isolation rule), the crossing must be covered in another isolation rule. Otherwise, the tool issues this message.

Use report rule check CPF_ISOb -verbose for more information on the isolation rule and the design pin.

Applicability

Applies to behavioral models or design netlists that will have low power features added during future implementation



CPF_ISO2

Message

Source domain is not compatible with isolation rule

Default Severity

Error

Description

An isolation rule by default is intended to isolation the ‘from’ or driving domain. The update isolation rule option ‘-isolation_target to’ can override the default. When the isolation target is the default ‘from’ domain and that domain is an always on domain based on power mode definitions, this error is reported.

Note: An addition CPF_ISO13 error result, isolation rule unnecessary between domains might also be reported for this domain crossing.

Review the verbose message to identify the name of the isolation rule and source domain. Possible fixes include modifying the power modes, update the isolation rule with ‘-isolation_target to’ if ON to OFF isolation is desired, or removing the rule.

Example

In the following example, a crossing from a non-switchable domain d1 (instance x1) to a switchable domain has an isolation rule defined with default isolation target ‘from.’ This results in the following error report:

CPF_ISO2: Isolation rule should not have been specified for source domain.Severity: Error Occurrence: 11: Data/Des.cpf:17 Isolation rule iso_r1 whose -isolation_target is

"from" (i.e., off-to-on isolation) should not be specified for alwayson source domain d1.from x1/y (domain d2)to x2/B (domain d1).



CPF_ISO3

Message

Destination domain is not compatible with isolation rule

Default Severity

Error

Description

When an isolation rule that applies to a ‘to’ domain that is always ON when the driving domain is ON and the isolation rule has option ‘isolation_target to’ that is valid for ON to OFF domain crossing, this error is reported.

Review the verbose message to identify the name of the isolation rule and the receiving (to) domain name. The domain conditions or power modes may be specified incorrectly or the isolation rule needs to be specified without the isolation target option.

There is an isolation rule with -isolation_target to that matches a power domain crossing where the destination domain is on.

Example

In the following example, a crossing from a switchable domain d2 (instance x1) to domain d1 (default) which is specified to be always ON has an isolation rule with an option to isolate for the mode when the from domain is ON and the to domain is OFF:

create_isolation_rule -name iso_it -from d2 -to d1 \-isolation_condition Iso -isolation_target to


CPF_ISO3: Isolation rule should not have been specified for destination domainSeverity: Error Occurrence: 11: Data/Des.cpf:17 Isolation rule iso_it (on-to-off) should not have

been specified for always on destination domain d1



CPF_ISO4

Message

Location in isolation rule is inconsistent with receiving domain(s)

Default Severity

Warning

Description

This indicates that an isolation rule that applies to a "to" domain via the -to <domain> option in a rule that specifies isolation location as “from,” and there are receivers of that driving domain signal that are not in the specified "to" domain list.

This is a warning by default. Synthesis or Place and Route software might be able to resolve the receiver conflict by duplicating the driver port and isolating only the receivers in the specified domain.

Review the verbose message to identify the name of the isolation rule, the driving and receiving (to) domain name. If the insertion tool can modify the design to insert isolation only for the nets driving the appropriate receivers, this message can be ignored. If the insertion tool does not insert correctly, this can be caught by running Conformal Low Power on the output netlist.

Example

In the following example, a crossing from a switchable domain d2 (instance x1) to domain d1 (default) to be placed in the from domain. The port of the from domain drives into both d1 and d3, the receivers in d3 do not require isolation.

create_isolation_rule -name iso_it -to d1 -pins "x1/Y" \-isolation_condition Iso \

update_isolation_rules -names iso_it -location from


CPF_ISO4: Isolation rule specifies inconsistent locationSeverity: Warning Occurrence: 11: Data/Des.cpf:20 Isolation rule iso_it specifies FROM location.

But one of the fanout’s of the source pin x1/U$1/O (domain d2)reaches a domain d3 not specified in the isolation rule’s TO domain list.Matching pin is x1/Y.



CPF_ISO5

Message

Multiple isolation rules apply to the same domain crossing

Default Severity

Warning

Description

This message occurs when multiple isolation rules apply to a single crossing between a driver and receiver in a different domain.

Review the verbose message for the isolation rule for the names of the from and to domains, the isolation rule names, and any matching pin names. To correct this, create non-overlapping rules using the -pins and -exclude options in the isolation rules.

If the isolation rules are not modified, the last isolation rule will be applied and it might cause problems if it is the inaccurate rule, as in the example.

Example

In the following example, a switchable domain pin drives to an unrelated switchable domain and an always on domain. There are two isolation rules.

create_isolation_rule -name iso1 -from d2 -to d1 \-isolation_condition Iso2

create_isolation_rule -name iso2 -from d2 -pins "x1/Y" \-isolation_condition Iso1


CPF_ISO5: Multiple isolation rules match power domain crossingSeverity: Error Occurrence: 11: Multiple isolation rules match power domain crossing

from x1/Y (domain d2)to x3/B (domain1).iso2 (matching pin x1/Y)iso1

Rule iso2 overrides the others.



CPF_ISO6

Message

Isolation library does not support specified isolation rule type

Default Severity

Error

Description

An isolation rule specifies where to put isolation cells, the isolation control, and the type of isolation cell with the -isolation_output option. This is low by default. This message is reported when there is no cell defined as isolation that has a function that is valid for the isolation output defined as default or specified in any isolation rule.

Review the verbose message to identify the name of the isolation rule and the specified isolation type and review the cells with the define_isolation_cell CPF command to check if a valid isolation cell can be defined to satisfy the requirements of the reported isolation rule.

Example

In the following example, an isolation rule is defined with high type output:

create_isolation_rule -name IsoHi -isolation_output high ...

In the library, all the defined isolation cells are AND functions. They isolate to low so there is no isolation cell available to meet the requirements of the isolation rule for insertion. This results in the following error report:

CPF_ISO6: Isolation rule ignored because there is no matching isolation cell type

Severity: Error Occurrence: 11: Data/Des.cpf:17 Isolation rule IsoHi ingored because there is no

isolation cell with type high.



CPF_ISO7

Message

Cell specified in isolation rule conflicts with specified rule type

Default Severity

Error

Description

An isolation rule specifies where to put isolation cells, the isolation control, and the type of isolation cell with the -isolation_output option. This is low by default. You can use the update_isolation_rules command to define specific isolation cells to be used by this rule. When the cell specified has an isolation function (type) that is different than defined by the isolation output option, it is an error.

Review the verbose message for the isolation cell specified in the update isolation rule, the specified cell type, the specified type defined in the rule, and the rule name and determine if the rule type needs to be changed or if the cell specified in the update isolation rule is incorrect.

Note: It is not necessary to define the -cells option in the update_isolation_rules command. All tools that support CPF can automatically select the best candidate.

Example

In the following example, an isolation rule is defined with high type output

create_isolation_rule -name IsoHi -isolation_output high ...

The update isolation rule calls a cell with low type output (AND function):

update_isolation_rules -names IsoHi -cells IsoHL


CPF_ISO7: Isolation cell type conflicts with type specified in isolation ruleSeverity: Error Occurrence: 11: Data/Des.cpf:7 Isolation cell IsoHL type(low)conflicts with type(high)

specified in isolation rule IsoHi.



CPF_ISO8

Message

Cell specified in isolation rule is not defined as an isolation cell

Default Severity

Error

Description

An update_isolation_rules CPF command’s -cells option defines a list of isolation cells to use for an isolation cell. When a cell defined in that list is not defined as an isolation cell, this error will result.

Review the verbose message for the isolation cell specified in the update_isolation_rules command and the rule name, and determine if the cell name is correct or if the define_isolation_cell command is missing for the specified cell.


Example

In the following example, an isolation rule and update isolation rule calls a cell that is not defined as an isolation cell:

create_isolation_rule -name IsoHiupdate_isolation_rules -names IsoHi -cells IsoHH


CPF_ISO8: The update isolation rule calls a cell not defined throughdefine_isolation_cellSeverity: Error Occurrence: 11: Data/Des.cpf:17 Cell IsoHH specified in isolation rule IsoHi is

not an isolation cell in CPF.



CPF_ISO13

Message

Domain definitions and power modes conflict with isolation rule

Default Severity

Error

Description

A domain crossing that is not OFF->ON in any mode has an isolation rule with an isolation target of from (default); or, a domain crossing that is not ON->OFF in any mode has an isolation rule with isolation target of to.

Use the report rule check CPF_ISO13 -verbose command to view information on the domains and the rule, to correct the power modes, or correct/remove the isolation rule.

Applicability




CPF_ISO13a

Message

Isolation rule is defined between two domains without any signal crossing

Default Severity

Warning

Description

An isolation rule applies to crossing that does not exist.

Use report rule check CPF_ISO13a -verbose to get information on the isolation rule. Check that the defined domains are correct and that the connections for the design are complete.

Applicability




CPF_ISO15

Message

Inconsistent isolation rule insertion location and specified cell

Default Severity

Error

Description

An update_isolation_rules CPF command -cells option defines a list of isolation cells to use for an isolation cell. By default, an isolation rule defines the insertion location to be TO domain and this can be changed to FROM domain with update_isolation_rules command’s -location option.

In define_isolation_cell, the -valid_location option defines the location that isolation cell can be placed in and therefore restricts its usage to an isolation rule with the same location. When a rule location (by default or by update_isolation_rules) is different than the -valid_location option specified in define_isolation_cell for the isolation cell in the list of the -cells option, the isolation rule is not legal.

Review the verbose message for the isolation cell specified in update_isolation_rules. Review its location, and the location of the specified rule name, and correct the rule location, cell valid location, or remove the cell from the -cell list.


Example

In the following example, an isolation rule and an update_isolation_rules command calls a cell defined with valid location from. The isolation rule location is to (the default).

define_isolation_cells -cells IsoHH -valid_location from

create_isolation_rule -name IsoHiupdate_isolation_rules -names IsoHi -cells IsoHH


CPF_ISO15: Isolation cell location conflicts with location specifiedin isolation rule.



Severity: Error Occurrence: 11: Lib/Lib.cpf:11 Isolation cell IsoHH location (from) conflicts with

location (to) specified in isolation rule IsoHi



CPF_ISO17

Message

Isolation cell location conflicts with location inferred from liberty

Default Severity

Warning

Description

The location of the isolation cell location conflicts with location specified from the Liberty library.



CPF_ISO18

Message

Isolation cell enable pin conflicts with enable specified in liberty

Default Severity

Error

Description

The isolation cell enable pin specified in CPF is different from the enable pin specified in the library.



CPF_ISO19

Message

Isolation polarity conflict in two isolation rules for a domain

Default Severity

Error

Description

Both edges of an isolation condition are used for the two isolation rules with same crossings and isolation target.



CPF_ISO20

Message

Isolation rule isolation target "to" is incompatible with "to" location

Default Severity

Error

Description

Isolation rule with an isolation target TO is specified with location TO.



CPF_ISO21

Message

Isolation rule is ignored for domain crossing

Default Severity

Warning

Description

An isolation rule is ignored for a crossing.



CPF_ISO22

Message

Isolation rule condition is an expression of multiple signals

Default Severity

Error

Description

Multiple signals are defined in an isolation rule’s isolation condition.



CPF_ISO23

Message

Isolation rule without condition mssing required isolation output type

Default Severity

Warning

Description

Rule applied to the crossing does not have isolation condition and the crossing does not have default isolation condition.



CPF_ISO24

Message

Isolation condition conflict between two rules

Default Severity

Error

Description

Two isolation conditions conflict.



CPF_ISO25

Message

Isolation location is not compatible for defined isolation cells

Default Severity

Warning

Description

The isolation location specified is not valid for the isolation cells defined in the library.



CPF_ISO26

Message

Isolation rule for type constraint is missing for a lower scope input

Default Severity

Warning

Description

A lower scope input data port does not have an isolation rule for some of its associated or loaded domains.



CPF_ISO27

Message

Crossing requiring isolation and level shifter is not supported by low power library cells

Default Severity

Error

Description

A crossing’s applied isolation rule and level shifter rule have same location. No combo cell is available and location of the applied isolation rule cannot be changed because the library does not support it.



CPF_ISO28

Message

Isolation rule for lower scope input does not specify isolation type

Default Severity

Warning

Description

A lower scope isolation rule for an input data port does not have -isolation_output specified



CPF_ISO29

Message

Isolation rule output type conflicts with tied input value

Default Severity

Warning

Description

A domain crossing with tied 0 (1’b0) has an isolation rule with output type high; or, a crossing with a tied 1 (1’b1) driver has an isolation rule with output type low. The isolation assertion will change the desired function of the tied logical value. For example, it will isolate an active low reset that is tied to 0 to a 1 logic value, forcing a reset through isolation.

Use the report rule check CPF_ISO29 -verbose command to view information on the rule and to correct the isolation output so that it matches the tied logic value.

Applicability




CPF_ISO30

Message

Isolation rules with no enable option is not compatible when using special buffer for isolating control signals

Default Severity

Error

Description

This message is flagged when the low power option -iso_no_enable_is_control_buffer is set and the isolation rule has the -no_enable option set.

Applicability




CPF_ISO32

Message

Signals defined for isolation control come from different power domains

Default Severity

Error

Description

An isolation rule has an isolation_condition that is an expression of multiple control pins that come from different domains. This can occur when blocks with the isolation control are assigned to different domains.

Use the report rule check CPF_ISO32 -verbose command to view information on the control signals and their driving domains.

Applicability




CPF_ISO33

Message

Expression arguments defined in an isolation condition are also defined as set_equivalent_control_pins group

Default Severity

Warning

Description

An isolation rule isolation_condition is an expression of multiple control pins that are defined as equivalent control pins. If the intent is that each control pin drives different groups of isolation cells, then use the equivalent control pin master in only the isolation rule. If the intent is to synthesize the expression in the rule and output drive all isolation cells, remove the set equivalent control pins definition.

Use the report rule check CPF_ISO33 -verbose command to view information about the isolation rule and control pins.

Applicability




CPF_ISO34

Message

Isolation cell drives the set, reset, or clock pin of a latch or flip flop.

Default Severity

Warning

Description

This warning identifies isolation cells that drive state element control signals. Use this information to verify the type of isolation cell that is compatible with the control polarity to avoid having a false clock edge, set, or reset when isolation is asserted.

Use the report rule check CPF_ISO34 -verbose command to view information on the rule and state element instances.

Applicability




CPF_ISO35

Message

Pin listed in isolation rule is not in the domain crossing

Default Severity

Warning

Description

An isolation rule specifies a pin that is not related to the driver and/or receiving domain that is specified in the -from and/or -to of the rule. CPF semantics specify that the domain specification is the first filter; therefore, in this case, the isolation rule does not apply to this pin. Check that the domain specification and pin names are correctly specified.

Use the report rule check CPF_ISO35 -verbose command to view information about the isolation rule and pin names.

Applicability




CPF_ISO37

Message

Domain of the specified instances conflicts with the location defined in the isolation rule

Default Severity

Error

Description

This message is issued when an isolation rule defines a within_hierarchy <instance> and the updated isolation rule defines a -location from or to, but the instance is not part of the domain specified with location.

Use the report rule check CPF_ISO37 -verbose command to view information on the rule, information on the domains of the driver, receiver, and instance, and to review the power modes for information on the nominal condition relationships.

Applicability




CPF_ISO39

Message

Isolation rule specifies insertion inside a Hard IP, external to the boundary, or library cell

Default Severity

Error

Description

Isolation cells cannot be inserted into a module that is a blackbox, library cell, or an external to the boundary. This rule message indicates that an isolation rule was updated to specify such an insertion using the -location or -within_hierarchy options.

Use report rule check CPF_ISO39 -verbose to get details on the rule and the black box instance and cell name.

Applicability




CPF_ISO40

Message

Valid location of the specified isolation cell is not compatible with the domain of the specified insertion hierarchy

Default Severity

Error

Description

The updated isolation rule indicates that cells should be inserted at a particular location (through the -cell option), but the valid location of one or more cells is not compatible with the rule insertion location (based on the rule -within_hierarchy option or the update rule -location option).

Use report rule check CPF_ISO40 -verbose for more information on the rule and cells that are not compatible with rule insertion location.

Applicability




CPF_ISO41

Message

Isolation library does not support the insertion hierarchy specified in the isolation rule

Default Severity

Error

Description

The update isolation rule has conflicting -within_hierarchy and -location options. In other words, the instance specified by -within_hierarchy is not the same as the -from or -to domain specified by -location.

Use the report rule check CPF_ISO41 -verbose command to view information on the rule and location specifications and correct the conflict.

Applicability




CPF Level Shifter Cells

The following lists the Level Shifter (CPF_LS) rule checks:

■ CPF_LS1 on page 463

■ CPF_LS1a on page 464




















CPF_LS1

Message

Signal driving different voltage region has no level shifter rule

Default Severity

Error

Description

There is no level shifter rule specified on a crossing between two power domains defined in power modes as operating at different voltage levels.

If the voltage levels are within desired tolerance range, use the ADD RULE FILTER Conformal Extended Checks command to remove this message from the reporting.

If a level shifter is necessary, use the create_level_shifter_rule CPF command to define this crossing as needing a level shifter.

Example

In the following example, a gate with hierarchical instance name ‘xlow/x1’ in power domain ‘lo’ operates on voltage 1.0V. This drives a logic gate with hierarchical instance name ‘xhi/xl,’ which resides in power domain ‘hi’ that operates on 1.2V. There is no CPF level shifter rule defined for this crossing. This results in the following error report:

CPF_LS1: No level shifter rule specified for power domain crossingSeverity: Error Occurrence: 1 1: No level shifter rule specified for power domain crossing

from xlow/x1/Y (domain lo) to xhi/x1/A (domain hi)



CPF_LS1a

Message

Tied signal driving different voltage region has no level shifter rule

Default Severity

Error

Description

A design instance pin that is tied to 1b’0 or 1b’1 drives a receiver in a domain that has a different power or ground voltage condition in one or more power modes; therefore, this crossing does not have a level shifter rule.

Use the report rule check CPF_LS1 -verbose command to view information on the location of the tied signal and to add a level shifter rule.

Applicability




CPF_LS2

Message

Level shifter rule is unnecessary based on power mode definitions

Default Severity

Error

Description

A level shifter rule for a crossing between two power domains is determined to be not necessary. If the domains are always at the same voltage or are within a defined tolerance in all modes, this error is reported.

Check the defined power modes and nominal conditions. There are many causes for this error: nominal condition defined with the wrong voltage power mode definitions incomplete or incorrect, or the level shifter rule is invalid. You can review the power specification and fix the cause appropriately.

Example

In the following example, in CPF, a level shifter rule named lsrule is specified as following:

create_level_shifter_rule -name lsrule -from lo -to hi

There is only one power mode defined as follows:

create_power_mode -name all -domain_conditions {lo@l hi@h } -default

However, the following CPF command shows both operating condition ‘l’ and ‘h’ operate at the same voltage level of 1.0.

create_nominal_condition -name l -voltage 1.0create_nominal_condition -name h -voltage 1.0


CPF_LS2: Level shifter rule unnecessary between power domains.Severity: Error Occurrence: 1 1: Data/Des.cpf:23 Level shifter rule lsrule is unnecessary

between domains lo to hi.

One way to fix this problem is to redefine the voltage value of nominal condition ‘h’.



CPF_LS3

Message

Level shifter rule specifies invalid cell based on defined power modes

Default Severity

Error

Description

The level shifter cell defined to be used for a power domain crossing based on create and update level shifter rules does not support the voltage conditions of the from and to domains the level shifter rule applies.

Review the detailed error message for the level shifter cell, shifter voltage value, and the domain name. Make sure the cell defined by the update_level_shifter_rules CPF command’s -cells option is valid for the from and to domain based on the domain operation conditions defined in create_power_mode, and check the CPF definition of voltage range for the cell is correct.

Example

In the following example, a level shifter LevLH is specified to be used between a driving domain of 1.0 volt and a receiving domain of 1.2 volts:

define_level_shifter_cell -cells LevLH \-input_voltage_range 1.0 \-output_voltage_range 1.2 \

Level shifter rule lsrule is specified for ‘lo’ domain to ‘hi’ domain crossing and update level shifter rule specifies the LevLH cell to be used for those crossings:


update_level_shifter_rules -names lsrule -cells LevLH

In the CPF the domain ‘hi’ is defined to have a nominal voltage value of 1.5 volts in all power modes and this is not consistent with level shifter cell LevLH CPF definition of output voltage range (shown above). This results in the following error report:

CPF_LS3: Level shifter cell voltage does not match with what is expectedin the level shifter rule

Severity: Error Occurrence: 1



1: Data/Des.cpf:23 Level shifter cell LevLH receiving voltage(1.2V) does not match domain hi’s voltage in levelshifter rule(lsrule).

It is not necessary to specify the -cells option. Synthesis and place-and-route tools can select the correct level shifter based on crossing voltages for automatic insertion.



CPF_LS4

Message

Level shifter cells do not exist to support voltages of crossings defined by level shifter rule

Default Severity

Error

Description

There is no level shifter cell defined in CPF spec to match the corresponding level shifter rule. Check the verbose error message for the level shifter rule, identify all the domain operating conditions for the from and to domains, and determine if it is safe to redefine level shifter definitions to support the ranges required by the design.

Example

In the following example, a level shifter rule ‘lsrule’ is specified with the command:


Based on the nominal condition and power modes, domain ‘lo’ operates at 1.0 volts and power domain ‘hi’ operates at 1.5 volts, specified with the following commands:

create_nominal_condition -name l -voltage 1.0

create_nominal_condition -name h -voltage 1.5

create_power_mode -name all -domain_conditions {lo@l hi@h } -default

Checking the CPF definitions of level shifters, there are level shifters defined, but none of those have an input and output voltage range defined that supports a 1.0 volt to 1.5 volt crossing. This results in the following error report:

CPF_LS4: Level shifter rule ignored because there is no matching level shifter cell

Severity: Error Occurrence: 1 1: Data/Des.cpf:23 Level shifter rule lsrule ignored because

there is no level shifter cell available with matching voltage.



CPF_LS5

Message

Multiple level shifter rules apply to signal crossing voltage regions

Default Severity

Error

Description

A signal with a driver in one domain and one or more receivers in another domain is the object of multiple level shifter rules. Review the level shifter rules reported in the verbose error report to see if there is a conflict based on the definition of update level shifter rule that results in different cells specified by the -cells option or different location (default location is ‘to’).

If there is a conflict the user should refine the 2 rules so that all original crossings have a level shifter rule, but there is no overlap between the rules.

If there is no conflict, remove the rule that is the subset of the other.

Example

In the following example, a design CPF file has a level shifter rule based on a ‘from’ and ‘to’ power domain, and a level shifter rule based on a specified hierarchical pin name, which is part of the crossing between the ‘from’ and ‘to’ domains of the first rule:

create_level_shifter_rule -name lsrule1 -from lo -to hi

create_level_shifter_rule -name lsrule2 -pins xl/Y


CPF_LS5: Multiple level shifter rules match power domain crossing Severity: Error Occurrence: 1 1: Multiple level shifter rules match power domain crossing

from xl/x1/Y (domain lo)to xh/x1/A (domain hi)lsrule2lsrule1Level shifter rule lsrule2 overrides the others



CPF_LS7

Message

Cell specified in level shifter rule is not defined as a level shifter

Default Severity

Error

Description

The ‘update_level_shifter_cell’ CPF command has a ‘-cells’ option to specify cells to be used for the level shifter rule being updated. When any cell defined as argument of the ‘-cells’ option is not defined as a level shifter cell with ‘define_level_shifter_cell,’ this results in this error.

Review the verbose error message and correct the cell name, add the ‘define_level_shifter_cell’ command for that cell. Alternatively, you can remove the ‘-cells’ option so that low power synthesis or place-and-route tool will automatically select valid level shifters. There is no need for you to define the cells to be used for any rule.

Example

In the following example, CPF creates and updates a level shifter rule:


update_level_shifter_rules -names lsrule -cells SC_BUF -location to

The cell SC_BUF is not defined as a level shifter cell and therefore is not valid to be specified as an argument to ‘-cells’ option in update rule. This results in the following error report:

CPF_LS7: Cell specified in level shifter rule is not a level shifter cellSeverity: Error Occurrence: 1 1: Data/Des.cpf:23 Cell SC_BUF specified in level shifter rule

lsrule is not a level shifter cell in CPF (Lib/Lib.v:72)



CPF_LS9

Message

Level shifter rule with 'from' location has receivers in multiple voltage regions

Default Severity

Warning

Description

When a level shifter rule defines a level shifter location as ‘from’ and the related from domain port fans out to multiple power domains which creates a conflict for the level shifter rule, it results in this message.

Specific synthesis tools can automatically fix this by creating a new port in the from domain to unrelated to domains and bypass the level shifter.

Review the verbose error message to find the level shifter rule name, source pin name, and to domain name. If the synthesis or place-and-route tool cannot automatically fix this conflict, you can manually fix it by creating an extra port to bypass the port which needs shifting, or define the location in the ‘to’ domain if a valid level shifter exists. You do not have to determine validity, just comment the update level shifter rule and the Conformal Low Power software will report if a valid shifter does not exist.

Example

In the following example, CPF creates and updates a level shifter rule:

create_level_shifter_rule -name lsrule1 -from lo -to hi1

update_level_shifter_rules -names lsrule1 -location from

Source domain pin x1/x1/Y fans out into both hi1 and hi2 domain. A single level shifter cannot be inserted to satisfy both receiving domains. This results in the following error report:

CPF_LS9: Level shifter rule specifies inconsistent locationSeverity: Error Occurrence: 1 1: Data/Des.cpf:27 Level shifter rule lsrule1 specifies FROM

location. But one of the fanout’s of the source pin xl/x1/Y reaches a domain hi2 not specified in the level shifter rule’s TO domain list.



CPF_LS10

Message

Level shifter rule specified instance name prefix is not in level shifter instance name

Default Severity

Warning

Description

Incorrect naming style has been specified for level shifter instance.



CPF_LS12

Message

Level shifter cell enable conflicts with enable specified in liberty

Default Severity

Error

Description

Level shifter cell enable pin specified in CPF is different from the enable pin specified in the library.



CPF_LS13

Message

A level shifter rule is ignored for a crossing

Default Severity

Error

Description

When domain mapping limits nominal conditions of the from and to domains such that level shifting is not required, you do not need a level shifter rule for hierarchical power intent in the lower scope. The level shifter rule will be optimized unless you use the -non_optimization option with the WRITE POWER INTENT command.

Applicability




CPF_LS14

Message

Level shifter rule location changed to match what library can support

Default Severity

Warning

Description

Hierarchical power intent integration has changed the insertion location of a level shifter rule to match the location that the low power library can be support.

Applicability




CPF_LS15

Message

Crossing requiring isolation and level shifter is not supported by low power library cells

Default Severity

Error

Description

When a crossing is from a driver that can be switched off when the receiver is on and that can operate at a different voltage than the receiver, the crossing requires isolation and level shifting. There are no low power cells defined in the library that can be inserted to support the crossing.

Use the report rule check CPF_LS15 -verbose command to view information on the domain crossing, and to review power modes. Using the power mode information, you can understand the insertion requirements by checking the nominal condition relationships of the driver and receiver domains.

Applicability




CPF_LS18

MessageLevel shifter rule applies to pin with receivers having different voltage

conditions.

Default Severity

Warning

Description

Indicates that a level shifter rule specifies a location for the source (from) domain and has multiple receiving domains and the receivers can be at different nominal conditions in one or more power modes.

Implementation tools might be able to optimize the netlist to add multiple level shifters to resolve the conflict between the single source pin and multiple receivers with different voltages. If the implementation tools cannot resolve the conflict, Low Power structural checks will report errors on the implemented netlists.

Use report rule check CPF_LS18 -verbose for more information on the level shifter rule and the receiving pins.

Applicability




CPF_LS19

MessageDomain of the specified insertion hierarchy conflicts with the location defined in

the level shifter rule.

Default Severity

Error

Description

An update level shifter rule specifies -within_hierarchy and the -location options, but the domain of the instance specified by the -within_hierarchy option is not the same domain as the domain defined by the -location option (from or to) and causes an implementation conflict.

Use report rule check CPF_LS19 -verbose for more information on the level shifter rule and review the power intent and design domain specification to see which option of the rule is incorrect and remove it.

Applicability




CPF_LS21

MessageLevel shifter rule specifies insertion inside a Hard IP, external to the boundary,

or library cell.

Default Severity

Error

Description

Level shifters cannot be inserted into an instance that is a blackbox, library cell, or a hard IP macro. This rule message indicates that a level shifter rule specifies to insert a level shifter in an instance that is a black box, a library cell, or an external to the boundary. The insertion was either specified by default or the level shifter rule was updated using the -location or -within_hierarchy options.

In some cases, you will need to create a wrapper around the blackboxed instance and assign this to the domain where the level shifter would be inserted; this requires modifying the RTL netlist to enable implementation based on power intent specification.

Use report rule check CPF_LS21 -verbose to get detailed information on the level shifter rule and review the specified location and reported driver and receiver objects.

Applicability




CPF_LS22

MessageSpecified insertion level shifter using with hierarchy is not compatible with both

the driver and receiver domains and requires a level shifter that can be inserted in any location and there is no legal level shifter in the library to meet the requirements.

Default Severity

Error

Description

Indicates that the level shifter rule specifies a location (by default or using -location or -within_hierarchy), but the updated level shifter rule is not compatible with the driver and receiver domains and the library database does not have a shifter cell(s) with any valid location that supportsthis voltage crossing.

Use report rule check CPF_LS22 -verbose for more information on the level shifter rule, specified location domain, and driver/receiver domains. Review the power modes and correct the location of the rule so that it is compatible with the driver and receiver domains in all power modes.

Applicability




CPF_LS23

MessageValid location of the specified level shifter cell is not compatible with the domain

of the specified insertion hierarchy

Default Severity

Error

Description

The -cells option of the update_isolation_rules command specifies the level shifter cells to use when inserting the crossings for the rule. This message indicates that the valid location of a level shifter cell is not compatible with the insertion location. For example, a level shifter cell with valid location of from is specified in a level shifter rule with a default insertion location of from. This conflict cause issues during place and route and power connectivity.

Use report rule check CPF_LS23 -verbose for more information on the level shifter rule, its specified location, and its level shifter cells. Use this information to review the desired location with the library and change the insertion location and to specify cells that are compatible with the specified location.

Applicability




CPF_LS24

MessageLevel shifter library does not support specified insertion hierarchy defined in the

level shifter rule.

Default Severity

Error

Description

A level shifter rule specifies an insertion location that can not be supported by any cell defined as a level shifter based on the level shifter -valid_location option.

Use report rule check CPF_LS24 -verbose for more information on the level shifter rule and location and to review the level shifter cells defined.

If the level shifter library specification is correct, change the insertion rule to reflect a supported location.

Applicability




CPF Library

The following lists the CPF Library (CPF_LIB) rule checks:

■ CPF_LIB1 on page 484



■ CPF_LIB3a on page 488



















■ CPF_LIB21a on page 515




CPF_LIB1

Message

Inconsistent cell names between library views

Default Severity

Error

Description

A cell defined in CPF with the ‘define_’ command is not found in the cell library database. Check the Verilog simulation library or the Liberty library paths for completeness.

Example

In the following example, there is no is no cell named IsoLH in the library database.

set_design TopMod

create_power_domain -name hi -instances { xh ih ) -boundary_ports { C D Z }


CPF_LIB1: CPF cell is not defined in librarySeverity: Error Occurrence: 11: Lib/Lib.cpf:11 cpf cell ’IsoLH’ does not have a library view



CPF_LIB2

Message

Inconsistent cell port names between library views

Default Severity

Error

Description

The CPF definition for a cell includes a non power or ground port with a name that does not match any port in the library cell database.

Look at the Verbose error which provides the file and line number for both CPF and Verilog or Library file for the cell in question and compare the port names.

Example

In the following example, if the Liberty CPF file contains:

define_isolation_cell -cells IsoLL -enable I_module IsoLL (

There is no is no cell named IsoLH in the library database. This results in the following error report:

CPF_LIB2: Cell port mismatch for low power cell in CPFSeverity: Error Occurrence: 11: Lib/Lib.cpf:7 cpf cell ’IsoLL’ has port ’I_’

not defined in library view (Lib/Lib.v:22)

Note: When the cell is an isolation cell and the port mismatch is the enable, the software will also report a redundant CPF_LIB10 error for this situation.



CPF_LIB3

Message

Inconsistent cell port types between library views

Default Severity

Error

Description

A cell port can be of type power, ground, or not specified in LEF file. This error reports CPF defined ports: control, power, and ground type, that do not match the port type for that cell defined in LEF format. Look at the Verbose error which provides the file and line number for both CPF and LEF files for the cell in question and compare the CPF and LEF definition of the reported port.

In addition to using LEF to define power and ground ports, you can read in the Spice library with the READ LIBRARY command’s -spice and -circuit_view options, and with the proper global power and ground port definitions:

*.GLOBAL <pwr>:P <gnd>:G <pwr>:P <gnd>:G ...

This will also define power and ground ports. You can also define power and ground ports using the following command:

add cell port -module <name> -power <power nets ...> -ground <ground nets ...>

Example

In the following example, if the Liberty CPF file contains:

define_level_shifter_cell -cells LevLH -input_power_pin VL -output_power_pin VH

and the Library LEF file contains:

MACRO LevLHCLASS CORE ;PIN VL

DIRECTION INOUT ;USE POWER ;

END VLPIN VH

DIRECTION INOUT ;END VH



Pin VH in the LEF file for cell LevLH needs to have USE POWER to be compatible with the CPF definition.


CPF_LIB3: Cell port type mismatch for low power cellSeverity: Error Occurrence: 1

1: Lib/Lib.cpf:33 cpf cell ’LevLH’ has power port ’VH’ not defined as a power port with LEF, spice, or add cell port (Lib/Lib.lef:48)



CPF_LIB3a

Message

Library view power and ground ports check is disabled

Default Severity

Warning

Description

CPF_LIB3a indicates that power/ground port checking is not performed. This occurs when the netlist style is logical or hybrid, and all cells do not have power/ground ports defined (unlike CPF_LIB3, which flags individual cells).

To fix this warning, read in the LEF or Spice library, or use the ADD CELL PORT command to define power/ground ports. The tool will check the power/ground port definitions.

Example

In this dofile example, the netlist style is set to logical and power/ground port definitions are not read in:

set lowpower option -netlist_style logical//read lef file Lib/Lib.lefread library Lib/Lib.vread power intent Lib/Lib.cpf -library

This resulting verbose warning report:

CPF_LIB3a: Power and ground ports will not be checked.Severity: Warning Occurrence: 11: Power/ground ports are not checked for logical/hybrid netlist with no power/ground ports defined



CPF_LIB4

Message

Inconsistent cell port directions between library views

Default Severity

Error

Description

Analyzes library checks to ensure the port direction of the control signals defined in CPF for low power signals are consistent with the library model. When port directions are inconsistent, it causes several errors during low power analysis that are difficult to debug and find the real cause: a bad direction for a control signal pin or CPF definition of that signal.

Check the verbose error report for the cell and port and compare the CPF definition and the Liberty or Verilog model and fix the port direction as needed.

Example

In the following example, cell LP_PSW is defined as a power switch cell with Ei as the enable control input, and Eo as the buffered output version of Ei. In the model, both Ei and Eo are defined as being input direction ports. This conflicts with the CPF definition of Eo port:

module LP_PSW (Ei, Eo, Vi, Vo, VSS);input Ei, Eo, Vi, VSS;output Vo;

Running the following command:

define_power_switch_cell -cells LP_PSW -stage_1_output Eo

results in the following error report:

CPF_LIB4: Cell port direction mismatch for low power cellnot compatible with the model structure

Severity: Error Occurrence: 11: Lib/Lib.cpf:23 CPF cell ’LP_PSW’ stage output ’Eo’ is

input port in library view



To fix this, change the model port direction as follows:

module LP_PSW (Ei, Eo, Vi, Vo, VSS);input Ei, Vi, VSS;output Eo, Vo;



CPF_LIB5

Message

Library model view of low power cell does not exist

Default Severity

Warning

Description

Complete models of all low power cells are required for complete verification. When a low power cell does not have a model function defined in the Library (Liberty or Verilog format), this error alerts you to add the model information before continuing analysis on the design.

Example

In the following example, in the Verilog Library, an isolation cell and ports are defined but there is no model or structure to define the isolation function:

module IsoLL (A, Ib, Y);input A, Ib;output Y;

endmodule


CPF_LIB5: CPF cell is black boxed in library.Severity: Error Occurrence: 11: Lib/Lib.cpf:7 cpf cell ’IsoLL’ is black boxed in library



CPF_LIB6

Message

Library cell does not have a power port defined

Default Severity

Error

Description

A LEF file can be used to define power and ground ports of standard cells. This is required for verification of post place-and-route netlists with power and ground net connectivity to leaf cells. When a standard or macro cell does not have one or more ports defined as power type in the LEF file, this results in an error.

You can fix this by adding the power port information in the LEF file for that cell, or use the Conformal Low Power’s ADD CELL PORT command to define this without modifying the LEF file.

Example

In the following example, In the LEF description of the SC_XOR cell, VDD PIN is defined but it is not specified with USE POWER:

PIN VDDDIRECTION INOUT ;

END VDD

Resulting in the following error report:

CPF_LIB6: Library cell power port cannot be determined by data from LEF,add cell port or spiceSeverity: Error Occurrence: 11: Library cell ’SC_XOR’ power’ port cannot be determinedby data from LEF

It can be fixed in the LEF in the following fashion:

PIN VDDDIRECTION INOUT ;USE POWER ;

END VDD

The Conformal Low Power command to fix this is:



add cell port -module SC_XOR -power VDD -ground VSS

Note: This command must identify all power and ground ports, even if they are previously defined in the LEF file.



CPF_LIB7

Message

Library cell does not have a ground port defined

Default Severity

Error

Description

A LEF file can be used to define power and ground ports of standard cells. This is required for verification of post place-and-route netlists with power and ground net connectivity to leaf cells. When a standard or macro cell does not have one or more ports defined as ground type in the LEF file, this results in an error.

You can fix this by adding the ground port information in the LEF file for that cell, or use the Conformal Low Power’s ADD CELL PORT command to define this without modifying the LEF file.

Example

In the following example, In the LEF description of the SC_XOR cell, VSS PIN is defined but it is not specified with USE GROUND:

PIN VSSDIRECTION INOUT ;

END VSS

Resulting in the following error report:

CPF_LIB7: Library cell ground port cannot be determined by data from LEF, add cell port or spice

Severity: Error Occurrence: 11: Library cell ’SC_XOR’ ground’ port cannot be determined

by data from LEF

It can be fixed in the LEF in the following fashion:

PIN VSSDIRECTION INOUT ;USE POWER ;

END VSS



The Conformal Low Power command to fix this is:

add cell port -module SC_XOR -power VDD -ground VSS

Note: This command must identify all power and ground ports, even if they are previously defined in the LEF file.



CPF_LIB8

Message

Library cell is defined with multiple power ports

Default Severity

Error

Description

A LEF file can be used to define power and ground ports of standard cells. This is required for verification of post place-and-route netlists with power and ground net connectivity to leaf cells. When a cell defined in LEF has multiple ports defined with USE POWER and that cell is not defined as a low power cell, this is reported as an error. If not fixed this will impact the quality of power analysis.

If the cells reported are isolation, level shifters, state retention, power switches, ground switches, always-on buffers, or clamp cells that are not defined in CPF, add those definitions correctly and this error will not be reported for those cells.

If this error is issued for a cell that is defined as a macro model, this error can be ignored.

Example

In the following example, in the LEF description of HMAC cell, two power pins, AVDD and DVDD, are specified with USE POWER and this cell is not defined in CPF as a low power type library cell:

PIN AVDDDIRECTION INOUT ;USE POWER ;

END AVDD

PIN DVDDDIRECTION INOUT ;USE POWER ;

END DVDD


CPF_LIB8: Library cell is defined with multiple power ports by datain LEF, add cell port or spice




1: Library cell ’HMAC’ is defined with multiple power portsby data in LEF



CPF_LIB9

Message

Library cell is defined with multiple ground ports

Default Severity

Error

Description

A LEF file can be used to define power and ground ports of standard cells. This is required for verification of post place-and-route netlists with power and ground net connectivity to leaf cells. When a cell defined in LEF has multiple ports defined with USE GROUND and that cell is not defined as a low power cell, this is reported as an error. If not fixed this will impact the quality of power analysis.

If the cells reported are isolation, level shifters, state retention, power switches, ground switches, always on buffers, or clamp cells that are not defined in CPF, add those definitions correctly and this error will not be reported for those cells.

If this error is issued for a cell that is defined as a macro model, this error can be ignored.

Example

In the following example, in the LEF description of HMAC cell, two ground pins, AVSS and DVSS, are specified with USE GROUND and this cell is not defined in CPF as a low power type library cell:

PIN AVSSDIRECTION INOUT ;USE POWER ;

END AVSS

PIN AVSSDIRECTION INOUT ;USE POWER ;

END AVSS


CPF_LIB9: Library cell is defined with multiple ground ports by data in LEF, add cell port or spiceSeverity: Error Occurrence: 1



1: Library cell ’HMAC’ is defined with multiple ground portsby data in LEF



CPF_LIB10

Message

Dedicated isolation cell location conflict with model structure

Default Severity

Error

Description

An isolation cell model structure is compared to the CPF definition of valid location. When the isolation is defined to be in the ‘on’ location and has the data input inverted or buffered, it is not a valid model for low power analysis. When the isolation is defined to be in the ‘from’ location and does not have two power ports or two ground ports for an ‘AND’ or ‘OR’ isolation function, it is not a valid model for low power analysis.

Check the model structure of the reported cell and look at the CPF definition. It might be necessary to check the SPICE circuit model to determine if the cell model structure is accurately represented.

Example

In the following example, in the CPF definition, the IsoHL cell’s valid location is defined to be in the ‘ON’ domain. In the model, the structure is a NOR primitive with the data inverted. This means that the model has a gate (the inverter) that can be ‘ON’ when its driver is ‘OFF’:

module IsoHL (A, I, Y);input A, I;output Y;nor (Y, I, ~A);

endmodule


CPF_LIB10: Isolation cell’s valid location conflicts with model structure; data drives logic not controlled by isolation enable.

Severity: Error Occurrence: 11: Lib/Lib.cpf:15 Isolation cell ’IsoHL’

Data pin: A



This cell would be valid if the circuit was an AND gate with the isolation enable inverted and modeled in Verilog or Liberty, as follows:

Y = !I && A;



CPF_LIB11

Message

Non-dedicated isolation cell location conflict with model structure

Default Severity

Error

Description

A cell defined as a non-dedicated isolation cell can be used as an isolation cell or for normal logic synthesis. That cell must have one port that only drives into a function controlled by the other port or the cell structure is not valid for low power analysis.

Check the model structure and verify it is modeled accurately. If it is not, then fix the model. If it is modeled accurately, it cannot be used for a non-dedicated isolation cell.

Example

In the following example, cell IsoHH is defined as a non-dedicated isolation cell with a structure that is a NAND primitive of the inversions of both inputs:

module IsoHH (A, B, Y);input A, B;output Y;nand (Y, ~A, ~B);

endmodule


CPF_LIB11: CPF defined non-dedicated isolation cell’s valid locationoption is not compatible with the model structure

Severity: Error Occurrence: 11: Lib/Lib.cpf:19 Isolation cell ’IsoHH’

If the SPICE structure of this cell was an ‘OR’ gate and it was modeled as that in the Liberty or Verilog model, this error would not be reported.

Y = A || B; -or- OR x1 (Y, A, B)



CPF_LIB12

Message

Isolation cell location, function, and power/ground port conflict

Default Severity

Error

Description

A cell that is a two-level function, such as AND or OR, and whose cell location is defined as ‘from’ needs to have two power pins or two ground pins.

Check the verbose error message for the cell name and verify the structure of the function is the same as the SPICE circuit. Verify the definition of the power and ground ports are correct and compare to the CPF definition. If the model structure is accurate and the power/ground port definition is correct, the valid location should be changed to ‘on.’

Example

In the following example, The cell IsoHH is defined as a dedicated isolation cell defined with valid location of ‘from’:

module IsoHH (A, Iso, Y);input A, Iso;output Y;or (Y, A, Iso);

endmodule

The CPF definition defines this cell as having valid location of ‘from’ and specifies only one power and ground port. This is not a valid isolation cell for the ‘from’ location based on the model structure and CPF definition of power/ground ports:

define_isolation_cell -cells IsoHH -valid_location from -power VDD \-ground VSS -enable Iso


CPF_LIB12: CPF defined isolation cell has functional structure that is not compatible with the defined CPF options: dedicated type, valid location "from", and no swichable power or ground port.

Severity: Error Occurrence: 11: Lib/Lib.cpf:19 Isolation cell ’IsoHH’ Data pin: A



This can be fixed by doing one of the following:

■ If there are two power or two ground ports for this cell, fix the CPF to define the ports correctly.

■ Change the -valid_location option to ‘on.’



CPF_LIB13

Message

Switch cell in to out supply path is not defined in functional model

Default Severity

Error

Description

A complete model of a power and ground switch cell can be provided with a Verilog simulation model or a Liberty model with a PG_PIN function. A complete model is essential for functional checking of a post place and route netlist and to verify switch enable polarity is defined correctly by the CPF definition.

This error means there is no functional path between the input and switched power ports in the library model or the READ LIBRARY command’s -extract_liberty_pg_pin option was not defined. Review the Liberty or Verilog model for the reported switch cell to ensure it is complete and correct.

Example

In the following example, if there is the following in the Library CPF file:

define_power_switch_cell -cells LP_PSW -power Vi -power_switchable Vo

and the following in the Liberty file:

cell (LP_PSW) {cell_footprint : head;pg_pin (Vo) {

pg_type : internal_ground;voltage_name : VSS;

}

this results in the following error report:

CPF_LIB13: Switch cell’s source supply port to switchable supply port path does not exist in the functional model

Severity: Error Occurrence: 11: Lib/Lib.cpf:23 Switch cell ’PF_PSW’

Source supply port: ViSwitchable source supply port: Vo



CPF_LIB14

Message

Inconsistent switch cell enable polarity between library views

Default Severity

Error

Description

A switch cell is defined with an enable condition with a polarity different than the switch model function. This enables the input supply to the switched supply path to be ON or the polarity cannot be determined because the CPF enable is not part of the switch function.

Check the model structure and compare to the CPF definition. If the model switch enable polarity is not the same as the SPICE circuit, the model should be fixed; otherwise, the CPF enable condition should be changed.

Example

In the following example, the power switch cell LP_PSW is defined with stage 1 enable being active when input Ei is active low but that conflicts with the power switch model which requires input Ei to be active high to enable the switch to be ON:

define_power_switch_cell -cells LP_PSW \-power_switchable Vo -power Vi \-stage_1_enable !Ei -stage_1_output Eo \-type header

module LP_PSW (Ei, Vi, Eo, Vo);input Ei, Vi;output Eo, Vo;

buf (Eo, Ei);bufif1 (Vo, Vi, Ei);

endmodule


CPF_LIB14: Switch cell’s enable pin polarity is incorrect for the switching function in the liberty model view

Severity: Error Occurrence: 11: Lib/Lib.cpf:23 Switch cell ’LP_PSW’

Source supply port: Vi

Stage 1 enable functional expression: !Ei



CPF_LIB15

Message

Inconsistent switch cell output enable between library views

Default Severity

Error

Description

The CPF for a switch cell defines enable inputs for each switch stage, and then can optionally define inverted or buffered stage outputs to enable “daisy-chaining” switches. Define the CPF function of the stage output with a ‘!’ to define the output is the inversion of the input, or do not use ‘!’ if the output is a non-inverted version of the input.

Note: This error can also mean that the stage output is not a direct inverted or non-inverted version of the stage enable (input). This can occur when there is no path, the cell is blackboxed, or the output is a function involving other signals.

Review the verbose error message for the switch cell name, input function, output function, and compare to the library cell model. Fix the model or CPF definition, whichever is not correct based on the SPICE circuit of the switch.

Example

The power switch cell LP_PSW is defined with stage 1 output ‘Eo’ being the inversion of the stage 1 enable ‘Ei,’ but in the library model ‘Eo’ is the same polarity as ‘Ei’:

define_power_switch_cell -cells LP_PSW \-power_switchable Vo -power Vi \-stage_1_enable Ei -stage_1_output !Eo \-type header

module LP_PSW (Ei, Vi, Eo, Vo);input Ei, Vi;output Eo, Vo;

buf (Eo, Ei);bufif1 (Vo, Vi, Ei);

endmodule


CPF_LIB15: Switch cell’s stage output function conflicts with the CPF stage enable functional expression



Severity: Error Occurrence: 11: Lib/Lib.cpf:23 Switch cell ’LP_PSW’

Stage 1 enable functional expression: EiStage 2 output functional expression: !Eo



CPF_LIB16

Message

Cell without functional model has power/ground ports only

Default Severity

Warning

Description

This applies to black-boxed cells with only power/ground ports.

Use the report rule check CPF_LIB16 -verbose command to retrieve the name of the cell. Use this to identify cells that have power models (such as power or ground pads) or non-functional cells that must be removed the CLP database. Use the following command:

remove <cell name list> -ins_mod –all > /null/dev

directly after reading in all design data. This will reduce any issues in ANALYZE POWER DOMAIN.

Applicability

This rule applies to the Conformal Low Power command analyze library -lowpower, which performs quality checks on cells in LEF or Liberty format.



CPF_LIB17

Message

Inconsistent power port definitions between library views

Default Severity

Warning

Description

Reported when a port is defined as power type in one library view (LEF or CPF) or defined with the add cell port command, but the other views do not define this port or do not define this port as a power type.

Use the report rule check CPF_LIB17 -verbose to find the cell name and review the CPF, LEF, or other definitions and correct any inconsistencies.

Applicability

This rule applies to CLP command analyze library -lowpower which performs quality checks on cells in LEF or Liberty format.



CPF_LIB18

Message

Inconsistent ground port definitions between library views.

Default Severity

Warning (You can use the set rule handling command to change severity)

Description

Reported when a port is defined as ground type in one library view (LEF or CPF) or defined with add cell port command and the other views do not define this port or do not define this port as a ground type.

Use the report rule check CPF_LIB18 -verbose to find the cell name and review the CPF, LEF, or other definitions and correct any inconsistencies.

Applicability

Applies to the CLP command analyze library -lowpower, which performs quality checks on cell definitions between LEF and CPF formats.



CPF_LIB19

Message

Inconsistent location and switchable power in isolation cell definition.

Default Severity

Error

Description

If an isolation cell is defined with the -power_switchable option in CPF, then the valid location must be FROM.

Check the -verbose message to find out which isolation cell has a power switchable port defined and check whether its valid location is TO or ON. If the valid location is TO or ON, remove the -power_switchable option, or change the valid location to FROM.

For an enabled level shifter with CPF version 1.1, the isolation cell definition is not required. Define the level shifter with enable only.

Applicability




CPF_LIB20

Message

Inconsistent location and switchable ground in isolation cell definition

Default Severity

Error

Description

If an isolation cell is defined with -ground_switchable option in CPF, then the valid location must be FROM.

Check the -verbose message to find out which isolation cell has a ground switchable port defined and check whether its valid location is TO or ON. If the valid location is TO or ON, remove the -ground_switchable option, or change the valid location to FROM.

For an enabled-level shifter with CPF version 1.1, the isolation cell definition is not required. Define the level shifter with enable only.

Applicability




CPF_LIB21

Message

Inconsistent switch cell data port names between library views

Default Severity

Error

Description

Reported when a data port of a switch cell defined in the library does not match any port in the corresponding switch cell definition in CPF.

Refer to the -verbose message, which provides the file name and line number for both CPF and library files.

Applicability




CPF_LIB21a

Message

More data ports exist in the functional library for a switch cell with complete control pin definitions.

Default Severity

Note

Description

Reported when a data port of a switch cell defined in the library does not match any port in the corresponding switch cell definition in CPF. The switch cell must have complete control pin specifications in CPF. Specifically, check to see that the cell defines the stage_1_enable, stage_1_output, stage_2_enable, and stage_2_output signals.


Applicability




CPF_LIB22

Message

Inconsistent Level shifter shift direction and input/output voltage range

Default Severity

Error

Description

Reported when the direction of the shift and voltage values defined by -input_voltage_rage and -output_voltage_range pair in the CPF definition of a level shifter cell are inconsistent.


Applicability




CPF Macro

The following lists the rule checks for CPF macro model information:

■ CPF_MACRO1 on page 518

















CPF_MACRO1

Message

Macro model port is defined in multiple feedthru group definitions

Default Severity

Error

Description

A macro model feedthrough group defines all ports that are connected inside macro model. It is not legal to define a port as a member of two or more feedthrough groups.

Review the CPF definition of the feedthrough group for the macro model and port reported in the verbose error report and remove the port from the groups with which it is not associated.

Example

In the following example, a macro block has the following feedthrough group declarations where an input port in[1] is defined in two feedthrough groups:

set_wire_feedthrough_ports {in[1] out}

set_wire_feedthrough_ports {in[1] data_out}


CPF_MACRO1: Macro model port is defined in multiple feedthru groupdefinitions

Severity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Port in[1] of macro model BBOX is

defined in multiple feedthrough group definitions


set_wire_feedthrough_ports {in[1] out data_out}



CPF_MACRO2

Message

Macro model output port is defined in multiple isolation rules

Default Severity

Error

Description

An isolation rule can be defined for an output port of a macro model, but only a maximum of one isolation rule for each port can be defined, unlike macro model input ports which can have multiple internal isolation functions receiving the input port.

Check the verbose report for the output port, the macro model, and the isolation rules, and correct the overlap.

Example

In the following example, a macro block has the following isolation rules where an output port out is defined in isolation rule R1 and R2:

create_isolation_rule -name R1 -pins {out} -isolation_output high \-isolation_condition iso -from PDSW

create_isolation_rule -name R2 -pins {out} -isolation_output low \-isolation_condition iso -from PDSW


CPF_MACRO2: Macro model output port is defined in multiple isolation rulesSeverity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Ouput port out of macro model BBOX is

defined in multiple isolation rules ( R1 R2 )

This can be fixed by having isolation rule R2 is correctly applied to output ‘out1’:


create_isolation_rule -name R2 -pins {out1} -isolation_output low \-isolation_condition iso -from PDSW



CPF_MACRO3

Message

Macro model port is defined as floating and with isolation rule

Default Severity

Error

Description

A macro port should not be defined as both floating and as having an internal isolation driver or receiver. If the port connects to internal circuitry, it should not be defined as a floating port. If a port does not connect to internal circuitry, it should not be defined as part of an isolation rule - it should be defined as a floating port.

Review the verbose error report for the port name, the macro model name, and the isolation rule, and correct the isolation or floating port definition.

Example

In the following example, a macro block has the following isolation rule and floating port settings:

create_isolation_rule -name R1 -pins {*out} -isolation_output high \-isolation_condition iso -from PDSW

set_floating_ports {data_out}


CPF_MACRO3: Macro model port is defined as floating and with isolation ruleSeverity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Port in[1] of macro model BBOX is defined in

multiple feedthrough group definitions

This can be fixed by excluding the floating port from the isolation rule with the following command:

create_isolation_rule -name R1 -pins {*out} -isolation_output high \-isolation_condition iso -from PDSW \-exclude {data_out}



CPF_MACRO4

Message

A macro port defined as both floating and feedthru

Default Severity

Warning

Description

A macro port should not be defined as floating and as part of feedthrough group. The floating definition will be ignored.

Example

In the following example, port ‘data_out’ is defined as floating and as a part of feedthrough group:


set_floating_ports {data_out}


CPF_MACRO4: A macro port defined as both floating and feedthruSeverity: Warning Occurrence: 11: Data/bbox_macro.cpf:23 Port data_out of macro model BBOX is

defined as both floating and feedthru, the floating definitionwill be ignored

This can be fixed by removing the floating port definition with the following command:


#set_floating_ports {data_out}



CPF_MACRO5

Message

Macro model port is defined as floating and with voltage tolerance

Default Severity

Error

Description

A macro model port can be defined as having a voltage tolerance or as a floating port (which does not have receivers) but it is not valid to define as both.

Check the verbose error report for the port name and the macro model name and remove that port from either the floating port or the voltage tolerance definition.

Example

In the following example, input port ‘in[1]’ is defined as floating and has voltage tolerance:

set_floating_ports {in[1]}

set_input_voltage_tolerance -ports {in[1]} -bias 0.2


CPF_MACRO5: Macro model port is defined as floating and with voltage toleranceSeverity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Port in[1] of macro model BBOX is defined as

floating and with voltage tolerance

This can be fixed by removing the voltage tolerance definition with the following command:


#set_input_voltage_tolerance -ports {in[1]} -bias 0.2



CPF_MACRO6

Message

A macro port is defined as floating and as a domain port

Default Severity

Error

Description

A macro model port can be defined as floating if there are no internal receivers or drivers, or it can be defined as a boundary port of an internal domain to signify it has internal receivers or drivers, but it cannot be defined as both a floating port and a boundary port to a power domain.

Review the verbose error report for port name and macro model name and remove the port from the floating port or the boundary port definition.

Example

In the following example, port ‘data’ is defined as floating and as a boundary port of the PDSW domain:

create_power_domain -name PDSW -boundary_ports {data in[*]}

set_floating_ports {data}


CPF_MACRO6: A macro port defined as both floating and related to internal circuitry with -boundary_ports option

Severity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Port data of macro model BBOX is defined

as both floating and re lated to internal circuitry with-boundary_ports option

This can be fixed by removing the floating port definition with the following command:


#set_floating_ports {data}



CPF_MACRO7

Message

A macro power or ground is defined as a boundary port

Default Severity

Error

Description

Macro model power and ground ports are associated to a power domain with the update_power_domain command’s -primary_power_net and -primary_ground_net options. Only data ports are valid to be defined in the list for the create_power_domain command’s -boundary_ports option.

Example

In the following example, power port ‘VDD’ and ‘VSW’ are defined as a boundary port of the related power domain:

create_power_domain -name PD1 -boundary_ports {out* iso data_out VDD}

create_power_domain -name PDSW -boundary_ports {data in[*] VSW}


CPF_MACRO7: A macro power or ground port is defined as a boundary portcircuitry with -boundary_ports option

Severity: Error Occurrence: 21: Data/bbox_macro.cpf:2 A power port VDD of macro model BBOX

is defined as a boundary port2: Data/bbox_macro.cpf:2 A power port VSW of macro model BBOX

is defined as a boundary port

This can be fixed by removing the VDD and VSW ports from the list in the -boundary_ports option. Make sure to update all domains that are not internally switched with the appropriate power and ground net as with the following commands:

create_power_domain -name PD1 -boundary_ports {out* iso data_out}

create_power_domain -name PDSW -boundary_ports {data in[*]}

update_power_domain -name PD1 -primary_power_net VDD -primary_ground_net VSS

update_power_domain -name PDSW -primary_power_net VSW -primary_ground_net VSS



Note: for internally switched power domains, it is only necessary to define the secondary domain with create_power_domain and not define power/ground nets with the update_power_domain command.



CPF_MACRO8

Message

A macro power or ground is not defined as power or ground net, feedthru, or floating

Default Severity

Error

Description

All power and ground macro ports must be defined in the macro model as an primary power or ground port to a power domain when it used to supply circuitry, as a feedthrough if it connects to an internal net with multiple boundary ports, or as a floating port if it does not connect to other ports or circuitry inside the macro. A feedthrough can also drive internal circuitry.

Example

In the following example, power port ‘VDD1’ is not defined as a primary power net, a feedthrough port, or a floating port. This results in the following error report:

CPF_MACRO8: A macro power or ground port is not defined as an primary poweror ground net, a feedthru port or a floating port

Severity: Error Occurrence: 11: Data/bbox_macro.cpf:2 A power port VDD1 of macro model BBOX

is not defined as a primary power net, a feedthru port or a floating port

This can be fixed by declaring VDD1 as a feedthrough port if VDD1 is internally connected to the VDD port with the following command:

set_wire_feedthrough_ports {VDD VDD1}



CPF_MACRO9

Message

A macro data port is not defined as domain port, feedthru, floating

Default Severity

Error

Description

All macro data ports must be defined in the macro model as a boundary port when it connects to internal circuitry, as a feedthrough if it connects to an internal net with multiple ports, or as a floating port if it does not connect to other ports or circuitry inside the macro. A feedthrough can also connect to internal circuitry.

Example

In the following example, output data port ‘data_out’ is driven by the PD1 power domain logic but is not defined as a boundary port of this power domain:

create_power_domain -name PD1 -boundary_ports {out* iso} -default


CPF_MACRO9: A macro data port is not defined as a boundary port, a feedthruport or a floating port

Severity: Error Occurrence: 11: Data/bbox_macro.cpf:2 A data port data_out of macro model

BBOX is not defined as a boundary port, a feedthru port or a floating port

This can be fixed by adding ‘data_out’ in the boundary port list of the associated power domain with the following command:

create_power_domain -name PD1 -boundary_ports {out* iso data_out} -default



CPF_MACRO10

Message

Switch rule defined in macro model will be ignored

Default Severity

Warning

Description

A macro model internally switched domain does not require a switch rule. An internal switched domain in a macro model requires definition of a based (secondary) domain with the create_power_domain command. This is sufficient for verification and analysis.

Example

In the following example, the macro model has an internal switched domain PDSW, and there is one switch rule SW_R1 related to PDSW domain:

create_power_domain -name PDSW -boundary_ports {data in[*]} \-shutoff_condition {!pe}-secondary_domains {PD1}

create_power_switch_rule -name SW_R1 -domain PDSW -external_power_net VDD


CPF_MACRO10: Switch rule defined in macro model definition, it will be ignored

Severity: Warning Occurrence: 11: Data/bbox_macro.cpf:12 Switch rule SW_R1 defined in macro

model BBOX definition, it will be ignored

This can be fixed by removing the SW_R1 switch rule, defined in this macro model.



CPF_MACRO11

Message

Macro model isolation rule must specify related domain and pins

Default Severity

Error

Description

A macro model isolation rule must specify -to domain and -pins for isolation rules at input data boundary or -from domain and -pins for isolation rules at output data boundary.

Review the verbose error message for the isolation rule name, macro model name, and target pin name and add the ‘-to <receiving domain>’ option if the target pin is input or add the ‘-from <driving domain>’ option if the target pin is an output.

Example

In the following example, a macro model has an isolation rule, R1, for output data port ‘out:’

create_isolation_rule -name R1 -pins {out} -isolation_output high \-isolation_condition isoD


CPF_MACRO11: Macro model isolation rule does not specify target pins and internal macro model domain.

Severity: Warning Occurrence: 11: Data/bbox_macro.cpf:2 Isolation rule R1 of macro model BBOX

does not specify from domain for a target pin out

This can be fixed by adding macro internal power domain (PDSW) which drives the output port ‘out’ in the isolation rule R1:




CPF_MACRO12

Message

Illegal macro model internal domain definition of internal power or ground net, this option will be ignored

Default Severity

Warning

Description

A macro model power domain that is internally switched does not require power and ground nets to be specified. Source power and ground nets are inferred by the CPF 1.0e version -secondary_domains option or equivalent CPF 1.1 version -base_domains option.

Check the verbose warning report for the power or ground net, the macro model name and the power domain name and remove the update_power_domain command in the CPF definition of that macro model for the specified power domain.

Example

In the following example, the macro model has an internal switched domain PDSW and there are power and ground nets updated to PDSW domain:

create_power_domain -name PDSW -boundary_ports {data in[*]} \-shutoff_condition {!pe}-secondary_domains {PD1}


CPF_MACRO12: Illegal macro model internal domain definition of internal power or ground net, this option will be ignored

Severity: Warning Occurrence: 21: Data/bbox_macro.cpf:5 power(ground) net VSW in macro model

BBOX internal domain PDSW is illegal, ignored2: Data/bbox_macro.cpf:5 power(ground) net VSS in macro model

BBOX internal domain PDSW is illegal, ignored



CPF_MACRO15

MessageAn isolation rule without condition is not valid for output ports

Default Severity

Error

Description

When the macro model power intent file has an isolation rule that relates to a macro block output pin, you must define an isolation condition.

For rules that relate to macro block input pins, isolation conditions are not required because they do not specify the existence of isolation, just a constraint for the type of isolation necessary due to the design inputs. Block outputs do not require a constraint.

Use report rule check CPF_MACRO15 -verbose for more information on the macro model name and isolation rule name. If the isolation exists at the macro output port, add the isolation condition; otherwise, remove the rule.

Applicability




CPF_MACRO16

Message

Feedthrough group port types conflict

Default Severity

Error

Description

A feedthrough group must be either all power ports, ground ports, or data ports. A feedthrough group should not contain ports which are different types. The cause of this error could be an incorrect user specification of group or incorrect definition of port type, such as power port not being defined as a power port in LEF file.

Review the verbose error report for the macro model name and the ports which are defined with mixed types. Correct port types, port names, or remove all ports which do not belong in the defined feedthrough group.

Example

In the following example, the macro model has a feedthrough group which contains a power port ‘VDD’ and a data type port ‘data_out:’

set_wire_feedthrough_ports {VDD data_out}


CPF_MACRO16: Ports defined in feedthrough group are of mixed typesSeverity: Error Occurrence: 11: Data/bbox_macro.cpf:2 Ports of macro model BBOX defined

in feedthrough group are of mixed typesPower pins: VDDData pins: data_out



CPF_MACRO17

Message

Feedthrough group port directions conflicts

Default Severity

Error

Description

The feedthrough group pins’ direction must be consistent. The valid combinations are two or more inout types, or one input type and one or more output types. All other combinations create a conflict.

Example

For the following command:

set_wire_feedthrough_ports {data data1 data_out data_out1}

if the direction of pin data and pin data1 is input, and the direction of pin data_out and pin data_out1 is output, this will result in the following report.

CPF_MACRO17: Feedthrough group port direction conflictsSeverity: Error Occurrence: 11: Port direction conflicts found for pin defined in feedthrough group

Data/bbox_macro.cpf:1 Macro model BBOX1Input: data data1Output: data_out data_out1Inout



CPF Power and Ground Nets

The following lists the Power and Ground Net (CPF_PGN) rule checks:

■ CPF_PGN1 on page 535









CPF_PGN1

Message

Power net is defined but not used

Default Severity

Warning

Description

A power net created by the create_power_nets command is not referenced in the CPF. All power nets should be specified as a power net for one or more power domains using the update_power_domain command.

Review the verbose error report for the power net name and determine if that name is correct. Make sure all power nets are being used by one or more power domains.

Example

In the following example, the intent is that both VDD and VDD1 are to be in the same power domain. The CPF does not define VDD1 as a power domain net.

create_power_nets -nets VDD -voltage 1.0create_power_nets -nets VDD1 -voltage 1.0update_power_domain -name DON -primary_power_net VDD -primary_ground_net VSS


CPF_PGN1: Power net is defined but not usedSeverity: Warning Occurrence: 11: Data/top.cpf:13 Power net VDD1 is defined but not used

You can fix this with the following command:

update_power_domain -name DON -equivalent_power_nets { VDD VDD1 } \-primary_ground_net VSS



CPF_PGN2

Message

Ground net is defined but not used

Default Severity

Warning

Description

A ground net created by the create_ground_nets command is not referenced in the CPF. All ground nets should be specified as a ground net for one or more power domains using the update_power_domain command.

Review the verbose error report for the power net name and determine if that name is correct. Make sure all ground nets are being used by one or more power domains.

Example

In the following example, the intent is that both VSS and VSS1 are to be in the same power domain. The CPF does not define VSS1 as a power domain ground net.

create_power_nets -nets VSS -voltage 0.0create_power_nets -nets VSS1 -voltage 0.0update_power_domain -name DON -primary_power_net VDD -primary_ground_net VSS


CPF_PGN2: ground net is defined but not usedSeverity: Warning Occurrence: 11: Data/top.cpf:13 ground net VSS1 is defined but not used

You can fix this with the following command:

update_power_domain -name DON -equivalent_ground_nets { VSS VSS1 } \-primary_power_net VDD



CPF_PGN3

Message

Power net with external shutoff is object of a power switch rule

Default Severity

Error

Description

A power net that is shut-off externally to design scope is defined with the create_power_nets command’s -external_shutoff_condition option. It is not legal to define a power net as externally shutoff and as a primary_power_net of a power domain with an internal power switch rule.

Review the verbose error report for the power net name. Review the CPF to find which domain this power net is associated with by the update_power_domain command’s -primary_power_net or -equivalent_power_nets options. Review the CPF to fine the power switch rule defined for that power domain and determine whether the switch rule or create_power_nets command’s -external_shutoff_condition option, and the create_power_domain command’s -external_controlled_shutoff option should be removed.

Example

In the following example, a power net VSW is defined with an external shutoff condition and a power domain is defined as external_controlled_shutoff. It updates the VSW power net to that power domain as a primary power net and defines a switch rule for that power domain.

create_power_domain -name DSW -shutoff_condition {!pe} \-external_controlled_shutoff

create_power_nets -nets VSW -voltage 1.0 \-external_shutoff_condition {!pe}

update_power_domain -name DSW -primary_power_net VSWcreate_power_switch_rule -name SR1 -domain DSW


CPF_PGN3: External shutoff power net used as an internal powerswitchable netSeverity: Error Occurrence: 1



1: Data/top.cpf:13 External switchable power net VSW used as an internally switchable net

You can fix this by removing switch rule with the following commands:

create_power_domain -name DSW -shutoff_condition {!pe} \-external_controlled_shutoff

create_power_nets -nets VSW -voltage 1.0 \-external_shutoff_condition {!pe}

update_power_domain -name DSW -primary_power_net VSW

You can also fix this by removing the external shutoff from the power domain and power net with the following commands:

create_power_domain -name DSW -shutoff_condition {!pe}create_power_nets -nets VSW -voltage 1.0update_power_domain -name DSW -primary_power_net VSWcreate_power_switch_rule -name SR1 -domain DSW



CPF_PGN4

Message

Power net is not connected to any leaf cell

Default Severity

Warning

Description

This rule is flagged if there is no leaf cell connected to a power net created by the create_power_nets command.

Check the verbose message to find out which power net does not have leaf cells. This can occur in defining a redundant power net, or incorrectly connect the power net in the netlist that causes this power net to become floating

Example

In the following example, an internal switched power net is defined but no leaf cells is connected to this power net:

create_power_nets -nets VSW -voltage 1.0 -internal


CPF_PGN4: Power net is not connected to any leaf cellSeverity: Warning Occurrence: 11: Data/top.cpf:13 Power net VSW is not connected to any leaf cell

You can fix this by reconnecting the instance power pin to the expected power net, as with the following:

From: block1 u_1 (.in(in), .out(nn), .VDD(VDD), .VSS(VSS));To: block1 u_1 (.in(in), .out(nn), .VDD(VSW), .VSS(VSS));



CPF_PGN5

Message

Ground net is not connected to any leaf cell

Default Severity

Warning

Description

This rule is flagged if there is no leaf cell connected to a ground net created by the create_power_nets command.

Check the verbose message to find out which ground net does not have leaf cells. This can occur in defining a redundant ground net, or incorrectly connect the ground net in the netlist that causes this ground net to become floating.

Example

In the following example, an internal switched ground net is defined but no leaf cells is connected to this ground net:

create_power_nets -nets GSW -internal


CPF_PGN5: Ground net is not connected to any leaf cellSeverity: Warning Occurrence: 11: Data/top.cpf:13 Ground net GSW is not connected to any leaf cell

You can fix this by reconnecting the instance power pin to the expected ground net, as with the following:

From: block1 u_1 (.in(in), .out(nn), .VDD(VDD), .VSS(VSS));To: block1 u_1 (.in(in), .out(nn), .VDD(VSW), .VSS(VSS));



CPF_PGN11

MessageDomain supply net is defined as external supply in switch rule for that domain

Default Severity

Error

Description

A switch rule must define the external power or ground net that is the source of the net. This message indicates that the net defined as the input to the switch is also defined as the domain supply it is switching, which means it is also the output pin of the switch.

Use report rule check CPF_PGN11 -verbose for more information on the domain name, the supply net of the switchable domain, or the supply net defined as external power or ground in the switch rule.

Applicability




CPF_PGN13

MessagePower/ground net not defined as internal does not connect to a primary port

Default Severity

Warning

Description

If a power/ground net is not connected to the primary port, you must declare it as internal ( -internal option).

Use report rule check CPF_PGN13 -verbose for more information on the domain name, the supply net of the switchable domain, or the supply net defined as external power or ground in the switch rule.

Applicability




CPF Power Domains

The following lists the Power Domain (CPF_PD) rule checks:

■ CPF_PD1 on page 544










■ CPF_PD12a on page 555






CPF_PD1

Message

Power domain does not have a primary power net specified

Default Severity

Warning

Description

All design scope non-virtual power domains must be updated with internal (primary) power net when any power net is defined in CPF. A virtual power domain is a power domain that is not specified as the default power domain, and for which no instances or boundary ports are defined.

Check the verbose message to find out which power domain does not have an updated power net. To fix this problem, specify the internal (primary) power net associated to this power domain in update_power_domain command.

Example

In this example, there is a power net specified in the CPF, but no power net is updated to power domain TDH:

create_power_nets -nets VDD -voltage 1.2create_ground_nets -nets GH -voltage 0.2update_power_domain -name TDH -internal_ground_net GH


CPF_PD1: Power domain without internal (primary) power net information Severity: Warning Occurrence: 11: Data/top.cpf:6 Power domain TDH's internal power net not specified.

An example fix:

update_power_domain -name TDH -internal_power_net VDD -internal_ground_net GH



CPF_PD2

Message


Default Severity

Error

Description

If more than one internal power net is specified for a power domain, the last one will be considered and the previous ones will be ignored.



CPF_PD3

Message


Default Severity

Warning

Description

With CPF 1.0 and CPF 1.0e versions, when an internal switched domain is defined, a corresponding switch rule for this internal switched domain is required for a CPF file containing physical information.

Check the verbose message to find out which power domain does not have a power switch rule. This problem can be either the domain definition is incorrect and it is an externally switched domain, it should not have a shutoff condition, or the switch rule is not specified.

Example

In this example, the following CPF description defines DSW as an internal switch domain (shutoff_condition is specified), but there is no switch rule.

create_power_domain -name DSW -instances {u_1} -shutoff_condition {!pe} \-secondary_domains DON


CPF_PD3: Internally switched power domain has no power switch rule.Severity: Error Occurrence: 11: Data/top.cpf:8 Internally switched power domain DSW has no powerswitch rule.

An example fix is to define a switch rule for this power domain:

create_power_switch_rule -name SR1 -domain DSW -external_power_net VDD



CPF_PD4

Message

Domain not defined as internal switched is object of a switch rule

Default Severity

Error

Description

It is not valid to have a power domain defined with a power switch rule and without a shutoff condition.

Check the verbose message to find out which unswitched power domain has a switch rule and the switch rule name. Check the switch rule option for the power domain to make sure it was not a mistake. Also check to make sure if the power domain is supposed to be switchable, a shutoff condition is defined using the proper control signal in the create power domain command.

Example

The following CPF description defines DON as an unswitched domain, and there is a switch rule defined for this domain. CPF also defines DSW as a switched domain but it does not have a switch rule:

create_power_domain -name DON -default create_power_domain -name DSW -shutof_condition {!pe} ...create_power_switch_rule -name SR1 -domain DON -external_power_net VDD


CPF_PD4: Unswitched power domain has power switch rule.Severity: Error Occurrence: 11: Data/top.cpf:7 Unswitched power domain DON has power switch rule SR1.

You can fix this by correcting the domain name with the corresponding internal switched domain name with the following command:

create_power_switch_rule -name SR1 -domain DSW -external_power_net VDD



CPF_PD7

Message

Instance specified in multiple power domains

Default Severity

Error

Description

The power domain definition includes the option to specify design instances as objects. It is an error to list the same instance as an object of multiple power domains.

Review the verbose error message for the instance name and the power domains this instance is assigned to. The instance name must be removed from the power domains that it should not be a part of. If this instance is a macro model, use the set_instance CPF command to map macro domains to the top-level domains, and remove the specific reference to macro instances in the list of domain instances.

Example

In the following example, the instance u_1 has multiple power domains: D2 and DSW. However, only instance x1 in the instance u_1 is to be in power domain DSW, and all other instances should be in domain D2.

The following CPF description specifies u_1 in D2 and DSW domains:

create_power_domain -name D2 -instances {u_1} -boundary_ports {in[*]} create_power_domain -name DSW -instances {u_1}


CPF_PD7: Instance specified in multiple power domains.Severity: Error Occurrence: 11: Instance u_1 specified in multiple power domains (DSW, D2, ...)

You can fix this by specifying the sub instance x1 which belong to DSW with the following command:

create_power_domain -name DSW -instances {u_1/x1}



CPF_PD8

Message

Multiple signals defined in a domain’s default isolation condition

Default Severity

Error

Description

Conformal Low Power supports defining a logical expression of a single top-module port or a design block instance pin for an isolation condition:

create_isolation_rule -name <> -isolation_condition <pin_name> | !<pin_name>

Review the verbose error message for the isolation rule or domain if the isolation is from a default isolation rule and determine what the intent is:

■ If the intent is to have multiple isolation control signals, each controlling a unique set of isolation cells, then specify the isolation control with exactly 1 pin and use the set_equivalent_control_pins CPF command to define the master and other pins. Refer to the CPF version 1.1 and later documentation.

■ If the intent is to synthesize the function in the expression and drive all isolation cells with a single control net, then modify the design to add a block containing that function and use the output pin of that block as the isolation control.

Example

In the following example, iso and iso1 are defined as a default isolation condition of the power domain DSW:

create_power_domain -name DSW -instances {u_1} \-shutoff_condition {!pe} -secondary_domains DON \-default_isolation_condition {iso || iso1}


CPF_PD8: Multiple signals are defined in a domain’s default isolation condition.




1: Data/top.cpf:8 Multiple signals defined in DSW’s defaultisolation condition

You can fix this by keeping signal iso in the -default_isolation_condition setting and use set_equivalent_control_pins approach to specify the functional equivalent signal iso1, as with the following commands:

create_power_domain -name DSW -instances {u_1} \-shutoff_condition {!pe} -secondary_domains DON \-default_isolation_condition {iso}

set_equivalent_control_pins -domain DSW -master iso -pins iso1



CPF_PD9

Message

Power domain MOS bias net is not a defined bias or power/ground net

Default Severity

Error

Description

A net specified in update_power_domain CPF command options -nmos_bias_net or -pmos_bias_net option must be declared as a bias net using the create_bias_net CPF command.

This can occur when the net specified in -noms_bias_net or -pmos_bias_net is not defined with the create_bias_net CPF command or the name is incorrect. To fix this, check the verbose error report for the bias net updated to the power domain. Declare this bias net with create_bias_net or correct the bias net name.

Example

In the following example, A poms bias net, BIAS, is specified in the update_power_domain command:

update_power_domain -name DVSW -internal_power_net VSW \-internal_ground_net VSS \-pmos_bias_net BIAS

But this BIAS net is not declared as a bias net with create_bias_net command, so this results in the following error report:

CPF_PD9: MOS bias in a power domain is not defined with create_bias_net Severity: Error Occurrence: 11: ../Data/top.cpf:19: PMOS bias net BIAS updated to power domain DVSW

is not declared as a bias net

You can fix this by declaring BIAS as a bias net if BIAS net is intended to be used as a bias control signal, as with the following command:

create_bias_net -net BIAS



CPF_PD10

Message

Power intent is missing power mode definitions

Default Severity

Error

Description

The CPF must include at least one create_power_mode command. Review the CPF and add all valid power modes to define the valid configurations of the design based on unique power/ground voltage nominal conditions of domains.

Example

When no create_power_mode command is set in the CPF file, this results in the following error report:

CPF_PD10: Power modes are not defined.Severity: Error Occurrence: 11: Power modes are not defined.

You can fix this by adding the create_power_mode setting in the CPF file, as with the following command:

create_power_mode -name M1 -domain_conditions {DH@H DL@L} -default



CPF_PD11

MessagePower domain voltage is not specified in power modes

Default Severity

Warning

Description.

Power modes define nominal conditions of domains in all functional conditions. Any domain defined in power intent must be specified in one or more power modes; without this, power intent quality checks and analysis cannot be completed.

Use report rule check CPF_PD11 -verbose for more information on the domain name and add this domain and nominal condition to the relevant power modes.

Applicability




CPF_PD12

Message

Inconsistent nominal condition between primary domain and base domain

Default Severity

Error

Description

When a primary domain is turned ON, its nominal condition must match the nominal condition of one of the base (secondary) domains.

Use the verbose message to determine which power domain is inconsistent with the list of base domains. There might be an incorrect base name setting or the power mode has an incorrect domain condition definition.

Example

In the following example, the create_power_domain defines DON as the base domain of the switched domain DSW:

create_power_domain -name DSW -shutoff_condition {!pe} -base_domains DON

with the following nominal conditions and power mode declarations:

create_nominal_condition -name on -voltage 1.0create_nominal_condition -name off -voltage 0create_power_mode -name M1 -domain_conditions {DON@on DSW@on} -defaultcreate_power_mode -name M2 -domain_conditions {DON@on DSW@off}create_power_mode -name M3 -domain_conditions {DON@off DSW@on}

Resulting in the following verbose report:

CPF_PD12: Inconsistent nominal condition between the primary power domain with itsbase domain(s)Severity: Error Occurrence: 11: Data/top.cpf:26Mode: M3Secondary domain: DONPrimary domain: DSW

To fix this, you can refine power mode M3 as:

create_power_mode -name M3 -domain_conditions {DON@off DSW@off}



CPF_PD12a

MessagePower mode voltage of switched domain is less than its base domain

Default Severity

Warning

Description

The nominal condition of an internally switched power domain must be at the same power and ground voltage as the base domain specified in the power mode that defines the domain as not switched off.

This warning applies only to domains that are switchable through power or ground switches. You can ignore this warning if the domain is supplied by an internal regulator.

Use report rule check CPF_PD12a -verbose for more information on the domain name and the base domain. If it is not a regulated domain, review and correct the power modes.

Applicability




CPF_PD13

MessageSwitch rule is missing for switched domain

Default Severity

Warning (logical mode)

Error (physical mode)

Description

This applies to CPF version 1.1. CPF 1.1 supports virtual domains, which do not require switch rules.

An internally switched domain must have a power or ground switch rule defined; this is recommended for netlists that do not have power and ground connectivity and is required before and after place and route.

This warning applies only to domains that are switchable through power or ground switches. You can ignore this warning if the domain is supplied by an internal regulator.

Use report rule check CPF_PD13 -verbose for more information on the domain name, to review the power intent specification, and to add switch rules as required.

Applicability




CPF_PD14

MessageSignals defined for default isolation condition come from different power domains.

Default Severity

Error

Description

Indicates that the design pins specified the -default_isolation_condition option of the create_power_domain command are assigned to or driven by multiple domains. This creates a conflict with the power specification, since all control to a single domain control should be driven by one domain.

Use report rule check CPF_PD14 -verbose for more information on the domain name, review the power intent specification. From there, determine how to modify the isolation condition or the domain assignments of the control domains so they are consistent.

Applicability




CPF_PD15

MessageSignals defined for default retention control come from different power domains.

Default Severity

Error

Description

Indicates that the default_save_edge or default_restore_edge conditions are specified for a power domain, but the pins specified in the condition are assigned to or driven by multiple domains. This creates a conflict with power specification since all control to a single domain control should be driven by one domain.

Use report rule check CPF_PD15 -verbose for more information on the domain name and to review the power intent specification. From there, determine how to modify the conditions or the domain assignments of the control domains so they are consistent.

Applicability




CPF Power Shut Off

The following lists the Power Shut Off rule checks:

■ CPF_PSO1 on page 560

■ CPF_PSO1a on page 561

■ CPF_PSO1b on page 562







CPF_PSO1

Message

Conflict between domain shutoff and switch rule enable

Default Severity

Error

Description

The switch rule enable condition must be the opposite polarity of the shutoff condition for the corresponding power domain.

The verbose message lists the power domain whose polarity setting for the shutoff condition is inconsistent with that of the associated switch rule. There is either an incorrect shutoff condition in the power domain or an incorrect enable condition in the switch rule.

Example

In this example, the following CPF description defines DSW as an internal switched domain with shutoff condition pe and a switch rule SR1:

create_power_domain -name DSW \-instances {u_1} -shutoff_condition {pe} \-base_domains DON

create_power_switch_rule -name SR1 -domain DSW -external_power_net VDD update_power_switch_rule -name SR1 -enable_condition_1 {pe}

This resulting verbose report:

CPF_PSO1: Shutoff condition defined in the internal switched domain has logic operator conflict with enable condition defined in the associated switch rule Severity: Error Occurrence: 11: Data/top.cpf:8 Shutoff condition 'pe' of domain DSW has conflict with the enable condition 'pe' of switch rule SR1.

To fix this, you can refine the enable condition set in the switch rule:

update_power_switch_rule -name SR1 -enable_condition_1 {!pe}



CPF_PSO1a

Message

Conflict between domain shutoff and external supply shutoff

Default Severity

Error

Description

The shutoff condition defined for an external switched power/ground net must have the same polarity as the shutoff condition defined in the associated power domain.

Check the verbose message to determine which power domain has an inconsistent shutoff polarity setting. There is either an incorrect shutoff condition setting in the power domain declaration or an incorrect shutoff condition set in the power/ground net updated to this power domain.

Example

In this example, the CPF description defines DSW as an external switched domain with a power net VSW updated to DSW power domain:

create_power_domain -name DSW -instances {u_1} -shutoff_condition {!(pe)} \ -external_controlled_shutoff -base_domains DON create_power_nets -nets VSW -external_shutoff_condition {pe}create_ground_nets -nets VSSupdate_power_domain -name DSW -primary_power_net VSW -primary_ground_net VSS


CPF_PSO1a: Shutoff condition defined in the external switched domain has logic operator conflict with shutoff condition defined in the associated power/ground net. Severity: Error Occurrence: 11: Data/top.cpf:8 Shutoff condition '!(/pe)' of domain DSW is not consistent with the external shutoff condition 'pe' of power net VSW.

An example fix - refine the shutoff condition setting in VSW net:

create_power_nets -nets VSW -external_shutoff_condition {!pe}



CPF_PSO1b

MessageDomain shutoff condition can be disabled without turning on all switch rule enables

Default Severity

Warning

Description

An internally switched domain is ON when all enables defined in the update_switch_rule command is ON. To ensure that the domain has full current for active mode, a power domain is not fully ON and ready active use until all switches are enabled.

Use report rule check CPF_PSO1b -verbose for more information on the domain, switch rule, and the control signals involved.

Applicability

All design netlists that have complete power intent specification including power and ground definition and switch rules.



CPF_PSO2

Message

Conflict between internally switched domain and domain supply nets

Default Severity

Error

Description

Header-type, internally switched domains, must be associated with a power net (association for which is done through the -internal option of the create_power_net command). Footer-type, internally switched domains, must be associated with a ground net.

Review the verbose message to determine which internally switched domain is associated with an non-internally switched power or ground net. You might have an incorrect power domain or power/ground net setting.

Example

In the following example, the CPF description defines DSW as an internally switched domain with an associated power net VSW:

create_power_domain -name DSW \-instances {u_1} -shutoff_condition {pe} \-base_domains DON

create_power_nets -nets VSW create_ground_nets -nets VSSupdate_power_domain -name DSW -primary_power_net VSW -primary_ground_net VSS


CPF_PSO2: Internally switched power domain is not associated with an internal power/ground netSeverity: Error Occurrence: 11: Data/top.cpf:10 Internally switched power domain DSW is associated with an unswitched power net VSW.

To fix this, declare VSW as an internal power net:

create_power_nets -nets VSW -internal



CPF_PSO3

Message

Conflict between domain shutoff and switch rule / supply shutoff

Default Severity

Error

Description

This message indicates that the shutoff condition in the domain definition is not covered by the switch rule enable settings and/or by the external shutoff condition.

Check the verbose message to find out which domain has a shutoff condition signal that is not covered by its related switch rule enable setting(s) or by the shutoff setting in its primary power/ground net.

For an internally switched domain, there might be an incorrect shutoff condition setting in the power domain or an incorrect enable condition setting in the switch rule. For an externally switched domain, there might be an inconsistent shutoff condition setting between the power domain and the power/ground net updated to the domain.

Example

In the following example, the CPF description defines DSW as an internally switched domain with a shutoff condition "!(pe1&&pe2)" and a switch rule SR1:

create_power_domain -name DSW -instances {u_1} \-shutoff_condition {!(pe1&&pe2)} \-base_domains DON create_power_switch_rule -name SR1 -domain DSW -external_power_net VDD update_power_switch_rule -name SR1 -enable_condition_1 {pe1}


CPF_PSO3: Domain shutoff condition is not covered by the composite of switchrules and/or external power/ground source net shutoff conditionSeverity: Error Occurrence: 11: Data/top.cpf:8 Shutoff condition '!(/pe1&&/pe2)' of domain DSW is not covered by the enable condition 'pe1' of switch rule SR1.

To fix this, you can refine the enable condition setting in the switch rule:



update_power_switch_rule -name SR1 -enable_condition_1 {pe1} \-enable_condition_2 {pe2}



CPF_PSO4

Message

Conflict between domain shutoff and switch rule / supply shutoff

Default Severity

Error

Description

This rule checks that the shutoff condition defined in the CREATE POWER DOMAIN command is consistent with the shutoff condition defined by composite of all the switch rules and power/ground supply nets that apply to the domain.

The verbose message identifies the domain and compares the shutoff condition with the switch rule enable settings and the external shutoff condition of any primary power or ground net.

Example

In the following example, the CPF description defines DSW as an internal switched domain and a switch rule SR1:

create_power_domain -name DSW -instances {u_1} \-shutoff_condition {!(pe1)} \-base_domains DON

create_power_switch_rule -name SR1 -domain DSW -external_power_net VDD update_power_switch_rule -name SR1 -enable_condition_1 {pe1} \-enable_condition_2 {pe2}


CPF_PSO4: Switch enable condition and/or external power/ground source net shutoff condition has signals undefined in the domain shutoff conditionSeverity: Error Occurrence: 11: Data/top.cpf:8 Switch enable condition 'pe1,pe2' of switch rule SR1 has signal(s) undefined in the domain shutoff condition '!(/pe1)' of domain DSW.

To fix this, you can refine the shutoff condition for domain DSW:

create_power_domain -name DSW -instances {u_1} \-shutoff_condition {!(pe1&&pe2)} \-base_domains DON



CPF_PSO5

MessageSignals defined for shutoff control come from different power domains.

Default Severity

Error

Description

A shutoff condition expression of a power domain contains control pins that are driven by different power domains. All control signals used to enable power to a domain should have one domain in common with all power control signals for that domain.

Use report rule check CPF_PSO5 -verbose for more information on the control signals and their driving domains.

Applicability




CPF_PSO6

MessageShutoff condition expression arguments are defined as equivalent.

Default Severity

Warning

Description

When a power domain is shutoff with separate and functionally-nonequivalent control signals, like restore then enable for switches with two enables, the correct method to express this is with an expression of all enables where the domain is OFF if any signal is not active.

When a power domain is shutoff with separate and functionally-equivalent control signals, like a domain with multiple switch groups each controlled by a separate enable, then that can be specified with a set equivalent control pin command. In this case, use the control pin defined as the master as the shutoff condition and take enable polarity into account and do not use the other control signals defined by the -pins option of the set equivalent control pins command.

Use report rule check CPF_PSO6 -verbose to get details about the domain and control pins and determine which method is required and correct the power intent specification to be consistent.

Applicability




CPF Power Switches

The following lists the Power Switch (CPF_PSW) rule checks:

■ CPF_PSW3 on page 570







CPF_PSW3

Message

Secondary or base domain is not specified for internal switched domain

Default Severity

Error

Description

All power domains that are switched internally by switches or by regulators must be defined with a base domain that describes the external source for that domain.

Use report rule check CPF_PSW3 -verbose to get information related to the power domain. If the domain is internally switchable (has a shutoff condition, but is not defined as an externally controlled shutoff), add the base domain option.

Applicability




CPF_PSW4

MessageLow scope block(s) have physical format and higher scope does not

Default Severity

Warning

Description

This message indicates that the design hierarchical power intent includes lower-scope blocks with physical power features such as power/ground nets and switch rules. The top scope or higher scopes do not have physical power information and physical intent in the lower scope is ignored for hierarchical integration and analysis.

Use report rule check CPF_PSW4 -verbose to get details about which lower block’s physical information is ignored

Applicability




CPF_PSW5

Message

Switch rule is applied to externally switchable domain

Default Severity

Warning

Description

Indicates that an externally switchable domain has a switch rule defined for it; this causes a conflict. A domain is externally switchable when it is OFF in one or more power modes and does not have a shutoff condition; or, it has a shutoff condition and has an externally controlled shutoff option.

Use report rule check CPF_PSW5 -verbose to get information related to the power domain and switch rule. If the domain should be internally switched, make sure the domain has a shutoff condition and is OFF in one or more power modes, and does not have an externally controlled shutoff option. If the domain is externally switched, delete all switch rules for this domain.

In the case of a domain that is internally and externally switched, define a domain for the external switching and assign this as the base domain of the internally switched domain.

Applicability




CPF_PSW6

MessageMultiple signals are defined in switch enable settings

Default Severity

Warning

Description

An update power switch rule command has an enable condition with an expression of two or more control signals. This is not supported.

For a power switch with one enable; define an expression in the shutoff condition of the power domain to which it relates.

For a power switch with two enables; use enable_condition_1 and enable_condition_2 options.

For multiple switch groups with functionally-equivalent controls; use set equivalent control pins and do not update the switch rules.

For multiple switch groups with nonequivalent controls; define domain shutoff condition as expression of the controls and create a separate switch rule and update switch rule for each control.

Use report rule check CPF_PSW6 -verbose to get information on the power switch rule.

Applicability




CPF_PSW7

Message

Input and output voltage of a switch rule not compatible

Default Severity

Error

Description

A switched power domain and the base domain must be at the same nominal condition when the switched domain is ON. The power or ground voltage across the switch is expected to be zero when the switched domain is ON.

Use report rule check CPF_PSW7 -verbose to get details about the power domain and the base domain. Review both power modes to make sure they have the same nominal condition when they are ON.

Note that voltage regulated power domains do not have to be at the same nominal condition as the source power domain. This is supported by CPF 2.0; in CPF 1.1, you must define a virtual base domain for the regulated power domain to have the same nominal conditions as the regulated domain (OFF and ON) and it needs to be OFF in all power modes when the real source of the regulator is OFF.

Applicability




CPF Retention Cells

The following lists the Retention Cell (CPF_RET) rule checks:

■ CPF_RET1 on page 576


















CPF_RET1

Message

No valid retention cell defined in library to support retention rule

Default Severity

Error

Description

A retention rule specifies a different save and restore edge but there is no cell in the library that has save and restore pins.



CPF_RET2

Message

Cell specified in retention rule has only one power gating pin

Default Severity

Error

Description

A retention rule specifies a different save and restore edge but the cell specified in the retention rule has no save and restore pins.



CPF_RET3

Message

Cell specified in retention rule does not have state retention power gating attribute

Default Severity

Note

Description

A retention rule specifies a cell that does not have state retention power gating.



CPF_RET5

Message

Multiple retention rules match instance

Default Severity

Error

Description

There is more than one retention rule that applies to an instance or a flip-flop. The last rule takes precedence.



CPF_RET6

Message

Instance defined in retention rule is not valid retention object

Default Severity

Note

Description

The retention rule specifies an instance or a domain that has no flip-flops.



CPF_RET7

Message

State retention rule restore edge is not specified, the rule is ignored

Default Severity

Error

Description

The retention rule does not specify the restore_edge and the domain or the instances domain has no default_restore_edge specification.



CPF_RET8

Message

Cell specified in retention rule conflicts with cell type definition

Default Severity

Error

Description

The cell specified in the retention rule has a cell type attribute different than the one specified in the rule.



CPF_RET9

Message

State retention rule specifies cell type not existing in cell library

Default Severity

Error

Description

There is no cell in the library whose cell type attribute matches that specified in the retention rule.



CPF_RET10

Message

State retention cell save and restore condition are the same

Default Severity

Error

Description

The define_state_retention_cell command specifies the same function for both save and restore.



CPF_RET11

Message

State retention rule save and restore condition are the same

Default Severity

Error

Description

The state retention rule specifies the same edge for both save and restore.



CPF_RET12

Message

State retention cell not defined through define_state_retention_cell

Default Severity

Warning

Description

A state retention cell specified in a rule is not defined through a define_state_retention_cell command.



CPF_RET13

Message

State retention rule specifies cell without save and restore

Default Severity

Error

Description

The cell specified in define_state_retention_cell does not have a save and restore function.



CPF_RET14

Message

State retention rule specified cell with single retention control pin

Default Severity

Error

Description

The cell specified in define_state_retention_cell has only one power gating pin.



CPF_RET21

Message

State retention rule ignored due to domain being reconfigured

Default Severity

Warning

Description

When a switchable domain from a lower scope power intent is mapped to a non-switchable domain, all low power features such as state retention will no longer apply to that lower scope.

Use “report rule check CPF_RET21 –verbose” to get the retention rule and review the hierarchical power intent and domain mapping related to the power domain of that retention rule and verify the change in domain configuration is expected.

Applicability




CPF_RET22

MessageSignals defined for retention control come from different power domains.

Default Severity

Error

Description

This message indicates that a retention rule control (restore_edge, save_edge, restore_level or save_level) an expression of multiple control pins that come from different domains. This can occur when blocks with the retention control are assigned to different domains; retention controls should come from a single controlling domain.

Use report rule check CPF_RET22 -verbose for more information on the control signals and their driving domains.

Applicability




CPF_RET23

Message

Expression arguments defined in retention condition are also defined as set_equivalent_control_pins group.

Default Severity

Warning

Description

This message indicates that a retention rule control (restore_edge, save_edge, restore_level or save_level) is an expression of multiple control pins that are defined as equivalent control pins.

If each pin is for a different group of retention cells, then use the equivalent control pin master in only the retention rule.

If the expression will be synthesized and a single output drive all cells, remove the set equivalent control pins definition.

Use report rule check CPF_RET23 -verbose to get details about the isolation rule and control pins.

Applicability




CPF Power Mode Rule

■ CPF_PM1 on page 593



CPF_PM1

Message

Power modes are identical

Default Severity

Warning

Description

Indicates that two or more power modes have the same domain conditions and group mode setting.

Use report rule check CPF_PM1 -verbose to get details about which power modes are identical.

Applicability

Behavioral models or design netlists which will have low power features added during future implementation



CPF Gen Rules

■ CPF_GEN1 on page 595

■ CPF_GEN2 on page 596



CPF_GEN1

Message

Pin specified as the master of equivalent group is not the single control for the default isolation condition or shutoff condition

Default Severity

Error

Description

The master control pin applied for domain needs must be part of the definition of a shutoff condition, isolation condition, or state retention condition. The referred condition can contain only the master control pin in its expression.

Use the -verbose message to check whether the master pin is defined in the equivalent group, but not set as a shutoff condition, isolation condition, or state retention condition for the applied domain.

Applicability




CPF_GEN2

Message

Signal specified as an isolation rule equivalent group master is not in rule’s isolation condition

Default Severity

Error

Description

The master control pin applied for an isolation rule must be part of the definition of a isolation condition. The referred condition can contain only the master control pin in its expression.

Use the -verbose message to see which master pin is defined in the equivalent group but not set as an isolation condition for the applied rule.

Applicability



lowpower ref

Documents

publication subject

cadences trademarks

prior written permission

restricted print permission

permission statement

unauthorized use

low power command reference

restricted rights