pol_power

LedaPower Rules GuideVersion J-2014.12December 2014

Comments?E-mail your comments about this manual to [email protected].

Copyright Notice and Proprietary InformationCopyright 2014 Synopsys, Inc. All rights reserved. This software and documentation contain confidential and proprietary information that is the property of Synopsys, Inc. The software and documentation are furnished under a license agreement and may be used or copied only in accordance with the terms of the license agreement. No part of the software and documentation may be reproduced, transmitted, or translated, in any form or by any means, electronic, mechanical, manual, optical, or otherwise, without prior written permission of Synopsys, Inc., or as expressly provided by the license agreement.

Destination Control StatementAll technical data contained in this publication is subject to the export control laws of the United States of America. Disclosure to nationals of other countries contrary to United States law is prohibited. It is the readers responsibility to determine the applicable regulations and to comply with them.

DisclaimerSYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Registered Trademarks ()Synopsys, AMPS, Arcadia, C Level Design, C2HDL, C2V, C2VHDL, Cadabra, Calaveras Algorithm, CATS, CSim, Design Compiler, DesignPower, DesignWare, EPIC, Formality, HSPICE, Hypermodel, iN-Phase, in-Sync, Leda, MAST, Meta, Meta-Software, ModelAccess, ModelTools, NanoSim, OpenVera, PathMill, Photolynx, Physical Compiler, PowerMill, PrimeTime, RailMill, Raphael, RapidScript, Saber, SiVL, SNUG, SolvNet, Stream Driven Simulator, Superlog, System Compiler, Testify, TetraMAX, TimeMill, TMA, VCS, Vera, and Virtual Stepper are registered trademarks of Synopsys, Inc.

Trademarks ()abraCAD, abraMAP, Active Parasitics, AFGen, Apollo, Apollo II, Apollo-DPII, Apollo-GA, ApolloGAII, Astro, Astro-Rail, Astro-Xtalk, Aurora, AvanTestchip, AvanWaves, BCView, Behavioral Compiler, BOA, BRT, Cedar, ChipPlanner, Circuit Analysis, Columbia, Columbia-CE, Comet 3D, Cosmos, CosmosEnterprise, CosmosLE, CosmosScope, CosmosSE, Cyclelink, Davinci, DC Expert, DC Expert Plus, DC Professional, DC Ultra, DC Ultra Plus, Design Advisor, Design Analyzer, Design Vision, DesignerHDL, DesignTime, DFM-Workbench, DFT Compiler, Direct RTL, Direct Silicon Access, Discovery, DW8051, DWPCI, Dynamic-Macromodeling, Dynamic Model Switcher, ECL Compiler, ECO Compiler, EDAnavigator, Encore, Encore PQ, Evaccess, ExpressModel, Floorplan Manager, Formal Model Checker, FoundryModel, FPGA Compiler II, FPGA Express, Frame Compiler, Galaxy, Gatran, HDL Advisor, HDL Compiler, Hercules, Hercules-Explorer, Hercules-II, Hierarchical Optimization Technology, High Performance Option, HotPlace, HSPICE-Link, iN-Tandem, Integrator, Interactive Waveform Viewer, i-Virtual Stepper, Jupiter, Jupiter-DP, JupiterXT, JupiterXT-ASIC, JVXtreme, Liberty, Libra-Passport, Library Compiler, Libra-Visa, Magellan, Mars, Mars-Rail, Mars-Xtalk, Medici, Metacapture, Metacircuit, Metamanager, Metamixsim, Milkyway, ModelSource, Module Compiler, MS-3200, MS-3400, Nova Product Family, Nova-ExploreRTL, Nova-Trans, Nova-VeriLint, Nova-VHDLlint, Optimum Silicon, Orion_ec, Parasitic View, Passport, Planet, Planet-PL, Planet-RTL, Polaris, Polaris-CBS, Polaris-MT, Power Compiler, PowerCODE, PowerGate, ProFPGA, ProGen, Prospector, Protocol Compiler, PSMGen, Raphael-NES, RoadRunner, RTL Analyzer, Saturn, ScanBand, Schematic Compiler, Scirocco, Scirocco-i, Shadow Debugger, Silicon Blueprint, Silicon Early Access, SinglePass-SoC, Smart Extraction, SmartLicense, SmartModel Library, Softwire, Source-Level Design, Star, Star-DC, Star-MS, Star-MTB, Star-Power, Star-Rail, Star-RC, Star-RCXT, Star-Sim, Star-SimXT, Star-Time, Star-XP, SWIFT, Taurus, Taurus-Device, Taurus-Layout, Taurus-Lithography, Taurus-Process, Taurus-Topography, Taurus-Visual, Taurus-Workbench, TimeSlice, TimeTracker, Timing Annotator, TopoPlace, TopoRoute, Trace-On-Demand, True-Hspice, TSUPREM-4, TymeWare, VCS Express, VCSi, Venus, Verification Portal, VFormal, VHDL Compiler, VHDL System Simulator, and VMC are trademarks of Synopsys, Inc.

Service Marks (SM)MAP-in, SVP Caf, and TAP-in are service marks of Synopsys, Inc.

SystemC is a trademark of the Open SystemC Initiative and is used under license.ARM and AMBA are registered trademarks of ARM Limited.All other product or company names may be trademarks of their respective owners.

3Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

How Rules Are Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Manual Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Typographical and Symbol Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Getting Leda Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13The Synopsys Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 1Power Coding Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Overview of Low/Multi Power Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Power Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Specifying Power Domains with Tcl Commands . . . . . . . . . . . . . . . . . . . . . . . 18Inferring Power Domains from RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Inferring Power Domains from PG-Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Mixing Specifications and Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Mixing Specifications of Power Domains From Tcl and From RTL . . . . . . . . 27Mixing Specifications of Power Domains and Inference of Power Domains from

Power Nets on a PG-Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Power Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Specifying Level Shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31DB cellTcl Command set_level_shifterReporting Level Shifters

Specifying Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34DB cellTcl command - set_isolation_cell

Verilog $isolate system task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35VHDL isolate procedure system task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Automatic Inference of Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Reporting Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Specifying Power Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Reporting Power SwitchesSpecifying Power Cell Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Specifying Pins of a Power Library Cell and their Required Voltage Levels

4Contents

Specifying Power Pins in Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Specifying Enable Pin Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Power Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Checking Level Shifters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Checking Isolation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Checking Standard Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Operating Environment Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Relative Always on Relationship Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Verilog $retain System Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Retained Instances Specification and Always on Synthesis Consequence . . . . 58Support of Always-on Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Pin Level Library AttributeAutomatic Inference of Always_on PinsTcl command

5Contents

Support of Always-on Library Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Power Tcl commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

connect_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60create_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61create_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61create_power_net_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62delete_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63disable_isolation_cell_recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63enable_isolation_cell_recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63get_all_input_boundaries_from_power_domain . . . . . . . . . . . . . . . . . . . . . . . . 64get_all_output_boundaries_from_power_domain . . . . . . . . . . . . . . . . . . . . . . . 64get_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64get_clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65get_nets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65get_nth_power_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66get_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66get_ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66get_power_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67get_power_domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67get_power_down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68get_power_down_ack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68get_power_net_max_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68get_power_net_min_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69get_power_net_source_port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69get_power_net_type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69getn_power_net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69infer_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70infer_power_domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70remove_isolation_cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70remove_level_shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71remove_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71remove_power_net_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71report_enable_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72report_isolation_cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72report_level_shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72report_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73report_pin_voltages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73report_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73report_power_net_info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74report_power_pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6Contents

report_power_switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74reset_isolation_cell_recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74set_operating_conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74set_power_domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75set_power_domain_ctrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75set_power_off_value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76set_power_pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76set_power_switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76set_relative_always_on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77set_voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Level-Shifters Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78VDPAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Message: Avoid disjoint voltage domains: %s1 and voltage domain: %s2LSINSALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Message: Missing level shifter from %f1 to %f2: %s1. From pin/signal (voltage %f1): %s2 to pin/signal (voltage %f2): %s3

LSINSL2H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Message: Missing level shifter from %f1 to %f2: %s1. From pin/signal (voltage %f1): %s2 to pin/signal (voltage %f2): %s3.

LSINSH2L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Message: Missing level shifter from %f1 to %f2: %s1. From pin/signal (voltage %f1): %s2 to pin/signal (voltage %f2): %s3.

LSNONEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Message: Unnecessary level shifter: %s

LSREDSER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Message: Level shifter %s is unnecessary (redundant with %s1): %s2

LSREDPAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Message: Better split out wires after level shifters than before: %s1. The level shifter: %s2. The level shifter: %s3

LSLOCALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Message: Level shifter must be located in the lower voltage domain (voltage %f instead of %f / neutral region) %s

LSLOCL2H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Message: Level shifter (low to high) must be located in the higher voltage domain (voltage %f instead of %f / neutral region) %s

LSLOCH2L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Message: Level shifter (high to low) must be located in the lower voltage domain (voltage %f instead of %f / neutral region) %s

LSPOWALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Message: Level shifter must be located outside power domain %s (in a region always powered-on): %s

LSPINVOLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Message: Level shifter badly connected: %s. Pin voltage is %f instead of %f: %s

7Contents

Isolation Cells Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97ICINSALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Message: Missing isolation cell for power domain %s1: %s2. From pin/signal: %s3 to pin/signal: %s4

ICINSOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Message: Missing isolation cell for power domain %s1: %s2. From pin/signal: %s3 to pin/signal: %s4

ICINSIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Message: Missing isolation cell for power domain %s1: %s2. From pin/signal: %s3 to pin/signal: %s4

ICNONEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Message: Isolation cell %s is unnecessary: %s

ICNONEEDIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Message: Isolation cell %s is unnecessary: %s

ICLOCALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Message: Isolation cell must be located outside power domain %s (in a region always powered-on): %s

ICNOBUFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Message: No buffer is allowed between output port %s of power domain %s and isolation cell %s

ICPINVOLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108Message: Pin of isolation cell %s should be connected to voltage %f instead of %f: %s

ICOFFVAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Message: Isolation cell power off value mismatch with control specification of power domain %s1: %s2. Power off value is %s3 instead of %s4: %s5. Control signal power on value %s6: %s7

RTL Ruleset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110RTLPOW00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Message: Wrong number of arguments passed - at least 6 arguments are expected. Current $power statement will be ignored by Leda power checks

RTLPOW01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Message: First argument to $power (power domain name) must be a quoted string. Current $power statement will be ignored by Leda power checks

RTLPOW02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Message: Second argument to $power (power_on net) must be a valid signal name. Current $power statement will be ignored by Leda power checks

RTLPOW03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Message: Third argument to $power (on_sense expression) must be a valid expression. Current $power statement will be ignored by Leda power checks

RTLPOW04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Message: Fourth argument to $power (power_on ack net) must be a valid signal name. Current $power statement will be ignored by Leda power checks

RTLPOW05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Message: Fifth argument to $power statement (ack_sense expression) must be a valid expression. Current $power statement will be ignored by Leda power checks

8Contents

RTLPOW06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Message: Argument must be a valid instance name. Current $power statement will be ignored by Leda power checks: Argument %d

RTLPOW07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Message: $power must occur in an initial block

RTLPOW08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Message: $power statement must not be nested within any control structure

RTLPOW08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Message: Power procedure call must not be nested within any control structure

RTLPOW09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Message: $power statement must not be preceded by any timing control

RTLPOW09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Message: Power procedure call must not be preceded by any timing control

RTLPOW10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Message: Each instance in a design may be named in a power statement only once. Instance name will be ignored in enclosing statement: %s

RTLPOW11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Message: Power domains cannot be redefined at different hierarchical levels. Current statement will be ignored in power domain elaboration

RTLPOW20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Message: Signals passed as arguments to $power must be wires declared in the same module

RTLPOW20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Message: Signals passed as arguments to the power procedure call must be declared in the same design entity

RTLPOW21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Message: Register initialized by a constant

RTLPOW22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Message: Extra drivers detected for powerup_ack_net signal: %s

RTLPOW23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Message: Non edge-sensitive logic detected on boundary of power-down region.

RTLPOW24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Message: Nested non-contiguous power regions detected

RTLISO00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Message: Wrong number of arguments passed - exactly 4 arguments are expected. Current $isolate statement will be ignored by Leda power checks

RTLISO01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Message: First argument to $isolate (output net) must be a valid signal name. Current $isolate statement will be ignored by Leda power checks

RTLISO02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Message: Second argument to $isolate (enable net) must be a valid signal name. Current $isolate statement will be ignored by Leda power checks

RTLISO03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Message: Third argument to $isolate (input net) must be a valid signal name. Current $isolate statement will be ignored by Leda power checks

9Contents

RTLISO04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Message: Output and input signals must be of the same type. Current $power statement will be ignored by Leda power checks

RTLISO05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Message: Fourth argument to $isolate statement must have the same type as the output signal (first argument). Current $isolate statement will be ignored by Leda power checks

RTLISO06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Message: $isolate must be in an always block

RTLISO07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Message: Enclosing always of $isolate must be combinational

RTLISO08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Message: Each signal in $isolate must appear in sensitivity list of enclosing always block

RTLRET00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Message: Wrong number of arguments passed - at least 5 arguments are expected. Current $retain statement will be ignored by Leda power checks

RTLRET01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Message: First argument to $retain (save_signal net) must be a valid 1 bit signal name. Current $retain statement will be ignored by Leda power checks

RTLRET02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Message: Second argument to $retain (save_sense expression) must be a valid expression (0 or 1). Current $retain statement will be ignored by Leda power checks

RTLRET03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Message: Third argument to $retain (restore signal) must be a valid, 1-bit signal name. Current $retain statement will be ignored by Leda power checks

RTLRET04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Message: Fourth argument to $retain statement (restore_sense expression) must be a valid expression. Current $retain system task will be ignored by Leda power checks

RTLRET05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Message: Fifth argument to $retain statement (type) must be a valid type. Current $retain statement will be ignored by Leda power checks

RTLRET06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Message: Argument must be a valid instance name. Current $retain statement will be ignored by Leda power checks: Argument %d

RTLRET07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Message: $retain must occur in a TOP level initial block

RTLRET08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Message: $retain statement must not be nested within any control structure

RTLRET09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Message: $retain statement must not be preceded by any timing control

RTLRET10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Message: Extra drivers detected for powerup_ack_net signal

10

Contents

11

Preface

Preface

About This ManualThis book contains reference information for prepackaged rules that come with the Leda Checker tool. This information mirrors the information available in the HTML-based help files that you access directly from the Leda Checker tools Error Report. The purpose of this book is to provide a reference that you can view online or print out so that you can review available prepackaged rules and decide which ones you want to use before running the Checker tool on your HDL source files. On the other hand, the HTML-based help system is designed to provide random access to this same information from the Checker Error Report, so that you can quickly access more information about a specific rule that was violated, including in some cases, circuit diagrams and valid and invalid examples of Verilog or VHDL code.

This book is intended for use by hardware design and quality assurance engineers who are already familiar with VHDL or Verilog.

How Rules Are OrganizedRules are organized into major categories called policies, which have multiple rulesets. Each ruleset can contain multiple rules. You use the prepackaged rules to check your VHDL or Verilog source code for compliance with various standards and compatibility with downstream tools in the design and verification flow. Some rules apply just to Verilog or VHDL and some apply to both HDLs. The documentation for each rule, both in the HTML-based help system and in this manual clearly labels which languages each rule applies to.

NoteThere is a separate book for each policy (set of prepackaged rules) that Leda supports.

12

Preface

Related DocumentsThis manual is part of the Leda document set. To see a complete listing or to navigate to another online document in the set, refer to the Leda Document Navigator.

Manual OverviewThis manual contains the following chapters and appendixes:

Typographical and Symbol ConventionsThe following conventions are used throughout this document:

Preface Describes the manual and lists the typographical conventions and symbols used in it; explains how to get technical assistance.

Chapter 1Power Coding Rules

Detailed reference information for all rules in the Leda Power rules policy.

Table 1: Documentation Conventions

Convention Description and Example

% Represents the UNIX prompt.

Bold User input (text entered by the user).% cd $LMC_HOME/hdl

Monospace System-generated text (prompts, messages, files, reports).No Mismatches: 66 Vectors processed: 66 Possible"

Italic or Italic Variables for which you supply a specific value. As a command line example:% setenv LMC_HOME prod_dir

In body text:In the previous example, prod_dir is the directory where your product must be installed.

| (Vertical rule) Choice among alternatives, as in the following syntax example:-effort_level low | medium | high

[ ] (Square brackets) Enclose optional parameters:pin1 [pin2 ... pinN]

In this example, you must enter at least one pin name (pin1), but others are optional ([pin2 pinN]).

13

Preface

Getting Leda HelpFor help with Leda, send a detailed explanation of the problem, including contact information, to [email protected].

The Synopsys Web SiteGeneral information about Synopsys and its products is available at this URL:

http://www.synopsys.com

TopMenu > SubMenu Pulldown menu paths, such as:File > Save As

Table 1: Documentation Conventions (Continued)

Convention Description and Example

14

Preface

15

Chapter 1: Power Coding Rules

1Power Coding Rules

IntroductionThis chapter presents reference information for the Power policy. This policy contains general-purpose rules that cover many aspects of low-power checks, and a list of new prepackaged netlist checks in this domain.

AttentionThe Power Policy is currently in Limited Customer Availability (LCA) status. To use this policy, you need a separate Leda-power license feature. For more information, contact your sales representative.

16


Overview of Low/Multi Power DesignsDesigns may contain one or more blocks that operate at different voltage levels. More complex designs may even allow some of these blocks to be switched off from time to time to reduce power consumption. Synopsys implementation tools, including Leda, use the notion of power domain to describe both these types of design. A power domain is a logical grouping of one or more hierarchical blocks in a design that share the same:

Primary voltage states or voltage range.

Power down control and acknowledge signals, if any.

Other characteristics that implementation tools use, but which Leda ignores.

Figure 1 shows a multi-voltage design with two different power domains, one containing TOP and TOP.A and operating at 1.2V and the other containing TOP.B and operating at 1.4V. Signals going from one domain to the other require level-shifter cells to enable them to work at the different voltage levels. These are shown as buffers TOP.LS1 and TOP.LS2 in the figure.

Figure 1: Multi-Voltage Design

T O P . A ( 1 . 2 V ) T O P . B ( 1 . 4 V )

T O P ( 1 . 2 V )

T O P . B . G 1

LS

T O P . A . G 3T O P . L S 2 T O P . B . G 2

LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . A . G 1T O P . L S 1

T O P . A ( 1 . 2 V ) T O P . B ( 1 . 4 V )

T O P ( 1 . 2 V )

T O P . B . G 1

LS

T O P . A . G 3T O P . L S 2 T O P . B . G 2

LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . A . G 1T O P . L S 1

17


All cells instantiated in a multi-voltage design must work at the voltage level of the power domain in which they have been instantiated. This usually means different technology libraries for each voltage level. It also means that these technology libraries must include the appropriate level-shifter cells. The common practice is to group all these libraries into a common target library called a multi-NLDM library where NLDM stands for Non-Linear Data Model. Library selection is done by setting power contexts.

When dealing with multi-voltage designs, you also need to instantiate isolation cells to protect the power domains from each other. These must also appear in the technology libraries.

In most cases, information about power domains, cannot be extracted automatically from a design, and so you need to provide it. You can do this by:

Using commands such as create_power_domain in the Tcl-shell.

Using the Verilog $power system task call or the VHDL power procedure call in RTL code.

Scanning source power net trees in the PG-netlist (PG stands for Power-Ground)

Leda accepts all these methods and also allows you to combine them. In addition, the commands that Leda uses for defining power domains are identical to the commands used by other Synopsys tools.

The following sections contain details on using each of these methods to define power domains for Leda and the rules available to check them.

18


Power DomainsThis section describes the different ways to infer power domains in Leda. These are:

Using commands such as create_power_domain in the Tcl-shell.

Using the $power and $isolate system calls in RTL code.

Scanning source power net trees in the PG-netlist (PG stands for Power-Ground)

Specifying Power Domains with Tcl CommandsThe command to create power domains in Tcl is create_power_domain. You also need to specify a voltage specification for the power domain and then connect the power domain to the voltage specification. To do this, use the commands create_power_net_info and connect_power_domain.

Use the following commands to specify the power domains shown in Figure 1:Leda> create_power_net_info VDD12 -power -nominal_voltages {1.2} Leda> create_power_net_info VDD14 -power -nominal_voltages {1.4}

#If no cells are specified, then power domain is associated with TOP

Leda> create_power_domain POW12

Leda> create_power_domain POW14 object_list [get_cells IB]

Leda> connect_power_domain POW12 primary_power_net VDD12

Leda> connect_power_domain POW14 primary_power_net VDD14

For complete syntax of these commands, refer section Power Tcl commands on page 60.

When you create a power domain, Leda can automatically infer level shifters and isolation cells from DB libraries, if the corresponding cells have the following attributes:

Level shifter: is_level_shifter

Isolation cell: is_isolation_cell

Leda can also infer the cells if you have specified them explicitly in the Tcl shell using the following commands:

Leda> set_level_shifter

Leda> set_isolation_cell [] [-instances [instance_name_list] ]

19


Once this inference is complete, Leda provides many checks for coherence of the power domains. For example:

LSINSALL - Checks that a level shifter has been inserted on every connectivity path between logic or wires of two distinct voltage domains (with two different voltage levels).

LSNONEED - Check that level shifters have not been inserted between voltage regions/blocks of the same voltage level.

LSPINVOLT - Checks that level shifter pins are connected to the correct voltage domains, i.e. the voltage levels of the two voltage domains separated by a given level shifter match the voltage values specified for the two (in and out) pins of the given level shifter

ICINSALL - Checks that isolation cells are inserted on any connectivity path of any port of a power domain.

ICNONEED - Checks that isolation cells are inserted on a path that does neither reaches any power domain input port nor originates from any output port of a power domain

ICNOBUF - Checks that no buffers are present between the output ports of a power domain and the isolation cells

Inferring Power Domains from RTLLeda can infer power domains from RTL and combine them with those specified in Tcl mode. In Verilog, you can use the $power system task for this inference and in VHDL, you can use the power procedure call for power inference.

You need to decide whether the RTL-specified power domains are to be used or not. This is done through the infer_power_domains command in Tcl mode. You must execute this command after the elaboration command, like for any other Tcl power command:

Leda> elaborate top TOP

Leda> infer_power_domains

When instructed to do, Leda infers each of the following power domains:initial $power (, , ,

, , , , ... , )

20


This is exactly as if you had specified the following Tcl power command:create_power_domain [-power_down] [-power_down_ack ] [-power_down_ctrl ][-power_down_ack_sense ] [-power_down_ctrl_sense ][-object_list ]

The Leda checker handles power domains inferred from RTL in exactly the same way as their equivalent Tcl-specified power domains, with the following restrictions:

Power domains inferred from RTL cannot be removed by the command remove_power_domain. Leda issues an error message if remove_power_domain is called in the same Tcl session after command infer_power_domains.

Command report_power_domain is available on the power domains inferred from RTL.

In Verilog, a power domain is defined through the $power system task called from an initial statement like:

initial $power (, , , , , , , ... , )

Argumentsdomain_name Power domain name written as a string (within double quotes).

power_on_net The control signal for power on. It is limited to simple signals to avoid creation of implicit power domains. Simple signal means only wiring is required. If the width is wider than one bit, the lowest bit is taken. Bus representation for staggered power-on is not supported in this version.

on_sense_expression A constant number indicating the power-available sense of the power-on expression. The sense expression should have the same width as the power-on expression in a bit-to-bit correspondence to the power-on expression, and should only consist of 1s and 0s (no xs). Presently, only single bit numbers are supported. If the number has more than one bit, only the lowest bit is used.

power_on_ack_net The power up acknowledge expression is used to acknowledge to the outside environment (the power controller) that the power domain is fully up and running. It is limited to simple signals because $power drives this net. If the

21


width is wider than one bit, the lowest bit is used. Bus representation for staggered power-on is not supported in this version.

ack_sense_expression A constant number indicating the power-available sense of the power-ack expression. The sense expression must have the same width as the power-ack expression in a bit-to-bit correspondence to the power-ack expression, and should only consist of 1s and 0s (no xs). Presently, only single bits are supported. If the number has more than one bit, only the lowest bit is used.

instance_n A list of modules belonging to the power domain. Named blocks are not allowed. All the logic contained in the instances is assumed to be part of the defined power domain. In this version, hierarchical module instance reference is not allowed. Quoted names are allowed to create wildcard, and they take the form of a*, u*, etc. Exclusion is temporarily not supported.

For example:initial $power(pd1, pd_sig, 1`b0, p_ack, 1`b1, a, b*)

AttentionUse of wild cards (*) in instance names is temporarily not supported by Leda.

In VHDL, a power domain is defined through the power procedure system task called from an initial statement like:

procedure power (, , , , , , , ... , )

Argumentsdomain_name Power domain name written as a string (within double quotes).

on_sig The on_sig must be one of the following data types namely bit, bit_vector, std_logic, std_logic_vector.

on_sense The on_sense is a constant expression. If it is a 1-bit constant, then it must be either 0 or 1. The data type must match with that of the data type of on_sig.

ack_sig The ack_sig must be an output signal and the data type must match with that of the data type of on_sig. It can take the value of any constant expressions or a single bit value 0 or 1.

22


ack_sense The ack_sense is a constant expression. If it is a 1-bit constant, then it must be either 0 or 1. The data type must match with that of the data type of on_sig.

instance_n A list of modules belonging to the power domain. In this version, hierarchical module instance reference is not allowed. Wildcard expressions are also not supported.

For example:power("domain_name", power_on, "1", power_ack, "1", "IP1");

23


Inferring Power Domains from PG-NetlistThe final method of inferring power domains is through PG-Netlist (PG stands for Power-Ground). A PG-Netlist is a gate-level description with explicit representation of power supply pins and nets, and instantiations of library cells using the new PG-Pin Liberty format. The following example is a simplified version of Figure 1.

Figure 2: PG-Netlist Schematic

Here, the design contains explicit connection of power supplies. Note that voltage indication near the module names (TOP.A, TOP.B) have been removed and have been attached to the top-level port names (VDD1 and VDD2). This is to illustrate the fact that a PG-Netlist implicitly includes the information on power domains through the actual power connections to all the cells of the design. Therefore there should be no need for you to specify power domains with the command create_power_domain. With PG-Netlist, you need to specify power nets using the create_power_net_info command and its source_port attribute:

create_power_net_info VDD1 power nominal_voltages {1.2} source_port TOP.VDD1

create_power_net_info VDD2 power nominal_voltages {1.4} source_port TOP.VDD2

T O P . A T O P . B

T O P

T O P . A . G 1 T O P . L S 1T O P . B . G 2

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

A

BY A YLS

A

BY

T O P . A T O P . B

T O P

T O P . A . G 1 T O P . L S 1T O P . B . G 2

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

A

BY A YLSLS

A

BY

24


But Leda does not automatically infer power domains from a PG-Netlist description. You must execute following commands to perform the inference:

infer_power_domains power_nets {VDD1 VDD2}

More precisely, Leda infers the power domains and their corresponding boundaries that are defined as follows:

The power domain Leda infers for a given power net. For example, VDD1 in Figure 2 is the set of gates/cells that are connected only to those power nets/ports of the PG-Netlist that are driven by the primary power port corresponding to the given power net - e.g. TOP.VDD1 above (the only implies in particular that the cells that are connected to multiple power supplies are not included in such power domains).

The boundary of an inferred power domain is the list of pins of the corresponding gates/cells that are either connected directly to primary ports or that are connected to at least one gate/cell that is not part of the inferred power domain.

The power domain is not considered always on if the supplied power net is switchable. Moreover, in Leda, you can specify the type of power switch cells with the following command:

set_power_switch

Leda bypasses instances of specified power switch cells to follow the inference. It gets the internal power net to reach connected cells to infer sub power domains that are not always on by the presence of these switch boxes.

NoteLeda does not recognize currently the enable and the acknowledge signal of inferred domains when bypassing a single or daisy-chained power switch cells.

25


The following example illustrates this power domain inference.


In Figure 3, the power domain inferred for VDD1 includes the gates TOP.A.G1, TOP.A.G2 and TOP.A.G3, and the boundary of this power domain includes the pins TOP.A.G1.A, TOP.A.G2.A, TOP.A.G3.B, TOP.A.G1.Y and TOP.A.G3.Y (in red). In this example, this power domain boundary matches the hierarchical boundary of TOP.A, but although this is probably desired for the implementation tool flow, it is not the general case, which is illustrated by the following example.

T O P . A T O P . B

T O P

T O P . L S 1 T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

A

BY LS

T O P . A . G 3

T O P . L S 2 T O P . B . G 2

LST O P . A . G 2 A

BY

A

BY

A

BY

A Y

A Y

A Y

T O P . A . G 1

T O P . A T O P . B

T O P

T O P . L S 1 T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

A

BY LSLS

T O P . A . G 3

T O P . L S 2 T O P . B . G 2

LSLST O P . A . G 2 A

BY

A

BY

A

BY

A Y

A Y

A Y

T O P . A . G 1

26



The power domain inferred for VDD1 in Figure 4 includes the gates TOP.A.G1, TOP.A.G2, TOP.A.G3 and TOP.G1, and the boundary of this power domain includes the pins TOP.A.G1.A, TOP.A.G2.A, TOP.A.G3.B, TOP.A.G1.Y and TOP.G1.Y (in red). Therefore this boundary does not match any hierarchical boundary.

T O P . A TOP.B

T O P

T O P . A . G 1 T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

LS

T O P . A . G 3 T O P . L S 2 T O P . B . G 2

LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1

T O P . A TOP.B

T O P

T O P . A . G 1 T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

LSLS


LSLST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1

27


Mixing Specifications and InferenceAs we have seen, power domain information can come from different sources and this needs to be resolved. This section describes how this resolution is carried out.

Mixing Specifications of Power Domains From Tcl and From RTL

In the same Tcl session, you can mix power domains created by the create_power_domain command and power domains created by the $power statements in the RTL using the infer_power_domains command. So both the following sequences are equivalent if there is no conflict in specification:

Leda> create_power_domain


or


Leda> create_power_domain

But, from mixed specifications, two kinds of conflict can occur:

Same power domain name used

Same power region referenced

For the first case, Leda issues an error message when trying to create a power domain with the same name as an existing power domain.

For the second case, Leda moves the power region to the latest power domain referencing the region and if the source power domain has no more objects, Leda removes it. Leda issues information messages for each of these steps.

Here are the dependencies and ordering of steps:

28


Figure 5: Dependencies and Ordering of Power Commands

Mixing Specifications of Power Domains and Inference of Power Domains from Power Nets on a PG-Netlist

In the same Tcl session, you can mix logical power domains (created using Tcl specification or $power statement) and physical power domains (inferred from power net connections).

Let us take the same example of PG-Netlist (see: Figure 6):


P o w e r d o m a i n s s p e c i f i c a t i o ns

c r e a t e _ p o w e r _ d o m a i n

c r e a t e _ p o w e r _ n e t _

i n f o-v o l t a g e _ v a l u e s

| -v o l t a g e _ r a n g e

c o n n e c t _ p o w e r _ d o m a i n

i n f e r _ p o w e r _d o m a i n s

( $ p o w e r I n R T L )

L e v e l s h i f t e r s c h e c k s

i s o l a t i o n c e l l s c h e c k s

s e t _ o p e r a t i n g _ c o n d i t i o n s p o w e r_

d o m a i n s

>




i n f o-n o m I n a l _ v o l t a g e s

| -v o l t a g e _ r a n g e s







d o m a i n s

>

s e t _ v o l t a g e -o b j e c t _ l i s t




i n f o-v o l t a g e _ v a l u e s

| -v o l t a g e _ r a n g e







d o m a i n s

>




i n f o-n o m I n a l _ v o l t a g e s

| -v o l t a g e _ r a n g e s







d o m a i n s

>

s e t _ v o l t a g e -o b j e c t _ l i s t

T O P . A T O P . B

T O P

T O P . A . G 1TOP.B.G1

V D D 1 ( 1. 2 V ) V D D 2 ( 1 . 4 V)

LS


LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1

T O P . A T O P . B

T O P

T O P . A . G 1TOP.B.G1

V D D 1 ( 1. 2 V ) V D D 2 ( 1 . 4 V)

LSLS


LSLST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1

29


Level shifters are correctly instantiated/connected in this example. If you check it using the following sequence (sequence A) of Tcl commands, power domains are automatically inferred from the power ports VDD1 and VDD2.

Leda> infer_power_domains power_nets {VDD1 VDD2}Leda> check

But lets assume you check the same PG-Netlist using the power domains specified through the following sequence (sequence B) of Tcl commands:

Leda> create_power_net_info VDD1 power nominal_voltages {1.2} source_port TOP.VDD1


Leda> create_power_domain POW_TOP

Leda> connect_power_domain POW_TOP primary_power_net VDD2

#Note: VDD2 instead of VDD1 is the dummy info

Leda> create_power_domain POWA object_list [get_cells A]Leda> connect_power_domain POWA primary_power_net VDD1

Leda> create_power_domain POWB object_list [get_cells B]Leda> connect_power_domain POWB primary_power_net VDD2

Leda> check

In this case, power net connections in the PG-Netlist are ignored (because no infer_power_domains is executed), and the checker reports a missing level shifter between TOP.A.G3 (part of POWA, connected to VDD1) and TOP.G1 (part of POW_TOP, connected to VDD2), as well as an unnecessary level shifter TOP.LS2 between TOP.G1 and TOP.B.G2 (both gates respectively part of POW_TOP and POWB, both power domains connected to VDD2).

The reason for these differences between both sequences (one with create_power_domain commands, one with infer_power_domains commands) is caused by the difference between the specification of the power domains (using create_power_domain commands, typically written at RTL stage) and the actual implementation of the power domains (inferred by infer_power_domains commands from the PG-Netlist).

30


To help detect such differences between specification and implementation of power domains, the tool allows you to combine both the specification and inference of power domains into one sequence, as follows:






Leda> create_power_domain POWB object_list [get_cells B]Leda> connect_power_domain POWB primary_power_net VDD2

Leda> check

Leda> infer_power_domains power_nets {VDD1 VDD2}Leda> check

In this sequence, the first check only the power domains specified with the create_power_domain commands (so the results are the same as sequence B ), whereas the second check uses the inferred power domains which have higher priority for the checks (so the results are the same as sequence A ).

In addition, the execution of the command infer_power_domains in this sequence reports each instantiated standard cell that is effectively connected (in the PG-Netlist) to a primary power net (VDD1 or VDD2). This is different from the primary power net associated with the power domain specified with create_power_domain and including the instantiated cell.

31


In this example, the first infer_power_domains command (for PD1) reports the following consistency error:

Inferring power domain PD1 from power net VDD1 ...

Error: Cell 'TOP.G1' is connected to primary power net 'VDD1' while located in power region of power domain 'POW_TOP' connected to primary power net 'VDD2'. (POW-014)Inference of power domain PD1 completed.

Here are the dependencies:

Figure 7: Dependency of Commands

Power CellsAs mentioned previously, cells such as level shifters and isolation cells can be automatically identified from DB library information or explicitly specified with shell commands. For isolation cells, Leda can also automatically recognize standard cells used as isolation cells based on structure analysis. In this section we describe how this is done.

Specifying Level ShiftersYou can specify level shifters in two different ways: as DB cells or with the set_level_shifter Tcl command.

DB cellDB cells used as level shifters must have the predefined Boolean attribute is_level_shifter set to true.

P o w e r d o m a i n s s p e c i f i c a t i o n s

c r e a t e _ p o w e r _ n e t _ i n f o

-v o l t a g e _ v a l u e s | -v o l t a g e _ r a n g e



P o w e r d o m a i n s i n f e r e n c e f r o m

p o w e r n e t

S t a n d a r d c e l l s c h e c k s



-n o m i n a l_vo l t a g e




p o w e r n e t








p o w e r n e t








p o w e r n e t








p o w e r n e t








p o w e r n e t


32


The specific type of the level shifterbuffer-type or enabled-type is deduced as follows: if one pin of the cell has the boolean attribute level_shifter_enable_pin set to true, then it is an enabled level shifter (and in this case the cell is also an isolation cell) and the corresponding pin is the enable pin. Otherwise it is a buffer-type level shifter and it cannot be used as an isolation cell.

Tcl Command set_level_shifter Leda> set_level_shifter {}

Here, the cell names are Verilog module/primitive names or VHDL entity names.

Subsequent calls to the set_level_shifter command add more cells to the list of level shifter cells. You can remove a cell from the list of level shifters using the remove_level_shifter Tcl command.

Leda> remove_level_shifter {}

Note that only the level shifters defined with set_level_shifter can be removed; not the DB cells.

You can specify the specific type of the level shifter, buffer-type or enabled-type as follows. You can specify the enable pin of the cell (if any) using the set_enable_pin routine described in section Specifying Enable Pin Names on page 44. If you do this, the corresponding cell is an enabled level shifter and can be used as an isolation cell.

33


Reporting Level ShiftersYou can list all defined level shifters with the report_level_shifters command as follows:

Leda> report_level_shifters

===== Level shifters =====

by cell type:

* with set_level_shifter:

buffer type:

...

enable type:

...

* from DB libraries:

buffer type:

...

enable type:

...

by instance:

* with set_level_shifter:

34


...


:

:

...

:

Specifying Isolation CellsYou can specify isolation cells in four different ways:

As DB cells

By using the set_isolation_cell Tcl command in Ledas Tcl shell

By using the $isolate system task in the Verilog code

By using Ledas automatic inference of isolation cells from any standard cell.

DB cellDB cells used as isolation cells must have the predefined Boolean attribute is_isolation_cell set to true.

Some level shifter cells can also be used as isolation cells.

Tcl command - set_isolation_cellLeda> set_isolation_cell {} | -instances {}

With the set_isolation_cell Tcl command, you can specify either a list of cell names (Verilog module/primitive names or VHDL entity names) or a list of cell instances. Cell instances are hierarchical instance names used to differentiate between instances of a cell that are used for different purposes. For example, they are used to differentiate several instances of a given NAND cell that are used as isolation cells from other instances of the same NAND cell that are used as logic gates.

35


Subsequent calls to the set_isolation_cell command add more cells to the list of isolation cells. You can remove a cell from the list of isolation cells using the remove_isolation_cell Tcl command.

Leda> remove_isolation_cell {} | -instances {}

NoteOnly isolation cells defined with set_isolation_cell can be removed and not the DB cells.

Verilog $isolate system taskTo describe isolation cells with $isolate, the Verilog system task should be used as follows:

$isolate (, , , );

Argumentsoutput_net The output variable to be assigned to.

enable_net The enable signal

input_net The input data to be isolated. Its type must match exactly the type of the output variable.

unpowered_expr The unpowered expression to be used when the enable signal is low. This expression must match exactly the type of the output variable/data input, or be one of 1bz, 1b0, 1b1. In addition, the $isolate call should be embedded in an always constructs sensitive to any input with @*. For example:

always @*

$isolate(, , , );or

always @*

begin

$isolate(, , , );end

Leda infers an isolation cell instance from any $isolate system call, irrespective of its declaration place. But a predefined check issues an error message if the $isolate call is not in an always construct that is level-sensitive (combinatorial, not edge-sensitive) and that includes all three nets of the $isolate call in its sensitivity list.

36


Ledas inference of isolation cells specified in the RTL code with $isolate will be automatic (no user control). The $isolate PLI system call is just another way to specify isolation cells, complementary to the LIB/DB attribute is_isolation_cell or the Tcl command set_isolation_cell.

Leda will infer an isolation cell instance for the following RTL code:always @*

begin

$isolate(, , , );end

It does so in exactly the same way as it would have for the following RTL code:always @*

begin

=( ? : );end

The resulting inferred gate instance (with an implicit name such as ~isolate%d) is specified as an isolation cell using the command:

set_isolation_cell instances {.~isolate%d}

For example, the following construct:always @*

begin

$isolate(, , , );

$isolate(, , , );

end

37


This is inferred in exactly the same way as:always @*

begin

=( ? : );

=( ? : );

end

The only difference is the specific (implicit) naming of the instance and its registration as an isolation cell instance (equivalent use of set_isolation_cell).

Isolation cells inferred from RTL are handled by the Leda checker exactly as the isolation cells specified with a DB attribute (in particular, they cannot be removed with remove_isolation_cell). The command report_isolation_cells will report the $isolate inferred cells with the file name and line number at which they appear in the RTL code.

VHDL isolate procedure system taskTo describe isolation cells with isolate procedure, the VHDL system task should be used as follows:

procedure isolate (, , , );

Argumentsdata_out Isolated output signal to be presented to the surrounding

environment. This signal is of the same type as the non-isolated signal (3rd argument).

iso Signal that selects the isolated value which is driven to the output (isolated_signal). The enable signal must be a 1-bit logic net whose power is never shut down. If enable is 1, the (non-isolated) output value is driven to the output. If enable is 0, the clamp value is driven to the output. If enable is X, U, or Z an X shall be driven to the output.

data_in Non-isolated output signal to be isolated. The type of this signal must match exactly the type of the isolated signal output.

38


clamp Constant expression to be driven when the enable signal is low (power is shut off). This expression must match exactly the size of the output variable, or be one of the 1-bit constants 0, 1, or Z. In the latter case, the designated 1-bit value is applied to all bits of the isolated signal.

Automatic Inference of Isolation CellsIf you want to consider (AND, OR, NAND, NOR) standard cells as possible isolation cells, you can let Leda to recognize the ones that are effectively used as isolation cells. This will avoid the usage of the set_isolation_cell command or the usage of specific cells with specific attributes. The recognition is not enabled by default. You must execute the following command after elaboration and before power checks:

Leda> enable_isolation_cell_recognition

The recognition is done while checking the necessity of an isolation cell on each connectivity path connected to a power region. Leda performs a structural analysis of the connection of the other pin of the cell to find a dependency with the power down control signal in the specification of the power domain. If the cell is a valid isolation cell, then the other pin is equivalent to the enable pin of the cell.

39


In the following example, Leda recognizes TOP.G1 standard cell as isolation cellLeda> enable_isolation_cell_recognition

Leda> create_power_domain power_down power_down_ctrl [get_ports EN] object_list [get_cells A]

Figure 8: Isolation Cell Inference

T O P . A T O P . B

T O P

A

BY

E N

T O P . G 1

A Y

T O P . A T O P . B

T O P

A

BY

E N

T O P . G 1

A Y

40


Reporting Isolation CellsYou can list all defined isolation cells using the report_isolation_cells command as follows:

Leda> report_isolation_cells

===== Isolation cells =====

by cell type:

* with set_isolation_cell:

...


...

by instance:

* with set_isolation_cell:

...

* with set_isolation_cell -instances:

...


:

41


:

...

:

* from $isolate calls:

...

* recognized:

...

Leda issues a warning message if you execute the report_isolation_cells command when the recognition has been enabled but the checks have not been run.

Specifying Power SwitchesYou can use the command set_power_switch, only if the PG-Netlist has blocks that can be shutdown (multi-power != multi-voltage) and that are isolated by power switches at block-level, typically using coarse-grained MTCMOS switches (other isolation techniques exist, e.g. using fine-grained instead of coarse-grained MTCMOS switches). In this case, you should specify the names of the power switch cells so that the power domain inference can by-pass power switches. This is done using the set_power_switch command as shown in the Figure 9.

42


Figure 9: Isolation Cell Inference

In Figure 9, power domain inferencing via the source port of specified net VDD1 stops on cell TOP.G1, because Leda does not recognize the switch functionality of the cell.

To identify this cell as a power switch, you need to use the set_power_switch command.Leda> set_power_switch

Leda bypasses instances of specified power switch cells to follow inferencing. This step is similar in getting the internal power net to reach connected cells.

TOP.A TOP.B

TOP

TOP.A.G1

TOP.LS1TOP.B.G1

VDD1 (1.2V) VDD2 (1.4V)

A

BY LS

TOP.A.G3

TOP.LS2TOP.B.G2

LSTOP.A.G2A

BY

A

BY

A

BY

A Y

A Y

A Y

EN ACKTOP.G1

TOP.A TOP.B

TOP

TOP.A.G1

TOP.LS1TOP.B.G1

VDD1 (1.2V) VDD2 (1.4V)

A

BY LSLS

TOP.A.G3

TOP.LS2TOP.B.G2

LSLSTOP.A.G2A

BY

A

BY

A

BY

A Y

A Y

A Y

EN ACKTOP.G1

43


Reporting Power SwitchesYou need to use the command report_power_switches, to report the power switches

Leda> report_power_switches

===== Power switches =====

by cell type:

* with set_power_switch:

by instance:

Specifying Power Cell PinsThe following section describes how you can specify the power cell pins.

Specifying Pins of a Power Library Cell and their Required Voltage LevelsYou can specify the pin names and their required voltage levels for the power library cells in the following ways:

If the cell is a DB cell, Leda reads the pins defined in the DB cell as well as their predefined attributes input_signal_level and output_signal_level. These attributes reference a power rail that is defined in the same DB library, at a specific voltage level use the power_rail function. For example, input_signal_level: VDD1; and power_rail (VDD1, 1.2);.

If the cell has been defined with a Tcl command or is a DB cell, you can specify the pin names and their corresponding voltage levels with the set_pin_voltage Tcl command as follows:Leda> set_pin_voltage

Here, cell names are Verilog module/primitive names or VHDL entity names. For example:

Leda> set_pin_voltage LS12V A 1.2

Leda> set_pin_voltage LS9_12V Y 0.9

44


If the cell is a DB cell, the values set by the set_pin_voltage command supersede the values of the DB attributes input_signal_level and output_signal_level, if these attributes are defined.

Leda uses the pin names and voltage level information. For example, when checking that the pins of a level shifter or an isolation cell are connected to the correct voltage domains. For example, see rules LSPINVOLT and ICPINVOLT.

You can list all pin voltage values defined for a given cell with the report_pin_voltages Tcl command.

Leda> report_pin_voltages

For example:Leda> report_pin_voltages LS9_12V

===== Cell LS9_12V pin voltages =====

Pin A : 1.2 volt (DB)Pin Y : 0.9 volt (Tcl)Pin EN :

Specifying Power Pins in Standard CellsIf a library cell contains additional pins that are intended to be used as pg-pins, Leda cannot identify them automatically. In this case, you need to use the set_power_pin command in the Leda shell to indicate the pins. The command is used as follows:

Leda> set_power_pin -power | -gnd For example:

Leda> set_power_pin CELL VDD -power

Leda> set_power_pin "CELL" VSS -gnd

To apply on all cells, put "" as cell name. Leda> set_power_pin "" VPWR -power

Leda> set_power_pin "" VGND -gnd

For level shifters and other multi-voltage cells, you need to qualify both power pins.

Specifying Enable Pin NamesYou can specify the enable pin (one only, if any) for the power library cells in the following ways:

45


If the cell is a DB cell and if one pin of the cell has the Boolean attribute isolation_cell_enable_pin set to true, then the corresponding pin is the enable pin.

If the cell was defined with a Tcl command, you can specify the enable pin name with the set_enable_pin Tcl command as follows:Leda> set_enable_pin

Here, cell names are Verilog module/primitive names or VHDL entity names. For example:

Leda> set_enable_pin IC12V EN

The enable pin information is used to determine if a level shifter can be used as an isolation cell as well, or more generally for checks requiring the enable functionality and its corresponding pin.

You can find the enable pin for a given cell, if any, with the command report_enable_pin.

Leda> report_enable_pin

For example:Leda> report_enable_pin IC12V

Enable pin of IC12V: EN

Leda> report_enable_pin IC12VB

Enable pin of IC12VB:

Note that the enable pin can also be defined with a set_pin_voltage command. However each command has a different purpose. Command set_enable_pin defines the enable functionality of the pin, and set_pin_voltage defines the name of the pin and its voltage, regardless of its functionality.

Power ChecksThis section contains some examples of how Leda can combine power-related information from different sources (RTL, Tcl, PG-Netlist) with an extensive set of prepackaged rules to create and test a complete and coherent power environment.

46


Checking Level ShiftersThe Verilog code and Figure 10 shows a scenario, in which an extra (useless) level shifter is present on the path of a signal that is passing from module Top.A to module Top.B.

Figure 10: Extra Level Shifter in Design

T O P . A ( 1 . 2 V ) T O P . B ( 1 . 4 V )

T O P ( 1 . 2 V )

T O P . B . G 1

LS

T O P . A . G 3 T O P . L S 2TO P . B . G 2

LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . A . G 1 T O P .L S 1

T O P . A ( 1 . 2 V ) T O P . B ( 1 . 4 V )

T O P ( 1 . 2 V )

T O P . B . G 1

LS

T O P . A . G 3 T O P . L S 2TO P . B . G 2

LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . A . G 1 T O P .L S 1

47


The corresponding verilog code of Figure 9 is as follows:module A (Y1, Y2, A1, A2, A3); output Y1, Y2;

input A1, A2, A3;

wire INT;

NAND2CELL G1(Y1, A1, INT); NOTCELL G2(INT, A2); NAND2CELL G3(Y2, INT, A3);endmodule

module B (Y1, Y2, A1, A2); output Y1, Y2;

input A1, A2;

wire INT1, INT2;

NAND2CELL G1(Y1, A1, INT1); NAND2CELL G2(Y2, A2, INT2);endmodule

module TOP(Y1, Y2, A1, A2, A3); output Y1, Y2;

input A1, A2, A3;

wire INT1, INT2, INT3, INT4, INT5;

A IA(INT1, INT2, A1, A2, A3); B IB(Y1, Y2, INT4, INT5);

NOTCELL G1(INT3, INT2); LSCELL LS1(INT4, INT1); LSCELL LS2(INT5, INT3);

endmodule

48


By using the following power Tcl commands, Leda identifies the unwanted level shifter present in the circuit as shown in Figure 11:

Leda> create_power_net_info VDD12 -power -nominal_voltages {1.2} Leda> create_power_net_info VDD14 -power -nominal_voltages {1.4}Leda> create_power_domain POW12

#No cell is specified. So, power domain is associated to TOP

Leda> create_power_domain POW12A -object_list [get_cells IA] -power_downLeda> create_power_domain POW14B -object_list [get_cells IB] -power_downLeda> connect_power_domain POW12 -primary_power_net VDD12

Leda> connect_power_domain POW12A -primary_power_net VDD12

Leda> connect_power_domain POW14B -primary_power_net VDD14

Leda> check p POWER

49


Figure 11: Schematic generated in GUI for Errors

50


Checking Isolation CellsThe following example illustrates how information from RTL can be combined with information from the shell to test for missing isolation cells. In Figure 12, TOP.IC1 is an isolation cell.

Figure 12: Isolation Cell Schematic

You can tell Leda that you want TOP.IC12 to act as an isolation cell in three different ways:

By explicitly instantiating a DB cell that is an isolation cell

T O P . A TOP.B

T O P

T O P . B . G 1

T O P . A . G 3 T O P . G 2 T O P . B . G 2

T O P . A . G 2

A

BY

A

BY

A

BY

A

BY

A Y T O P . A . G 1 T O P . I C 1

A

BYIC

T O P . P D T O P . R S T

A Y

T O P . G 1T O P . A TOP.B

T O P

T O P . B . G 1

T O P . A . G 3 T O P . G 2 T O P . B . G 2

T O P . A . G 2

A

BY

A

BY

A

BY

A

BY

A Y T O P . A . G 1 T O P . I C 1

A

BYIC

A

BYIC

T O P . P D T O P . R S T

A Y

T O P . G 1

51


By writing the Verilog code for the TOP module as follows:module TOP(Y1, Y2, A1, A2, A3, PD, RST);

output Y1, Y2;

input A1, A2, A3, PD, RST;

wire INT1, INT2, INT3, INT4, INT5;

A IA(INT1, INT2, A1, A2, A3, PD); B IB(Y1, Y2, INT4, INT5);

NOR2CELL G1(INT3, PD, RST); ICCELL IC1(INT4, INT1, INT3); BUFCELL G2(INT5, INT2);endmodule

and then setting ICCELL as an isolation cell in the shell.Leda> set_isolation_cell ICCELL

By using the $isolate call and replacing the instantiation of ICCELL in the Verilog code with:$isolate(INT4, INT3, INT1,1b0);

Suppose you create the following power domain:Leda> create_power_domain POWA power_down power_down_ctrl [get_ports PD] object_list [get_cells IA]

52


You can see theres an isolation cell missing on the path containing TOP.G2. Regardless of how you inferred the isolation cells, running the following command causes the rule ICINSOUT to be flagged as follows:

Leda> check p POWER

51: wire INT1, INT2, INT3, INT4, INT5;

^

power_test_iso_noauto_missing.v:51: ISOLATION_CELLS> [ERROR] ICINSOUT: Missing isolation cell for power domain POWA: TOP.INT2

/remote/ledascratch/kobrien/kobrien_leda_dev_fr/Leda/tests/src/functional/LowPower/power_test_iso_noauto_missing/power_test_iso_noauto_missing.v:4: :Y: From pin: TOP.IA.G3.Y

/remote/ledascratch/kobrien/kobrien_leda_dev_fr/Leda/tests/src/functional/LowPower/power_test_iso_noauto_missing/power_test_iso_noauto_missing.v:16: :A: To pin: TOP.G2.A

Checking Standard CellsAs an example of how Leda checks standard cells, Figure 13 illustrates how Leda detects that the cell TOP.G1 is badly located because it is connected to the primary power net (VDD1) of power domain POWA but not contained within POWA power regions.

53


Figure 13: A Sample PG-Netlist Schematic






Leda> infer_power_domains power_nets {VDD1 VDD2}Inferring power domain PD1 from power net VDD1 ...

Error: Cell 'TOP.G1' is connected to primary power net 'VDD1' while located in power region of power domain 'POW_TOP' connected to primary power net 'VDD2'. (POW-014)Inference of power domain PD1 completed.

Inferring power domain PD2 from power net VDD2 ...

Inference of power domain PD2 completed.

T O P . A T O P . B

T O P

T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

LS


LST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1 T O P . A . G 1

T O P . A T O P . B

T O P

T O P . B . G 1

V D D 1 ( 1 . 2 V ) V D D 2 ( 1 . 4 V )

LSLS


LSLST O P . A . G 2

T O P . G 1

A

BY

A

BY

A

BY

A

BY

A Y

A Y

A Y

A Y

T O P . L S 1 T O P . A . G 1

54


Operating Environment SettingThe operating environment of a cell is a collection of all environmental factors that are needed to fully define the timing/power behavior of the cell. You can use the command set_voltage to define the operating voltage for supplied power nets.

Syntaxset_voltage [-min ] \-object_list

You need to make sure that the following conditions are met when setting the operating voltage to power nets:

The voltages set by the command set_voltage must fall within the ranges specified by the command create_power_net_info.

The command set_voltage can be applied on an internally generated power net, but value must fall within its inherited voltage ranges and less than its parent.

The operating voltage of the power net driving the design-level (top) power domain must match the operating voltage of the design level operating condition.

Relative Always on Relationship SettingYou can use the set_relative_always_on command to create relative always on relationship between power domains. This information is used to check if isolation cells are mandatory on nets crossing power domains on.

Syntaxset_relative_always_on [-relative_to \]

The significance of relative always on setting is that, even though two power domains may be shut down, and if one power domain is always on relative to the other power domain, then you dont need an isolation cell on the net crossing from the power domain that is always on, to the relative power domain.

The following example illustrates how command set_relative_always_on could be used in creating a relative always on relationship between power domains.

55


Figure 14: A Sample Schematic to Highlight Usage of set_relative_always_on

The power domains are configured as follows:Leda> create_power_domain PD

Leda> create_power_domain PDA -object_list [get_cells A] -power_downLeda> create_power_domain PDB -object_list [get_cells B] -power_down

The results for isolation cells check is listed below:

Table 2: Isolation Cells Checks without set_relative_always_on

Paths Missing Isolation CellUnnecessary Isolation

Cells

Path 1 - from A to B isolated

Path 2 - from A to B Yes

Path 3 - from B to A isolated

TOP.B

TOP

ISOEN

YA A

BY

TOP.B.G1

A

BY

TOP.B.G2

A

BY

TOP.B.G3

A

BY

TOP.B.G4

TOP.AA

BY

TOP.A.G1

A

BY

TOP.A.G2

A

BY

TOP.A.G3

A

BY

TOP.A.G4

ISOEN

AY

1)1)

2)2)

3)3)

4)4)

TOP.B

TOP

ISOEN

YA ISOEN

YA A

BY

TOP.B.G1

A

BY

TOP.B.G2

A

BY

A

BY

TOP.B.G2

A

BY

TOP.B.G3

A

BY

A

BY

TOP.B.G3

A

BY

TOP.B.G4

A

BY

A

BY

TOP.B.G4

TOP.AA

BY

TOP.A.G1

A

BY

A

BY

TOP.A.G1

A

BY

TOP.A.G2

A

BY

A

BY

TOP.A.G2

A

BY

TOP.A.G3

A

BY

A

BY

TOP.A.G3

A

BY

TOP.A.G4

A

BY

A

BY

TOP.A.G4

ISOEN

AY ISOEN

AY

1)1)

2)2)

3)3)

4)4)

56


Now, we configure that power domain PDA is always on relative to power

pol_power

Documents

design compiler

fpga compiler

hdl compiler

ecl compiler

dft compiler

eco compiler

physical compiler

behavioral compiler