SYSTEM AND METHOD FOR
`
`HIERARCHICAL POWER VERIFICATION
`
`CROSS-REFERENCE TO RELATED APPLICATION
`
`[0001]
`
`This application is a continuation of US. Application No. 14/815,302, filed July 31,
`
`2015, which claims priority under 35 U.S.C. 119(e) from prior US. provisional Application No.
`
`62/189,453, filed July 7, 2015. All of the foregoing are incorporated by reference herein in their
`
`entirety.
`
`TECHNICAL FIELD
`
`[0002]
`
`This invention relates to the field of integrated circuits verification and in particular to
`
`verification of power subsystems. More particularly the invention relates to a system, method
`
`and computer program product for efficiently verifying the power subsystems of large system-
`
`on-a-chip designs.
`
`BACKGROUND ART
`
`[0003]
`
`Low power consumption in a SoC (System on Chip) is increasingly important. SoC
`
`designs incorporate many techniques to reduce power consumption. One technique is for the
`
`designer to use multiple voltage levels, since the voltage needs to be high only for high
`
`frequency modules of the 80C, and low voltage levels reduce power consumption. Modules of a
`
`SoC that have voltages powering them that are different from the voltages powering some other
`
`module to which they are connected are called Voltage Domains. Another technique to reduce
`
`power consumption is to turn power off completely from a module during the time that it does
`
`not need to be powered. Voltage domains one or more of whose supply voltages is dynamically
`
`22524/41614/FW/10311251.1
`
`

`

`turned ON/OFF are called Power Domains. Turning power OFF completely is becoming more
`
`effective compared to clock disabling as circuit design rules shrink and the leakage current
`
`increases compared to the switching current.
`
`[0004]
`
`These modern techniques along with others create new requirements in the 80C
`
`design. Some of these requirements are:
`
`- A level shifter is needed between the output port of a module that is connected to the
`
`input port of another module whenever the two ports (that is, the logic connected to
`
`the two ports) are powered with a different voltage.
`
`- A register-state retention and restore circuit may be needed for critical registers of a
`
`module when the power to a module is removed.
`
`-
`
`Isolation circuits are needed following an output port of a module whose power is
`
`turned off (port floats) and the port is connected to an input port of a module that is
`
`powered.
`
`-
`
`Logic circuits for dynamically turning power on/off on some or all of the power ports
`
`of some or all the modules need to be added.
`
`[0005]
`
`SoC developers normally specify the power architecture (definition of voltage/power
`
`domains, use of retention registers and more) in separate files from the logic design specification.
`
`The power architecture specification is usually called the “power intent” (PI) and is expressed in
`
`languages like Unified Power Format (UPF), described in the IEEE Standard for Design and
`
`Verification of Low-Power Integrated Circuits. This IEEE standard establishes a format used to
`
`define the power intent for electronic systems and electronic intellectual property (1P). The
`
`format provides the ability to specify the power supply network, switches, isolation, retention,
`
`and other aspects relevant to power management of an electronic system. The standard defines
`
`22524/41614/FW/10311251.1
`
`

`

`the relationship between the power intent specification and the logic design specification
`
`captured via other formats (e.g., standard hardware description languages (HDLs)).
`
`[0006]
`
`A SoC may have many independent modules, each powered by multiple, different
`
`power supplies, many of which are common to more than one module. At a given time, a power
`
`supply can be turned on, turned off or be in a different state such as sleeping or idle. A power
`
`state table (PST) is a table with columns for all the voltages powering a module and rows for all
`
`the allowed combinations of power supply states.
`
`[0007]
`
`Electronic design automation (EDA) tools like Spyglass from the assignee verify the
`
`power architecture of an electronic design by comparing the power intent specification to the
`
`logic design and checking for coherence, correctness and the eXistence of necessary power-
`
`interface components.
`
`[0008]
`
`As SoC designs continue to grow in terms of complexity and number of transistors,
`
`the verification time increases and the memory requirements of the EDA tools grow. Power
`
`verification is one of the last development activities before tape-out, so SoC developers are under
`
`pressure to complete it quickly. SoC developers would benefit greatly if the verification time
`
`could be reduced from days to hours.
`
`SUTVIMARY DISCLOSURE
`
`[0009]
`
`The hierarchical power verification system (HPVS) uses abstract models to make top
`
`level power verification much more efficient and thereby reduce power verification time. The
`
`HPVS creates abstract models of power behavior of modules that it successfully verifies. The
`
`abstract models simplify the module definition by omitting internal module details but provide
`
`sufficient information for power verification of higher level modules that incorporate this
`
`22524/41614/FW/10311251.1
`
`

`

`abstracted module. After replacing modules with abstracted models the HPVS can quickly verify
`
`an entire SoC with a small memory footprint. When a user modifies a module, the HPVS need
`
`only verify the changed module and related modules at higher levels of module hierarchy.
`
`[0010]
`
`Specifically, the power verification system, comprises (a) a storage medium for
`
`receiving and storing a description of at least a portion of an electronic circuit design, and for
`
`receiving and storing a power intent file specifying a power architecture of power/voltage
`
`domains, their power supplies and any corresponding power devices of the electronic circuit
`
`design, and also for storing a report of power verification failures, (b) a processor having access
`
`to the storage medium and executing an application program for a hierarchical power verification
`
`tool that constructs, from the stored design description and power intent file, a set of abstract
`
`models of power behavior of circuit modules for use in higher level power verification of an
`
`electronic circuit design, and (c) a user interface including a computer display for displaying
`
`identified power verification failures and an input device for facilitating correction of at least one
`
`of the electronic circuit design and the power intent file.
`
`[0011]
`
`According to the power verification method, the system’s processor prepares the
`
`abstract models for each circuit module to be verified by performing in any order one or more of:
`
`(1) capture interface supplies, (2) create domains, (3) identify related supplies, (4) establish
`
`power state tables, (5) model isolation logic, (6) model level shifters, (7) model feed-through
`
`floating ports, and (8) model power switches. Design blocks are replaced with the abstract power
`
`models, resulting in reduced run-time and memory requirements. The power model may be
`
`expressed either in UPF or as a combination of liberty model and UPF. Any errors identified by
`
`the power verification are displayed on the system’s computer display, while the input device
`
`22524/41614/FW/10311251.l
`
`

`

`facilitates correction and storage of at least one of the electronic circuit design and the power
`
`intent file.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0012]
`
`FIG. 1 shows an exemplary flowchart outlining the steps for using abstract models to
`
`significantly reduce power verification time.
`
`[0013]
`
`FIG. 2 shows a simple scenario to help explain model abstraction.
`
`[0014]
`
`FIG. 3 shows a simple hierarchical module scenario to help explain model
`
`abstraction.
`
`[0015]
`
`FIG. 4 shows an exemplary module with power intent.
`
`[0016]
`
`FIG. 5 shows an exemplary flowchart outlining the steps for generating an abstract
`
`model.
`
`[0017]
`
`FIG. 6 shows an exemplary system for hierarchical power verification.
`
`DETAILED DESCRIPTION
`
`[0018]
`
`The hierarchical power verification system (HPVS) uses abstract models to
`
`significantly reduce power verification time. The HPVS creates abstract models of modules that
`
`it successfully verifies. The abstract models simplify the module definition by omitting internal
`
`module details but provide sufficient information for power verification of higher level modules
`
`that incorporate this abstracted module. After replacing modules with abstracted models the
`
`HPVS can quickly verify an entire SoC with a small memory footprint. When a user modifies a
`
`module, the HPVS need only verify the changed module and related modules at higher levels of
`
`22524/41614/FW/10311251.l
`
`

`

`module hierarchy. In contrast, existing power verification systems have to verify the entire
`
`design after a change.
`
`[0019]
`
`FIG. 1 is an exemplary and non-limiting flowchart lOO showing how the hierarchical
`
`power verification system (HPVS) uses abstract models to significantly reduce power
`
`verification time. In $1 10 the HPVS reads the design, the power intent and a list of abstracted
`
`models of design sub-modules. The user of the HPVS specifies if the HPVS should verify a
`
`complete SoC design, a module of the 80C design or a set of modules from the 80C design. The
`
`logic design is typically specified in a hardware description language such as Verilog or VHDL.
`
`The corresponding power intent is typically specified in a power specification language such as
`
`UPF.
`
`[0020]
`
`In 8120 the HPVS selects the next module to verify. In one mode of operation the
`
`HPVS selects the next module from a list specified by a user. In a second mode of operation the
`
`HPVS automatically selects a module from the specified design. In either mode the HPVS
`
`detects whether the selected module has an up-to-date abstract model. If the module has been
`
`modified after the last abstract model was generated, the HPVS will need to process the module.
`
`If the HPVS detects an up-to-date abstract model it will skip processing that module. In 8130 the
`
`HPVS checks if it has found a module to process. If the HPVS has finished processing all
`
`modules it terminates. If the HPVS find a module to process it continues at $140.
`
`[0021]
`
`In 8140 the HPVS determines if the selected module includes a module described by
`
`an abstract model. In one mode of operation the user explicitly specifies which abstract models
`
`to use for each module being checked. In a second mode of operation the HPVS automatically
`
`detects if the module includes a module described by an abstract model. The HPVS then
`
`22524/41614/FW/10311251.1
`
`

`

`performs power verification by comparing the power intent specification to the logic design and
`
`checking for coherence, correctness and the existence of necessary power-interface components.
`
`[0022]
`
`In 8150 the HPVS determines if the power verification found any errors. If the HPVS
`
`found one or more errors it proceeds to $170. If the HPVS did not find any errors it proceeds to
`
`8160. At $160 the HPVS generates an abstract model of the selected module and then proceeds
`
`to 8120. At $170 the HPVS either fixes the power verification errors or asks a user to fix the
`
`power verification errors. The HPVS proceeds at $140 to re-verify the module. In one
`
`embodiment the HPVS exits when it finds an error and the user must fix the error and restart the
`
`HPVS.
`
`[0023]
`
`FIG. 2 shows a simple scenario 200 to help explain model abstraction. The scenario
`
`gives a visual representation of the power intent. Module 202 has a power supply vddB 210 and
`
`a logic port 220 that drives internal logic 230. The power supply vddB 210 controls the internal
`
`logic 230. We say that logic port 220 has related power supply vddB 210. An abstracted model
`
`will specify the module power supplies; the logic ports and the logic ports’ related power
`
`supplies.
`
`[0024]
`
`In scenario 200 the logic port 220 could have associated isolation logic. The power
`
`intent could have either of the following UPF statements associated with logic port 220:
`
`set_isolation iso -location self
`
`-isolation_power_net VDDC
`
`set_isolation iso -location parent
`
`-isolation_power_net VDDC
`
`[0025]
`
`The first statement with “-location self’ means that an abstract model must capture
`
`the fact that the port is isolated and has internal isolation logic. The second statement with “-
`
`22524/41614/FW/10311251.l
`
`

`

`location parent” means that an abstract model must capture the fact that the port has external
`
`isolation logic.
`
`[0026]
`
`In scenario 200 the logic port 220 could have associated level-shifting logic. The
`
`power intent could have the following UPF statement associated with logic port 220:
`
`set_level_shifter ls -type low_to_high
`
`-location self -input_supply_set ssl
`
`[0027]
`
`The abstracted model must capture the level-shifting strategy and note the location of
`
`“self’ or “parent”.
`
`[0028]
`
`FIG. 3 shows a simple hierarchical module scenario 300 to help explain model
`
`abstraction. Module 302 includes module 304. Module 302 has primary power supply Vdd 311.
`
`Module 304 has primary power supply VddB 310. Thus module 304 has a different power
`
`domain compared to module 302. Logic port P 320 of module 302 connects to logic port. PB 325
`
`of module 304. Power supply port VddB 310 passes through module 302 and connects to power
`
`supply port 315 of module 304. Inside module 304 logic port PB 325 drives internal logic 330
`
`that uses power supply port 315. Module 302 has logic port P 320 with related power supply port
`
`VddB 310.
`
`[0029]
`
`In scenario 300 logic ports P 320 and PB 325 could each have associated isolation or
`
`level-shifting logic. The HPVS needs to decide to decide if the abstracted model of module 302
`
`requires isolation and/or level-shifting properties.
`
`[0030]
`
`FIG. 4 shows an exemplary module cellA 400 with power intent. Module cellA 400
`
`has 2 power supplies VddA 410 and VddB 411. Module cellA 400 has 2 ground supplies vssA
`
`420 and vssB 421.
`
`[0031]
`
`The HPVS can create abstract models in a variety of formats, including: a) as a liberty
`
`file with auxiliary information in a UPF file; and b) as a UPF 2.1 power model. We refer to the
`
`8
`
`22524/41614/FW/10311251.1
`
`

`

`UPF 2.1 model as a “full UPF” model. Liberty files are commonly used in the EDA industry to
`
`represent power and timing information of a module. In a) the liberty file is augmented with an
`
`auxiliary UPF file because the liberty file cannot represent all the needed attributes (such as
`
`Power State Tables--PSTs) for a complete abstraction of a module’s Power Intent. In b) the full
`
`UPF based abstraction provides a flexible alternative for abstraction. This is because the UPF
`
`files are command based and software like. Users can view; understand and modify UPF easily if
`
`needed.
`
`[0032]
`
`The power and ground power supplies vdda 410; vddB 411; vssA 420 and vssB 421
`
`are modeled in pg_pin statements with pg_type attribute values of primary_power and
`
`primary_ground in a liberty model; as supply sets in a full UPF power model; and as supply nets
`
`in the auxiliary UPF.
`
`[0033]
`
`Power supply port vddB 411 drives power switch psw1 440 which generates internal
`
`power supply net vddB_int 450. Power supply net vddB_int 450 is modeled as a pg_pin
`
`statement with direction internal in the liberty model; as a supply set in a full UPF power model
`
`and as supply nets in the auxiliary UPF. Power switch psw1 440 is modeled as a power switch
`
`with the same name in the UPF files. Port states are generated for the output supply port.
`
`[0034]
`
`Input logic port Y 432 controls power switch psw1 440 which generates vddB_int
`
`450. This aspect is captured in the UPF file. To model the power switch in the liberty file the
`
`HPVS does the following. The pg_pin statement for vddB_int 450 lists port Y 432 as the value
`
`of a switch_function attribute and port vddB 411 as the value of a pg_function attribute. The
`
`pg_pin statement for logic port Y 432 has attribute switch_pin with value true. Module level
`
`attribute switch_cell_type is specified in the liberty file.
`
`22524/41614/FW/10311251.1
`
`

`

`[0035]
`
`Module cell A 400 has logic ports W 430, X 431, Y 432, Z 433, Z1 434 and Z2 435.
`
`Logic ports Z 433 employs level shifter strategy is with location parent. These are represented
`
`using set_leve1_shifter statements in the UPF files. Logic port X 431 employs an isolation
`
`strategy iso with location self. This is modeled using an is_isolated attribute on pin X in the
`
`liberty file and using a set_isolation statement in the full UPF.
`
`[0036]
`
`Input logic ports W 430 and X 431 are related to power supply port VddA 410 and
`
`ground supply port vssA 420. These are modeled with the set_port_attribute statement with the
`
`“-receiver” option in the full UPF model. No information is required in the auxiliary UPF file.
`
`[0037]
`
`Input logic ports Y 432 and Z 433 are related to power supply port VddB 411 and
`
`ground supply port vssB 421. They are modeled in the same way but with different power and
`
`ground supplies.
`
`[0038]
`
`Output logic port Zl has related supplies VddB_int 450 and vssB 421. These are
`
`modeled with a set_port_attribute statement with the -driver option in the full UPF model.
`
`Output logic port Z2 has related supplies VddB 411 and vssB 421. These are also modeled with a
`
`set_port_attribute statement with the -driver option in the full UPF model.
`
`[0039]
`
`The completed abstracted models are shown below. The description of FIG. 5
`
`explains how to build each portion of the abstraction.
`
`Liberty file
`
`/* Library definition >“/
`
`library ( SpyGlass_Generated_Lib ) {
`
`/* Voltage map definition >“/
`
`voltage_map(state 1, 1.00),
`
`voltage_map(state2, 0.00),
`
`10
`
`22524/41614/FW/10311251.1
`
`

`

`/* Cell definition >“/
`
`cell (top ) {
`
`/* cell level attribute >“/
`
`is_macro_cell : true;
`
`switch_cell_type : fine_grain;
`
`/* pg_pin definition >“/
`
`pg_pin (VddA) {
`
`voltage_name : statel;
`
`pg_type : primary_power;
`
`}
`
`pg_pin (VddB ) {
`
`voltage_name : statel;
`
`pg_type : primary_power;
`
`}
`
`pgpm(va){
`
`voltage_name : state2;
`
`pg_type : primary_ground;
`
`}
`
`pgpm(V%B){
`
`voltage_name : state2;
`
`pg_type : primary_ground;
`
`}
`
`/* Output net of the power switch being modeled as internal power >“/
`
`pg_pin (VddB_int) {
`
`ll
`
`22524/41614/FW/10311251.1
`
`

`

`voltage_name : statel;
`
`pg_type : internal_power;
`
`direction : internal;
`
`pg_function : “VddB” ;
`
`switch_function : “Y”;
`
`}
`
`/* Signal pins definition >“/
`
`pin (W) {
`
`direction : input;
`
`related_power_pin : VddA;
`
`related_ground_pin : vssA;
`
`}
`
`pin (X) {
`
`direction : input;
`
`is_isolated : true; isolation_enab1e_condition : “W”;
`
`related_power_pin : VddA;
`
`related_ground_pin : vssA;
`
`}
`
`pin (Y) {
`
`direction : input;
`
`switch_pin : true;
`
`related_power_pin : VddB;
`
`related_ground_pin : vssB;
`
`}
`
`pin (Z ) {
`
`direction : input;
`
`related_power_pin : VddB;
`
`12
`
`22524/41614/FW/10311251.1
`
`

`

`related_ground_pin : vssB;
`
`}
`
`pin (Zl ) {
`
`direction : output;
`
`related_power_pin : VddB_int;
`
`related_ground_pin : vssB;
`
`}
`
`pin (ZZ ) {
`
`direction : output;
`
`related_power_pin : VddB;
`
`related_ground_pin : vssB;
`
`} } }
`
`[0040]
`
`The corresponding auxiliary UPF file generated is as follows:
`
`upf_version 1.0
`
`#Domain creation
`
`create_power_domain PD -include_scope
`
`#Supply net and port creation
`
`create_supply_port VddA
`
`create_supply_net VddA -domain PD
`
`connect_supply_net VddA -ports VddA
`
`add_port_state VddA -state {off off}
`
`add_port_state VddA -state {on 1.00}
`
`create_supply_port VddB
`
`l3
`
`22524/41614/FW/10311251.1
`
`

`

`create_supp1y_net VddB -domain PD
`
`connect_supp1y_net VddB -ports VddB
`
`add_port_state VddB -state {off off}
`
`add_port_state VddB -state {on 1.00}
`
`create_supp1y_port vssA
`
`create_supp1y_net vssA -domain PD
`
`connect_supp1y_net vssA -ports vssA
`
`add_port_state vssA -state {on 0.00}
`
`create_supp1y_port vssB
`
`create_supp1y_net vssB -domain PD
`
`connect_supp1y_net vssB -ports vssB
`
`add_port_state vssB -state {on 0.00}
`
`create_supp1y_net VddB_int
`
`#Domain primary supply definition
`
`set_domain_supp1y_net PD \
`
`-primary_power_net VddB \
`
`-primary_ground_net vssB
`
`#Level shifter strategy definition
`
`set_1eve1_shifter1s -domain PD -ru1e low_to_high
`
`-location parent -e1ements { Z }
`
`#Power switch modelling
`
`create_power_switch psw -domain PD
`
`-output_supp1y_port { VddB_int VddB_int }
`
`-input_supp1y_port { VddB VddB }
`
`-control_port { Y Y }
`
`14
`
`22524/41614/FW/10311251.1
`
`

`

`add_port_state psw/VddB_int -state {off off}
`
`add_port_state psw/VddB_int -state {on 1.00}
`
`#Power State definition
`
`create_pst pst -supp1ies { VddA VddB vssA vssB VddB_int }
`
`add_pst_state sl -pst pst -state {off off on on off}
`
`add_pst_state $2 -pst pst -state {on off on on off}
`
`add_pst_state s3 -pst pst -state {on on on on off}
`
`add_pst_state s4 -pst pst -state {on on on on on}
`
`[0041]
`
`The full UPF will be as follows:
`
`upf_version 2.1
`
`begin_power_mode1 upf_top -for { top }
`
`#Supply net and port creation
`
`create_supp1y_port VddA
`
`create_supp1y_net VddA
`
`connect_supp1y_net VddA -ports VddA
`
`add_port_state VddA -state {off off}
`
`add_port_state VddA -state {on 1.00}
`
`create_supp1y_port VddB
`
`create_supp1y_net VddB
`
`connect_supp1y_net VddB -ports VddB
`
`add_port_state VddB -state {off off}
`
`add_port_state VddB -state {on 1.00}
`
`create_supp1y_port vssA
`
`create_supp1y_net vssA
`
`connect_supp1y_net vssA -ports vssA
`
`add_port_state vssA -state {on 0.00}
`
`15
`
`22524/41614/FW/10311251.1
`
`

`

`create_supp1y_port vssB
`
`create_supp1y_net vssB
`
`connect_supp1y_net vssB -ports vssB
`
`add_port_state vssB -state {on 0.00}
`
`create_supp1y_net VddB_int
`
`#Supply set creation
`
`create_supp1y_set ssl -function { ground vssA }
`
`-function { power VddA }
`
`create_supp1y_set 532 -function { ground vssB }
`
`-function { power VddB }
`
`create _supp1y_set SS3 -function { ground vssB }
`
`-function { power VddB_int }
`
`#Power domain creation
`
`create_power_domain PD_top -inc1ude_scope\
`
`-supp1y { ssh_l ssl } \
`
`-supp1y { primary ssZ } \
`
`-supp1y { ssh_3 ss3 }
`
`#Adding port attributes
`
`set_port_attributes -ports { Y Z }
`
`-receiver_supp1y PD_topprimary
`
`set_port_attributes -ports { W X }
`
`-receiver_supp1y PD_top. ssh_l
`
`set_port_attributes -ports { ZZ }
`
`-driver_supp1y PD_topprimary
`
`set_port_attributes -ports { Zl }
`
`-driver_supp1y PD_top.ssh_3
`
`16
`
`22524/41614/FW/10311251.1
`
`

`

`#Isolation strategy
`
`set_isolation iso -domain PD_top -elements {X}
`
`-isolation_supply_set ssl -isolation_signal W
`
`-clamp_value O -isolation_sense low -location self
`
`#Level shifter strategy
`
`set_level_shifter ls -domain PD_top
`
`-rule low_to_high -location parent -elements { Z }
`
`#Power switch modelling
`
`create_power_switch psw -domain PD_top
`
`-output_supply_port { VddB_int VddB_int }
`
`-input_supply_port { VddB VddB }
`
`-control_port { Y Y }
`
`add_port_state psw/VddB_int -state {off off}
`
`add_port_state psw/VddB_int -state {on 1.00}
`
`#Power State definition
`
`create_pst pst -supplies { VddA VddB vssA vssB VddB_int }
`
`add_pst_state sl -pst pst -state {off off on on off}
`
`add_pst_state s2 -pst pst -state {on off on on off}
`
`add_pst_state s3 -pst pst -state {on on on on off}
`
`add_pst_state s4 -pst pst -state {on on on on on}
`
`end_power_model
`
`[0042]
`
`FIG. 5 shows an exemplary flowchart 500 outlining the steps for generating an
`
`abstract model. These steps can be performed in a different order to those shown in flowchart
`
`500. In SS 10 the HPVS reads the design, the power intent and any related abstract models.
`
`[0043]
`
`In 8520 the HPVS captures the interface supplies as follows:
`
`17
`
`22524/41614/FW/10311251.1
`
`

`

`[0044]
`
`1. For each supply net connected to a top level supply port specified in the UPF or in
`
`the design, create a corresponding pg_pin statement in the liberty file and a create_supply_port
`
`statement in the UPF with the same name as that of the connected supply net.
`
`#liberty file
`
`pg_pin (vddA) {
`
`voltage_name : statel;
`
`pg_type : primary_power;
`
`} #
`
`UPF create_supply_port vddA
`
`[0045]
`
`2. Generate port states (using the add_port_state statement) for each modeled supply
`
`port mentioned in the input UPF.
`
`#UPF
`
`add_port_state vddA -state {off off}
`
`add_port_state vddA -state {on 1.00}
`
`[0046]
`
`3. For every modeled supply port create a supply net with the same name and add a
`
`connect_supply_net statement for the corresponding port and net pair.
`
`#UPF
`
`create_supply_net vddA
`
`connect_supply_net vddA -ports vddA
`
`[0047]
`
`4. For the liberty+AuXiliary UPF Flow: Generate voltage_map statements for every
`
`unique non-off port state. Each pg_pin statement (shown in step 1 above) will have a
`
`voltage_name attribute set to one of the voltage_map values that corresponds to the voltage
`
`specified in the UPF.
`
`#liberty
`
`voltage_map(state l, 1.00);
`
`voltage_map(state2, 0.00);
`
`18
`
`22524/41614/FW/10311251.1
`
`

`

`In the auxiliary UPF, add -domain field for the supply net statements ‘create_supply_net‘ (for
`
`compatibility with UPF 1.0).
`
`#AuX UPF
`
`create_supply_net VddA -domain PD
`
`[0048]
`
`5. For full UPF flow: Add supply set for combinations of power and ground supplies
`
`that are inferred as related supplies of signal pins.
`
`#Full UPF
`
`create_supply_set ssl -function { ground vssA }
`
`-function { power VddA }
`
`create_supply_set ss2 -function { ground vssB }
`
`-function { power VddB }
`
`create_supply_set ss3 -function { ground vssB }
`
`-function { power VddB_int }
`
`[0049]
`
`In 8530 the HPVS creates power domains as follows:
`
`[0050]
`
`l. The HPVS creates one domain in the UPF corresponding to the top domain in the
`
`input UPF.
`
`#AuX UPF
`
`create_power_domain PD -include_scope
`
`[0051]
`
`2.
`
`In the auxiliary UPF, the HPVS generates a set_domain_supply_net statement.
`
`#AuX UPF
`
`set_domain_supply_net PD \
`
`-primary_power_net VddB \
`
`-primary_ground_net vssB
`
`[0052]
`
`3.
`
`In the full UPF, the HPVS creates a supply set with the power and ground handles
`
`and adds the -supply attribute with primary handle in the create_power_domain statement.
`
`19
`
`22524/41614/FW/10311251.1
`
`

`

`#Full UPF
`
`create_power_domain PD_top -include_scope\
`
`-supply { ssh_l ssl } \
`
`-supply { primary ss2 } \
`
`-supply { ssh_3 ss3 }
`
`In all cases, the primary power and primary ground supplies of the domain will be the same as
`
`those provided in the input UPF.
`
`[0053]
`
`In 8540 the HPVS identifies each top level interface port’s “related supplies” using
`
`the steps below. The first three steps identify the “related supplies” of logic ports, while the last
`
`two steps codify the information in the full UPF file:
`
`[0054]
`
`l. The HPVS does a depth first traversal from the top level interface port, skipping
`
`all the nested domain boundary ports that do not have a level shifter strategy specified.
`
`[0055]
`
`2. If the destination is a leaf cell, the HPVS sets the related supplies (power and
`
`ground) of the top level interface port to be the supply powering the leaf level destination logic.
`
`[0056]
`
`3. If the destination is a nested domain boundary port (having a level shifter strategy)
`
`then the related supplies are the input supplies of the level shifter on the input side and output
`
`supplies of the level shifter on the output side. For a top level interface port with level shifter
`
`strategy, the “related supplies” will be same as in Step 2.
`
`[0057]
`
`4. In the liberty file, the HPVS sets the related_power_pin and related_ground_pin
`
`based on these related supplies. No information need be added to the auxiliary UPF.
`
`#liberty
`
`pin (W) {
`
`direction : input,
`
`related_power_pin : vddA,
`
`related_ground_pin : vssA,
`
`}
`
`20
`
`22524/41614/FW/10311251.1
`
`

`

`[0058]
`
`5.
`
`In the full UPF, the HPVS adds create_supply_set statements for each of these
`
`related supplies and sets the driver/receiver supply of the ports to the respective supply set.
`
`#full UPF
`
`set_port_attributes -ports { Y Z }
`
`-receiver_supply PD_top.primary
`
`set_port_attributes -ports { W X }
`
`-receiver_supply PD_top. ssh_l
`
`set_port_attributes -ports { ZZ }
`
`-driver_supply PD_top.primary
`
`set_port_attributes -ports { Zl }
`
`-driver_supply PD_top.ssh_3
`
`[0059]
`
`In S550 the HPVS establishes the PST including supply port states. The HPVS
`
`generates a merged PST for the complete module. The generated PST only contains the supplies
`
`generated during identification of related supplies for the design pins.
`
`#UPF
`
`create_pst pst -supplies { VddA VddB vssA vssB VddB_int }
`
`add_pst_state sl -pst pst -state {off off on on off}
`
`add_pst_state s2 -pst pst -state {on off on on off}
`
`add_pst_state s3 -pst pst -state {on on on on off}
`
`add_pst_state s4 -pst pst -state {on on on on on}
`
`[0060]
`
`In S560 the HPVS handles isolation logic for each logic port. Isolation logic is
`
`modeled in the liberty file using the is_isolated attribute while the UPF requires isolation
`
`strategies. The HPVS uses the following steps to generate UPF:
`
`[0061]
`
`1.
`
`If an isolation strategy is specified on the top-level interface port with location as
`
`parent, then add a corresponding isolation strategy in the UPF file (both am: and full).
`
`21
`
`22524/41614/FW/10311251.1
`
`

`

`[0062]
`
`2. If an isolation strategy is specified on the top-level interface port with location as
`
`self then add a corresponding isolation strategy in the Full UPF file only.
`
`[0063]
`
`3. For any isolation strategy on a nested domain boundary port; there is no need to
`
`add strategy in the UPF files. They will be represented by is_isolated attribute in the LIB file
`
`[0064]
`
`The HPVS uses the following steps to generate is_isolated in liberty file:
`
`[0065]
`
`1. Do a depth first traversal from the top-level interface port; skipping every nested
`
`domain boundary port that does not have either isolation or level shifter strategy specified.
`
`[0066]
`
`2. If a nested domain boundary port is found with a level shifter strategy then stop
`
`and move onto the next logic port.
`
`[0067]
`
`3. If a nested domain boundary port with isolation strategy specified is found, then set
`
`the is_isolated attribute for the pin to true. For this pin also set the isolation_enable_condition to
`
`the resolved isolation_signal attribute of set_isolation statement.
`
`#liberty
`
`pin (X) {
`
`direction : input;
`
`is_isolated : true;
`
`isolation_enable_condition : “W”;
`
`related_power_pin : vddA;
`
`related_ground_pin : vssA;
`
`}
`
`[0068]
`
`In 8570 the HPVS handles level shifter logic for each logic port. If a level shifter
`
`strategy is specified on the top-level interface port then add a corresponding strategy in the UPF
`
`file (both am: and full) using the set_level_shifter statement. If there is any strategy on a nested
`
`domain boundary port; then the HPVS does not have to add those in the UPF file as they will be
`
`handled using related_power_pin and related_ground_pin attributes of the pin statement.
`
`22
`
`22524/41614/FW/10311251.1
`
`

`

`#Full UPF
`
`set_level_shifter ls -domain PD_top
`
`-rule low_to_high -location parent \
`
`-elements { Z }
`
`#Aux UPF
`
`set_level_shifter ls -domain PD -rule low_to_high
`
`-location parent \
`
`-elements { Z }
`
`[0069]
`
`In 8580 the HPVF handles feed-through and floating ports by processing each logic
`
`port. The HPVS uses the following steps to handle feed-through:
`
`[0070]
`
`1. For a top-level interface output port, do a backward depth first traversal, skipping
`
`nested domain boundary ports that do not have an isolation/level shifter strategy.
`
`[0071]
`
`2. If the destination is not an interface input port, then do nothing and move onto the
`
`next logic port.
`
`[0072]
`
`3. If destination is an interface input port, and an isolation/level-shifter strategy is
`
`specified on any of the ports, then do nothing and move onto the next logic port.
`
`[0073]
`
`4. Set the attribute “function” to the name of the interface input port with polarity
`
`determined by counting inverters in the path. In the full UPF add set_port_attributes {input-port
`
`output-port}-feedthrough for the interface input and output ports.
`
`#liberty (not from the above example)
`
`pin (Z1 ) {
`
`direction : output; related_power_pin : vddA;
`
`related_ground_pin : vssA;
`
`function : W;
`
`}
`
`23
`
`22524/41614/FW/10311251.1
`
`

`

`If a port is not connected to a net (i.e., it is floating), then create a corresponding pin and set the
`
`related supplies to the primary supply of the domain.
`
`[0074]
`
`In 8590 the HPVS handles Power switches. If the related supply of an interface port
`
`that the HPVS inferred is the output supply of a power switch, then the HPVS models that power
`
`switch. For the liberty model, the HPVS uses the following steps:
`
`[0075]
`
`1.
`
`In the pg_pin statement corresponding to the output of the power switch, set the
`
`pg_function to the name of the pg_pin corresponding to the input supply net.
`
`[0076]
`
`2. Set the direction of this pg_pin to internal and pg_type as internal power.
`
`[0077]
`
`3. Set the switch_function attribute of this pg_pin to the pin name which is driVing the
`
`pin specified in the control_port attribute of the corresponding create_power_switch statement.
`
`[0078]
`
`4. For the pin that is driVi