upf-based static low-power verification in complex power structure soc design using vclp

1

UPF-Based Static Low-Power Verification in Complex

Power Structure SoC Design Using VCLP

Liu Shaotao

Debajani Majhi

Broadcom

Irvine, US

www.broadcom.com

ABSTRACT

This paper presents UPF-based static low-power verification flow in complex power structure

SoC design using VCLP. It describes the current challenges in chip-level low-power verification

and UPF file techniques to reduce UPF complexity while performing more efficient verification.

This paper also demonstrates the static low-power verification on our current SoC projects using

VCLP. It shows that VCLP is able to handle a large design database while consuming less run-

time and machine usage when compared with other tools. This paper also discusses aspects of

VCLP that could be improved in the future.

SNUG 2015 2 UPF-Based Static Low-Power Verification in Complex Power

Structure SoC Designs Using VCLP

Table of Contents

1. Introduction ........................................................................................................................... 4

2. Complex power structure and the challenges in static low-power verification .................... 4 2.1 SoC power structure overview .............................................................................................. 4 2.2 Challenges in static low-power verification .......................................................................... 5

3. UPF coding techniques to reduce complexity ...................................................................... 8

3.1 UPF file structure................................................................................................................... 8 3.2 Chip power states management ............................................................................................. 9 3.3 Merging analog internal power pins ...................................................................................... 9 3.4 Use a black box model when necessary .............................................................................. 10

4. Static low-power verification signoff using VCLP ............................................................ 10 4.1 VCLP design flow ............................................................................................................... 10 4.2 Resource usage comparison ................................................................................................. 11

4.3 UPF check............................................................................................................................ 12 4.4 Gray cloud leakage analysis ................................................................................................ 13

4.5 Schematic debugging ........................................................................................................... 14 4.6 Results database management ............................................................................................. 14 4.7 Design violations found by VCLP....................................................................................... 15

5. VCLP Limitations and future enhancement ....................................................................... 16 5.1 Domain Boundary recognition ............................................................................................ 16

5.2 Equivalent supply net merging ............................................................................................ 17 5.3 Power state table merging.................................................................................................... 18

5.4 UPF2.1 support .................................................................................................................... 19

6. Conclusions ......................................................................................................................... 19

7. References ........................................................................................................................... 19



Table of Figures

Figure 1: SoC power architecture 5

Figure 2: Analog macro's power architecture 6

Figure 3: IO supply connections 7

Figure 4: Buffers placed in third domain 7

Figure 5 Virtual nets for analog macro's internal power 10

Figure 6 VCLP design flow 11

Figure 7: VCLP runtime comparison 12

Figure 8: VCLP memory usage comparison 12

Figure 9: VCLP errors for buffers in third domain 13

Figure 10: VCLP schematic debugging 14

Figure 11: Domain-based boundary recognition 16

Figure 12: Supply-set-based boundary recognition 17

Figure 13: Supply connections in package 17

Figure 14: Blocks with internal switch supplies 18

Table of Tables

Table 1: Violations found by VCLP ............................................................................................. 15

Table 2: System power state tables created by VCLP .................................................................. 19

Table 3: Most efficient power state tables .................................................................................... 19



1. Introduction

In the last couple of years, saving power has become one of the biggest challenges of the

semiconductor industry. To improve power saving, different low-power techniques such as

multi-voltage, power gating, DVFS, etc. are deployed. Static low-power verification has been

developed to verify that low-power architectures are designed and implemented using the correct

approach and meeting all the electrical rules in the SoC. The Unified Power Format (UPF) is the

standardized format that can be used throughout the entire design flow to ensure that the power

architecture specification is intact.

This paper describes UPF power-intent-based static low-power verification for complex low-

power architecture, multimillion-instance SoC. This paper first describes the complex power

structure in our design database and the challenges of building a UPF file for static low-power

verification. This paper then describes UPF coding techniques that perform static low-power

verification in the most efficient way. Thirdly, this paper presents our experience using VCLP to

sign off on 28 nm multimillion-instance SoC design projects. This paper also discusses the

current limitations and future enhancements that VCLP could improve for complex low-power

verification.

2. Complex power structure and the challenges in static low-power

verification

2.1 SoC power structure overview

The SoC design project is a 28 nm technology flip-chip design with more than 20 million

instances. It consists of multiple subblocks and hard analog IPs, both at the chip-level and

subblock level. Figure 1 describes the power architecture in brief. It consists of three main power

domains, PD_1, PD_2 and PD_3. Each power domain consists of few subblocks and analog

macros. All the subblocks use the primary power supplies in each domain. However, most of the

analog macros have their own I/O designs and their power/ground ports are individual ports at

the top level, which will be connected directly to the package. Overall, design has more than 30

subblocks and more than 20 analog macros inside, which results in more than 200 power/ground

ports at the top-level.

The design requires level shifter cells or isolation cells for each crossing between PD_1, PD_2,

and PD_3. As each analog macro may have multiple supplies, level-shifter cells are required at

the analog macros input/output pins whenever there is a voltage crossing. In addition, isolation

cells are required for the analog IP that are powered by switched internal power supply. In order

to accommodate above requirements, each analog macro need to be modeled as individual power

island. Their interface should be properly taken care to meet all low-power design rules.



Figure 1: SoC power architecture

2.2 Challenges in static low-power verification

Due to the complexity of the supply network in the chip design and the power architecture of the

analog IPs, the work of building a UPF power intent that describes all the cases and at the same

time can perform static low-power verification with 100% coverage in the most efficient way is

challenging. This session discuss all the challenges we have been through.

2.2.1 Building the chip UPF file

In order to perform the proper low-power checks with physical netlists, the UPF file should

contain all the supply connectivity, power states for each power ports, power state tables, low-

power strategies, etc. For a design with more than 200 power/ground supplies, it is very difficult

to create all the UPF statements and maintain the consistency between power-state table entries

and power port entries. Each inconsistency between them will result in UPF fatal errors that

prevent the verification from proceeding further. In addition, when building power state tables, it

is critical and tedious to group all the supplies into different groups and create different power

modes for low-power verification. Each supply must be at the desired supply states in the power

state table in order to perform proper low-power verification. Incorrect power states or missing

power states will lead to incomplete verifications.



2.2.2 Internal power-pin-inside analog macro

Many analog macros have internal voltage regulator to provide an internal power supply for their

logic. Some of the interface logic are powered by these internal power nets (Figure 2). In the

liberty files, “related_power/ground_pin” attributes are used to define the related internal power

nets (e.g. pin_A in Figure 2). It is necessary that all these internal power supplies be modeled in

the UPF files so the tool can know the power states of their related data pins. In some cases,

analog macros may have more than one internal supply listed in their liberty files. In our design

we have over 20 analog macros, and managing all the internal powers of the analog macros and

adding them to the power stable table is a major challenge.

Figure 2: Analog macro's power architecture

2.2.3 Power net driven by macros

In our design, there are also power nets driven by the macro’s output pin. Most of these cases

occur in the I/O pad region, which has the power pad’s output driving the rest of the signal I/O

pads (Figure 3). In the I/O’s liberty file, there are no attributes telling the tool that the output pin

is actually a feed-through pin from the input power pin and that all the supply nets are driven by

the pad’s output and become internal power supplies. They should be added to and properly

managed in the UPF files so that the signal I/Os can be properly verified during low-power

verification.



Figure 3: IO supply connections

2.2.4 Buffer insertions in timing ECOs

During timing ECOs, lots of buffers will be inserted to fix setup/hold timing violations.

However, the PNR tool does not handle the power-domain-aware placement very well. There are

many cases where buffers are placed in the wrong domain during ECO fixes (Figure 4). It is

critical to find all these cells early and place them in the correct power domain before moving on

to the next ECO loop. During ECO implementations in the Backend, sometimes there are more

than 20 back-to-back buffers in the data path placed in the wrong domain. It is also very

dangerous to fix the domain crossing at the starting and ending points to “fix the violations.”

These incorrect fixes can result in failures in the silicon. One way to address this issue is to run

power-aware Formality checks to find all these buffers, but it is not the most efficient approach,

as the failures in Formality could be due to many other reasons. The need to find the most

efficient method of discovering these kinds of issues is critical and strongly recommended.

VCLP has the ability to find these violations and enables us to fix them at an early stage.

Figure 4: Buffers placed in third domain



2.2.5 Large-design database handling

For some large designs that have more than 20 million instances, the ability to handle the design

database with limited resources and deliver results in time is very important. We have had

experiences during verification of the tool taking too much memory (more than 100G) when

reading in the design database. We also have seen the tool running for 24 hours and still not

finishing. There is no clue whether the verification is still ongoing or it has hung somewhere due

to improper settings in the UPF file or design database. Debugging these issues is tedious and

time-consuming. For the case of a large-design database, it is important to write the most

efficient UPF file and read in the design database in a smart way. For example, in one of the

cases we spent two days debugging a VCLP hang issue. In the end, we found the problem was

due to too many power state tables after reading in a subblock’s UPF files. More than 500 system

power states were created by the tool, which resulted in extremely long run times and large

memory consumption. In the end, the problem was solved by creating all the power state tables

in the top-level UPF file and omitting the subblock’s power state table. (See session 3.2)

2.2.6 Subblock power-intent files

A chip is designed and built in a hierarchical approach. Each subblock only has a single domain.

For those blocks with embedded macros, however, subblock UPF files are created to describe the

power architecture of the analog macros and define the low-power rules between the analog

macro’s interfaces with digital logic inside the blocks. In the chip-level verification, it is

necessary to load the subblock’s UPF file and leverage the information already there. When the

top UPF file loads multiple subblock UPF files, one of the challenges is the power state table

merging between the top and lower levels. How should they be merged without creating

redundant system power states and also without losing any useful power states? It is still an open

question.

3. UPF coding techniques to reduce complexity

3.1 UPF file structure

With more than 200 power/ground supplies and multiple internal power nets in the design

database, the UPF is written in different sessions to improve readability and manageability. The

top UPF file contains UPF commands such as “create_power_domain,” “set_domain_supply,”

and all other commands like the subblock’s UPF file loading, supply network creation, and

writing power state tables in a separate file and loading them in the top UPF file.



The following session describes the top-level structures that were used in the design:

#Top level power domain

create_power_domain PD_VDD

#Load the block level upf files

source upf_chip/<design_name>.read.block.upf

#PG ports declaration and PG connections

source upf_chip/<design_name>.connection.upf

#Analog macros internal PG connections

source upf_chip/<design_name>.macros.connetion.upf

#Low power block PG connections

source upf_chip/<design_name>.lp.blk.connection.upf

#Setting related power nets for top level ports

source upf_chip/<design_name>.top.level.ports.upf

#Setting Primary supply nets for power-domains

set_domain_supply_net PD_VDD -primary_power_net VDD -primary_ground_net

VSS

#Power state table

source upf_chip/<design_name>.pst.upf

#ISO/LS rules

source upf_chip/<design_name>.lp.rules.upf

3.2 Chip power states management

To avoid redundant system power states when loading different subblock UPF files, the power

state table in each block’s UPF file is not read in. For those power/ground supplies in the block,

they will follow the corresponding supply’s states in the top-level UPF file. For those internal

power nets inside the embedded macros, virtual power nets are created at the top level and

connected to these internal power nets (Figure 5). Therefore, all the internal power pins will

follow the power states of the virtual power nets in the power state tables.

3.3 Merging analog internal power pins

In the SoC projects, there are more than 20 analog macros presents and some of them have more

than one internal power inside the corresponding liberty files. As a result, tens of virtual nets

need to be created for each internal power pin and added to the power state tables, which already

have more than 200 entries inside. In order to keep the power state entries as small as possible, a

shared virtual power net (Figure 5) is created for analog macros that do not have logic

interactions. Therefore, the power state tables would be reduced while verification quality is not

downgraded.



Figure 5 Virtual nets for analog macro's internal power

3.4 Use a black box model when necessary

When dealing with a design that has more than 20 million instances, the run-time and machine

requirements are significantly larger than those for a smaller design database. However, it is very

common that many subblocks have only one power domain. For those subblocks that are pure

digital blocks with a single power supply, it is not necessary to read in the flattened netlist since

there is no low-power implementation inside these blocks. Instead, reading their liberty files

would greatly help in reducing machine and run-time requirements.

4. Static low-power verification signoff using VCLP

4.1 VCLP design flow

We are currently using a golden UPF design flow, in which golden UPF is delivered together

with RTL. The UPF file is used in various stages in the design flow; synthesis, PNR and static

low-power checks (Figure 6). Before synthesis, a “UPF check” is performed with RTL to ensure

UPF quality. It is then passed to the synthesis stage for low-power synthesis using Design

Compiler. Design Compiler will write all other low-power information into the supplemental

UPF file. Both the golden UPF file and the supplemental UPF file are used to perform the “UPF

check” and “Design check” using VCLP to check low-power cell insertions during synthesis.

Then they are passed to PNR together with a synthesized netlist. After PNR, “UPF check”,

“Design check” and “PG check” are performed using both UPF files and the physical netlist as

the sign-off for a static low-power check.



Figure 6 VCLP design flow

4.2 Resource usage comparison

For the large design database, using VCLP and UPF power-intent files has signification benefits

compared with other solutions, in terms of run time and machine requirement. It allows us to

reduce the turnover time while using the small machine for full-chip static verification. The full-

chip static low-power verification run time is reduced to approximately two hours from more

than eight hours, a 75% reduction (Figure 7). The memory requirement is reduced to 30G from

more than 60G, a 50% reduction (Figure 8).



Figure 7: VCLP runtime comparison

Figure 8: VCLP memory usage comparison

4.3 UPF check

When writing large UPF files with more than 200 power/ground ports in the design, it is very

important to provide a qualified UPF file to avoid unwanted violations being reported in later

stages. VCLP provides the feasibility to check the UPF files before proceeding further. VCLP’s

“check_upf ” is one of the compulsory stages in the flow and helps identify UPF defects like

missing connected supply pins, power state table inconsistency with the supply nets, the final

merge of power state table, etc. It can finish all the UPF-related check within five minutes and it

provides a way to clean up the UPF power-intent file before moving forward. It’s highly

recommended that we always run check_upf in VCLP before going through implementation to

avoid synthesizing/placing a bad design.



4.4 Gray cloud leakage analysis

The gray cloud leakage analysis feature is very useful in identifying issues in the timing ECOs

where buffers are inserted in the third domain. For those buffers/inverters that are placed in a

switched-power domain, the original path is broken when the switched domain is off. When

enabling gray cloud analysis in VCLP, the tool will find all the buffers placed in the third domain

and report “RAIL_BUFINV_STATE” violations on them (Figure 9). With these checks, we can

route this information to the layout owner and leave it to them to place the chain of buffers in the

correct power domain in time and without involving low-power-aware Formality. Here are

violations caught in our design, showing that the buffer chain from “BUF_inst_1” to

“BUF_inst_4” are placed in switched domain, while both the source and sink are in the AON

domain:

Tag : RAIL_BUFINV_STATE

Description : Supply off for buffer/inverter [Instance], but sink

[LogicSink] supplies on

Violation : LP:3446

Instance : BUF_inst_4

Cell : M10S31_BUFX4

CellPin : o

EndOfChain : BUF_inst_1/o

LengthOfChain : 1

LogicSource

PinName : AON_reg_387/q

LogicSink : AON_phy_top_inst/i_standby

Figure 9: VCLP errors for buffers in third domain



4.5 Schematic debugging

The schematic debugging interface (shown in Figure 10) in VCLP is very user-friendly and

helpful. Users can trace the driver/load information when violations show up at the domain

boundary. In addition, all the low-power related information (for instance, port and pin) are

shown in the interface. Users can easily discover the root cause of violations by looking at the

low-power properties shown in the interface. Figure 10 is one example of the VCLP schematic

debugging interface. The connectivity information is shown on the right side, while the left side

shows the low-power properties of current selected pin.

Figure 10: VCLP schematic debugging

4.6 Results database management

VCLP provides very good and easy-to-read report files. It generates both a management

summary and a tree summary. In the management summary, it shows the result summary

according to checking stages. In the tree summary, it shows the results summary according to

level of severity. In both summary reports, it not only shows the number of violations that exists

in the design, but also shows the number of violations that have been waived by user. Here is one

example for the summary report file:



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

Management Summary

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

Stage Family Errors Warnings Infos Waived

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

UPF Isolation 4 0 0 6

UPF UpfConsistency 0 2 0 3

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

Total 4 2 0 9

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

Tree Summary

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

Severity Stage Tag Count Waived

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

error UPF ISO_STRATEGY_MISSING 4 6

warning UPF UPF_CSN_MACRO 2 3

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

Total 6 9

4.7 Design violations found by VCLP

In the complex power structure SoC design, low-power violations may come from various

sources, such as manual fixes in the ECO, PG reconnection in PNR, imperfect low-power

synthesis, etc. We have used VCLP to sign off multiple projects and it helps us to identify the

low-power violations in RTL, logic netlist, and physical netlist. Table 1 lists the different

categories of violations caught by VCLP in our designs.

Violation

Source Violation Category Description

RTL Data pin tied to

wrong power

RTL connects 1.0V data pin to 1.5V power supply.

Synthsis

Missing ISO cells Synthesis miss adding ISO cells; or analog IP update in ECO

stage and new pins need to be isolated.

Missing level

shifter cells

Synthesis miss adding level shifter cells; or analog IP update in

ECO stage and new pins need to be isolated.

PNR

Wrong PG

connections

PNR tool reconnects PG pins to other power supplies.

Buffers placed in

third domain

PNR tool places AON buffers into swiched domain in timing

ECO.

Back-to-back level

shifter cells

Block level already has level shifter cells, top level insert

redundant level shifters in ECO.

Wrong ISO control Isolation control pin is reconnected in ECO.

Table 1: Violations found by VCLP



5. VCLP Limitations and future enhancement

Overall, VCLP has provided a much more efficient way for static low-power verification using

UPF format with the current features. However, there are still a few aspects with which VCLP

could better help us. This session describes some of the unsolved challenges ahead and how

VCLP could be improved in future releases.

5.1 Domain Boundary recognition

Currently, VCLP derives the domain boundary based on power domains. It does not support

domain boundary recognition for those crossing in the same power domain but only with

different supply sets. In the case of a large-design database with many power/ground supplies

and multiple analog IP, multiple power domains need to be created for analog instances so that

low-power strategies can be applied at their interfaces. This increases the complexity of the UPF

file and increases the possibility of user errors. If VCLP could support a supply-set-based

method to recognize domain boundaries, only one power domain would need to be created for

the entire design and all the low-power information would be traced by their corresponding

supplies instead of by user-created power domains. The following two figures elaborate on both

methodologies.

Figure 11: Domain-based boundary recognition



Figure 12: Supply-set-based boundary recognition

5.2 Equivalent supply net merging

Another approach to simplify the UPF file is to merge all the equivalent supply nets. In our flip-

chip designs, there are more than 100 ground ports and they are added to the power state table as

individual ground nets. However, all the 100 ground ports are connected to the same ground nets

in the package design (Figure 13), which means they are actually the same ground net in the

chip. If all of them could be merged to a signal net, and all their states is represented by a single

entry in the power state table, the UPF file would be much simpler and easier to manage by

users.

Figure 13: Supply connections in package



5.3 Power state table merging

In the hierarchical design, the subblock’s UPF file will be read in. One of the current drawbacks

is that the tool will treat each subblock’s power states as an independent supply and will create

redundant system power states, which leads to extra run time and resource usage. Figure 14

describes the current methodology

VDD is the common supply for both Block_A and Block_B.

Int_VDD is the internal supply inside each block, which is derived from VDD.

In both blocks, Int_VDD can be switched off independently.

There are no logic interactions between Int_VDD inside each block.

When both subblocks’ UPF files are loaded, the system power state tables are created in such

way as to cover all the possible cases:

(block_A/Int_VDD@on, block_A/Int_VDD @on)

(block_A/Int_VDD@on, block_A/Int_VDD @off)

(block_A/Int_VDD@off, block_A/Int_VDD @on)

(block_A/Int_VDD@off, block_A/Int_VDD @off)

However, due to the absence of logic interactions between both Int_VDDs, the system only

needs two power states to perform static low-power verification:

(block_A/Int_VDD @on, block_B/Int_VDD @on)

(block_A/Int_VDD @off, block_B/Int_VDD_B@off)

In this case, the power stable table is reduced by 50% and static low-power verification can also

complete in less time.

Figure 14: Blocks with internal switch supplies



System Power States VDD block_A/Int_VDD block_B/Int_VDD

state_1 1.0 1.0 1.0

state_2 1.0 off 1.0

state_3 1.0 1.0 off

state_4 1.0 off off

Table 2: System power state tables created by VCLP

System Power States VDD block_A/Int_VDD block_B/Int_VDD

state_1 1.0 1.0 1.0

state_4 1.0 off off

Table 3: Most efficient power state tables

5.4 UPF2.1 support

UPF 2.1 (IEEE standard 1801-2013) has been released and there are a lot of new features that

could help in the static low-power verification for complex low-power design SoCs, such as low-

power strategy creation, setting equivalent nets, port attributes settings, etc. We hope VCLP can

adopt these new features in the near future, which could further improve our chip level low-

power verification process.

6. Conclusions

We have adapted to the IEEE 1801 UPF standard in our SoC design. To manage the UPF files in

this complex design, it is suggested that UPF files be written in a more modular approach.

Merging all the internal supply nets that do not have logic interactions, reading sub UPF files for

subblocks and defining power states in only top level are effective approaches to reducing UPF

complexity and run time. With the help of VCLP, we are able to identify the defects in the user-

provided UPF file at an earlier stage. It also provides a much more efficient way for static low-

power verification and debugging. Looking forward, there is still a lot work to be done in the

future. Supporting supply-set-based boundary recognition, merging supply nets, merging power

state tables and support for UPF 2.1 features are possible improvements to VCLP.

7. References

[1] Verdi Signoff-LP User Guide

[2] IEEE Standard for Design and Verification of Low-Power Integrated Circuits (Standard IEEE 1801 –

2013)

upf-based static low-power verification in complex power structure soc design using vclp

Documents