Archive for the 'Power Format' Category

Based on earlier feedback, lets take a quick look at functional power state table and see how we can convert this into UPF state Table

Given below is a picture of sample Functional Power State Table

Now if you look at the above table it shows that there are 3 power domains and could be in 8 different states if we consider the active/switchable power.

But above table tells us that, there are only 5 legal states and rest of the them are not valid or illegal. Now to convert this into UPF PST, we need to first define 3 power rails.

Lets say that these 3 are called VDD_core, VDD_domain1 and VDD_domain2 respectively. Given this first we need to define the legal voltage values for these rails

add_port_state VDD_core -state {TOP_on 0.864} -state {TOP_off off}
add_port_state VDD_domain1 -state {DOMAIN1_on 1.08} -state {DOMAIN1_off off}
add_port_state VDD_domain2 -state {DOMAIN2_on 0.864} -state {DOMAIN2_off off}

Above UPF says that legal voltage values are either 1.08,0.864 or off

Now lets create a table and define the name and the columns

create_pst SYSTEM_PST -supplies {VDD_core VDD_domain1 VDD_domain2}

Now lets add the valid states to the table

add_pst_state AllOff -pst SYSTEM_PST -state {TOP_off DOMAIN1_off DOMAIN2_off}
add_pst_state LP0 -pst SYSTEM_PST -state {TOP_on DOMAIN1_off DOMAIN2_off}
add_pst_state LP1 -pst SYSTEM_PST -state {TOP_on DOMAIN1_off DOMAIN2_on}
add_pst_state LP2 -pst SYSTEM_PST -state {TOP_on DOMAIN1_on DOMAIN2_off}
add_pst_state AllOn -pst SYSTEM_PST -state {TOP_on DOMAIN1_on DOMAIN2_on}

Hopefully this gives a clear picture on how a power state table can be represented in UPF.

So far we have seen how UPF gets interpreted during synthesis and verification . Today lets look at how UPF gets interpreted during Floorplanning/Power Planning ? This is the most important phase in the design cycle, where power grid required for the design gets implemented physically to get the required functionality.

Main concerns here are

(a) If part of my design is going to be shut-down, how do I insert special cells in the power grid to cut-off power?

(b) How do I validate, whether my grid is beefed up enough to provide required amount of current to the circuit?

(c) How Many special cells are required to efficiently build the power grid ?

(d) How long will it take for the circuit to wake-up after recieving the wake-up signal ?

(e) Should I worry about the wake-up or shut-down sequence of switches as well as standard cells connected to the switches ?

(f) Which Part of the UPF conveys all these information?

First lets look at the UPF, which will be used by Floorplanning/Power Planning tools to implement the grid.

create_power_switch rx_sw
-domain RECIEVER
-input_supply_port {in VDD_LOW}
-output_supply_port {out VDD_LOW_RX_VIRTUAL}
-control_port {rx_sd power_controller/rx_sd}
-on_state {rx_on_state in {!rx_sd}}

The above command says, we need to insert a switch in the domain reciever, whose input supply port is VDD_LOW and output of the switch is VDD_LOW_RX_VIRTUAL. All the components inside the domain reciever are going to be powered through the supply net “VDD_LOW_RX_VIRTUAL”. Now how do we know which switch cell to use?

this is specified through the UPF command

map_power_switch -domain RECIEVER -lib_cell

Based on comments and feedback, I am posting the RTL as well as the UPF for this RTL. The Power Intent Diagram for this Designs is as shown Below

Power Intent Diagram

UPF for the above Power Intent:

######## Create Power Domains ###########

create_power_domain TOP
create_power_domain TX_AON -elements {transmitter power_controller}
create_power_domain RECIEVER -elements reciever
create_power_domain CRC_GEN -elements checker

## Toplevel Connections ######

# VDD_HIGH (1.08V)
create_supply_port VDD_HIGH
create_supply_net VDD_HIGH -domain TOP
create_supply_net VDD_HIGH -domain TX_AON -reuse
create_supply_net VDD_HIGH -domain CRC_GEN -reuse
connect_supply_net VDD_HIGH -ports VDD_HIGH

# VDD_LOW (0.864V)
create_supply_port VDD_LOW
create_supply_net VDD_LOW -domain TOP
create_supply_net VDD_LOW -domain RECIEVER -reuse
connect_supply_net VDD_LOW -ports VDD_LOW

# VSS (0.0V)
create_supply_port VSS
create_supply_net VSS -domain TOP
create_supply_net VSS -domain TX_AON -reuse
create_supply_net VSS -domain RECIEVER -reuse
create_supply_net VSS -domain CRC_GEN -reuse
connect_supply_net VSS -ports VSS

### RECIEVER/CRC DOMAIN Power Connections ##########

create_supply_net VDD_LOW_RX_VIRTUAL -domain RECIEVER
create_supply_net VDD_HIGH_CRC_VIRTUAL -domain CRC_GEN

### Establish Connections ################

set_domain_supply_net TOP -primary_power_net VDD_HIGH -primary_ground_net VSS
set_domain_supply_net TX_AON -primary_power_net VDD_HIGH -primary_ground_net VSS
set_domain_supply_net RECIEVER -primary_power_net VDD_LOW_RX_VIRTUAL -primary_ground_net VSS
set_domain_supply_net CRC_GEN -primary_power_net VDD_HIGH_CRC_VIRTUAL -primary_ground_net VSS

########## Shut-Down Logic for Reciever #######

create_power_switch rx_sw
-domain RECIEVER
-input_supply_port {in VDD_LOW}
-output_supply_port {out VDD_LOW_RX_VIRTUAL}
-control_port {rx_sd power_controller/rx_sd}
-on_state {state2008 in {!rx_sd}}

######### Isolation cell Settings for Reciever #######

set_isolation rx_iso_out
-domain RECIEVER
-isolation_power_net VDD_HIGH -isolation_ground_net VSS
-clamp_value 1
-applies_to outputs

set_isolation_control rx_iso_out
-domain RECIEVER
-isolation_signal power_controller/rx_iso
-isolation_sense low
-location parent

########## Create Shut-Down Logic for CRC #######

create_power_switch crc_sw -domain CRC_GEN -input_supply_port {in VDD_HIGH} -output_supply_port {out VDD_HIGH_CRC_VIRTUAL} -control_port {crc_sd power_controller/crc_sd} -on_state {state2009 in {!crc_sd}}

######### Isolation cell Settings for CRC #########
set_isolation crc_iso_in -domain CRC_GEN -isolation_power_net VDD_HIGH -isolation_ground_net VSS -clamp_value 1 -applies_to inputs

set_isolation_control crc_iso_in -domain CRC_GEN -isolation_signal power_controller/crc_iso -isolation_sense high -location parent

set_isolation crc_iso_out -domain CRC_GEN -isolation_power_net VDD_HIGH -isolation_ground_net VSS -applies_to outputs
set_isolation_control crc_iso_out -domain CRC_GEN -isolation_signal power_controller/crc_iso -location parent

#### Retention Logic for CRC ##############

set_retention crc_retain -domain CRC_GEN -retention_power_net VDD_HIGH -retention_ground_net VSS
set_retention_control crc_retain -domain CRC_GEN -save_signal {power_controller/crc_save high} -restore_signal {power_controller/crc_restore high}
map_retention_cell crc_retain -domain CRC_GEN -lib_cell_type LIB_CELL_NAME

#### Level Shifter for AON domain #################

set_level_shifter tx_aon_ls_out -domain TX_AON -applies_to outputs -location self -rule both

### Create Power State Table ##################

add_port_state VDD_HIGH -state {HighVoltage 1.08}
add_port_state VDD_LOW -state {LowVoltage 0.864}
add_port_state crc_sw/out -state {HighVoltage 1.08} -state {CRC_OFF off}
add_port_state rx_sw/out -state {LowVoltage 0.864} -state {RX_OFF off}

create_pst lvds_system_pst -supplies {VDD_HIGH VDD_LOW VDD_HIGH_CRC_VIRTUAL VDD_LOW_RX_VIRTUAL}
add_pst_state PRE_BOOT -pst lvds_system_pst -state { HighVoltage LowVoltage CRC_OFF RX_OFF}
add_pst_state CRC_ON -pst lvds_system_pst -state { HighVoltage LowVoltage HighVoltage RX_OFF}
add_pst_state RX_ON -pst lvds_system_pst -state { HighVoltage LowVoltage CRC_OFF LowVoltage}
add_pst_state ALL_ON -pst lvds_system_pst -state { HighVoltage LowVoltage HighVoltage LowVoltage}

RTL For the Top Level:

// This block needs to be Always on, it generates
// sd – shut_down for Switches
// save – save for RFF
// restore – restore for RFF
// iso – isolation_enable signals for Isolation cell
// reset – Reset signal to reset the block after wake-up
// Created on : 01/07/2008
// —————————————————————

module lvds_system ( clk, reset_n, frame_in, data_in, power_data, data_out, data_ok );
input [15:0] data_in;
input [3:0] power_data;
output [15:0] data_out;
input clk, reset_n, frame_in;
output data_ok;
wire serial_out, tx_frame, rx_frame;
wire rx_iso,crc_iso, crc_save,crc_restore, rx_sd,crc_sd,rx_power_ack,crc_power_ack;

piso transmitter ( .clk(clk), .reset_n(reset_n), .p_data_in(data_in), .load(
frame_in), .serial_out(serial_out), .tx_frame(tx_frame) );

sipo reciever ( .clk(clk), .reset_n(reset_n), .serial_in(serial_out),
.tx_frame(tx_frame), .parallel_out(data_out), .rx_frame(rx_frame) );

checker checker ( .clk(clk), .reset_n(reset_n), .load_tx_data(frame_in),
.load_rx_data(rx_frame), .tx_data(data_in), .rx_data(data_out),
.data_ok(data_ok) );

power_controller power_controller(.clock(clk),
.reset(reset_n),
.power_data(power_data),
.rx_iso(rx_iso),
.crc_iso(crc_iso),
.crc_save(crc_save),
.crc_restore(crc_restore),
.rx_sd(rx_sd),
.crc_sd(crc_sd),
.rx_power_ack(rx_power_ack),
.crc_power_ack(crc_power_ack));

endmodule

RTL for Power Controller:

RTL for Transmitter:

RTL for Reciever:

RTL for Checker:

Now lets look at the main components of UPF, which will be used by synthesis tools in making important decisions during optimization process.

For synthesis, main constructs in UPF which plays an important role are

(a) Level Shifter Insertion

(b) Isolation Cell Insertion

(c) Retention Cell Insertion and hook up

(a) Level Shifter Insertion: There are 2 commands, which influences level shifter insertion

set_level_shifter
-domain domain name
[-elements a list of pin and ports]
[-applies_to inputs | outputs | both]
[-threshold float]
[-rule low_to_high | high_to_low | both]
[-location self | parent | fanout | automatic]
[-no_shift]
level_shifter_name

Level shifters are placed on signals that have sources and sinks operating at different voltages, as their associated design elements are connected to different supply nets. In general, power state table (PST) and operating conditions are considered to determine if level shifters are needed for design elements on the boundaries of power domains.

The main option in the command, which I would give higher priority is the location of the level shifter

-location defines where the level shifter cells are placed in the logic hierarchy. All necessary supplies need to be available in the specified location.

a) Self: the level shifter cell is placed inside the model/cell being shifted.
b) Parent: The level shifter cell is placed in the parent of the cell /model
being shifted.
d) Fanout: level shifter occur at all fanout locations (sinks) of the port being
shifted.
e) Automatic: The implementation tool is free to choose the appropriate locations.

If we are using physical information based logic synthesis tools such as Design-Compiler Topographical, location plays an important role, as timing would be more accurate if physical location of the LS is considered in addition to other aspects of floorplan.

As a designer, I would prefer to specify the location of the LS in the command rather than letting the tool to make decisions automatically on the location.

Lets look at isolation strategy and other special cell related commands more in detail in my next post.

Its been a very busy month and could not write as expected. Lately I am getting many questions on a sample power intent diagram and associated UPF. Given below is a sample Power Intent Diagram of a design, which has 4 power domains, followed by How to represent this Intent into UPF.

Power Intent Diagram

Above Power Intent can be represented in UPF as given below

######## Create Power Domains

create_power_domain TOP
create_power_domain TX_AON -elements {transmitter power_controller}
create_power_domain RECIEVER -elements reciever
create_power_domain CRC_GEN -elements checker

## Toplevel Connections

# VDD_HIGH (1.08V)
create_supply_port VDD_HIGH
create_supply_net VDD_HIGH -domain TOP
create_supply_net VDD_HIGH -domain TX_AON -reuse
create_supply_net VDD_HIGH -domain CRC_GEN -reuse
connect_supply_net VDD_HIGH -ports VDD_HIGH

# VDD_LOW (0.864V)
create_supply_port VDD_LOW
create_supply_net VDD_LOW -domain TOP
create_supply_net VDD_LOW -domain RECIEVER -reuse
connect_supply_net VDD_LOW -ports VDD_LOW

# VSS (0.0V)
create_supply_port VSS
create_supply_net VSS -domain TOP
create_supply_net VSS -domain TX_AON -reuse
create_supply_net VSS -domain RECIEVER -reuse
create_supply_net VSS -domain CRC_GEN -reuse
connect_supply_net VSS -ports VSS

### RECIEVER/CRC DOMAIN Power Connections

create_supply_net VDD_LOW_RX_VIRTUAL -domain RECIEVER
create_supply_net VDD_HIGH_CRC_VIRTUAL -domain CRC_GEN

### Associate Supply Nets at the top level

set_domain_supply_net TOP -primary_power_net VDD_HIGH -primary_ground_net VSS
set_domain_supply_net TX_AON -primary_power_net VDD_HIGH -primary_ground_net VSS
set_domain_supply_net RECIEVER -primary_power_net VDD_LOW_RX_VIRTUAL -primary_ground_net VSS
set_domain_supply_net CRC_GEN -primary_power_net VDD_HIGH_CRC_VIRTUAL -primary_ground_net VSS

######### Create Switch to Shut-Down a Block

create_power_switch rx_sw
-domain RECIEVER
-input_supply_port {in VDD_LOW}
-output_supply_port {out VDD_LOW_RX_VIRTUAL}
-control_port {rx_sd power_controller/rx_sd}
-on_state {ON_STATE_RX in {!rx_sd}}

create_power_switch crc_sw -domain CRC_GEN -input_supply_port {in VDD_HIGH} -output_supply_port {out VDD_HIGH_CRC_VIRTUAL} -control_port {crc_sd power_controller/crc_sd} -on_state {ON_STATE_CRC in {!crc_sd}}

##### Isolation Strategy

set_isolation rx_iso_out
-domain RECIEVER
-isolation_power_net VDD_HIGH -isolation_ground_net VSS
-clamp_value 1
-applies_to outputs

#### Retention Register Strategy

set_retention crc_retain -domain CRC_GEN -retention_power_net VDD_HIGH -retention_ground_net VSS
set_retention_control crc_retain -domain CRC_GEN -save_signal {crc_save high} -restore_signal {crc_restore high}

#### Level Shifter Strategy

set_level_shifter tx_aon_ls_out -domain TX_AON -applies_to outputs -location self -rule both

### Create Power State Table

add_port_state VDD_HIGH -state {HighVoltage 1.08}
add_port_state VDD_LOW -state {LowVoltage 0.864}
add_port_state crc_sw/out -state {HighVoltage 1.08} -state {CRC_OFF off}
add_port_state rx_sw/out -state {LowVoltage 0.864} -state {RX_OFF off}

create_pst lvds_system_pst -supplies {VDD_HIGH VDD_LOW VDD_HIGH_CRC_VIRTUAL VDD_LOW_RX_VIRTUAL}
add_pst_state PRE_BOOT -pst lvds_system_pst -state { HighVoltage LowVoltage CRC_OFF RX_OFF}
add_pst_state CRC_ON -pst lvds_system_pst -state { HighVoltage LowVoltage HighVoltage RX_OFF}
add_pst_state RX_ON -pst lvds_system_pst -state { HighVoltage LowVoltage CRC_OFF LowVoltage}
add_pst_state ALL_ON -pst lvds_system_pst -state { HighVoltage LowVoltage HighVoltage LowVoltage}

The above completely represents the intent one would want tools to interpret, while making decisions on verification/implementation strategies.

Last week we saw how UPF is written from verification perspective and today lets see what information from simulator will help debug the issues.

First lets look at some of the information printed out by simulator when UPF is enabled.

Automatic Assertions Synthesized:

(1) INFO : Sleep Signal value changed. SleepSignal SLEEP corresponding to signal ‘testbench.dut.PwrCtrl.SLEEP’ changed to value = 1 at time =1094000

The above assertion informs user that Sleep signal named “SLEEP” responsible for shutting down block has wiggled.

(2) INFO : Design state changed. Design transitioned from BOOT state to DMA state at time 1094000.

Above assertion informs user that state of the design has changed, this state change is based on the change in voltage on rails and its per information described in UPF given below

add_port_state VDD_HIGH -state {HVoltage 1.08}
add_port_state VDD_LOW -state {LVoltage 0.864}
add_port_state crc_sw/out -state {HVoltage 1.08} -state {CRC_OFF 0.0}
add_port_state rx_sw/out -state {LVoltage 0.864} -state {RX_OFF 0.0}

create_pst System_State -supplies {VDD_HIGH VDD_LOW VDD_HIGH_VIRTUAL VDD_LOW_VIRTUAL}
add_pst_state BOOT -pst System_State -state { HVoltage LVoltage CRC_OFF RX_OFF}
add_pst_state DMA -pst System_State -state { HVoltage LVoltage HighVoltage RX_OFF}

Corresponding Waveform for the above state change is shown in the picture below

Voltage Aware Functional Simulation Waveform

(3) WARNING : Corrupting Island’s retained registers.
Retained registers of island Shut_Down_Hibernate have been corrupted because Retention Rail value has fallen below threshold value at time = 3818000

Above assertion warns user that, simulator corrupted the retention register, as voltage to these fell below the value specfied in the UPF.

Many more assertions similar to what’s shown above is synthesized automatically by VCS while simulating the design in UPF mode.

As you see from the above explanation, Voltage is no longer treated as Binary 1′s and 0′s instead real transient voltage is considered during functional simulation

Last week we discussed the various ways UPF can be used to model functional behaviour of a Mult-Voltage/Power Gating design. This week lets look at the following:

(1) Voltage ramps, and
(2) How will the simulator flag a violation, when some activity is triggered during the ramping up cycle or ramping down cycle?
(3) How to Model Voltage Regulator?

(1) Voltage Ramps and Modelling Voltage regulator:

One of the main requirements during functional simulation is to monitor signal ramps. For example, during shut-down and wake-up of a block, it takes some time for the power network to stablize with the required voltage. Now, if we don’t model this, the simulator will not validate the signal interaction with respect to change in voltage. This might lead to missing some functional bugs such as:

(a) Submitting request by an already powered block to a powering up block
(b) Assuming Always-on block to operate properly, while other blocks in the design are waking up and disrupt the current distribution to the block under question.
(c) ……etc

Now, in order to accomplish this, we need to define the voltage ramp using the verification methodology of VCS as shown below:

Vdd.legalvalues = {0-0.864};
Vdd.value = “tb.regulator_0.Vdd”;
VDD_memory_32kx8.legalvalues = {0-1.08};
VDD_memory_32kx8.value = “tb.regulator_1.VDD”;

If you look at the above format, it clearly shows that we are defining the voltage range of the signals supplied through regulators named regulator_0/regulator_1. These VDDs are associated with their respective blocks through UPF as described in the previous post.

The next step is to define the standby voltage value as well as shut-down values, as given below:

memory_32kx8.driving = VDD_memory_32kx8;
memory_32kx8.sleepheader = tb/system_controller/power_sequence/power_down;
memory_32kx8.sleepheaderthreshold = 0.0;
memory_32kx8.standbyvalues = {0.6};
memory_32kx8.shutdownvalue = 0.0;

From the above description, we are telling the simulator about the “power_down” signal, Standby Voltage value(0.6) and the voltage value when the block is shut-down.

So when you simulate the design using VCS along with UPF, simulator will make sure that these values are kept in mind while simulating the design. The above behaviour is shown in waveform captured below:

voltage_aware_waveform_02.jpg

In the next post, lets see how the simulator flags user about illegal states or behaviour with respect to change in voltage.

Before I sign-off for today, I would like to take a quick suvey on how many designers want to know a methodology to implement and verify design using Back-Biasing/Source-Biasing? Since I am getting many requests on the same, if you can just fill out the form below saying YES/NO, it would be really helpfull for me to work on this topic as well.

Link to Survey(Two questions only with Yes/No as options)
#######################################################
Do you use Well Biasing in your design ?
#######################################################

Last week we saw various commands within UPF which can be used for simulation. Today let us see how these constructs can be used to simulate certain behaviour.

(a) Functional Correctness of all the signals, when voltage is varying.

The question that needs to be asked here is, how to model the voltage in a logic simulator. One way to do this would be to use the behavioral model of a Voltage Regulator. Now, even if we do that, will the simulator be able to associate the Voltage Regulator to the appropriate signal and flag when there is violation ?

Using only UPF to encapsulate the above said behavior is difficult. But with the use of VCS along with UPF and its verification methodology we will be able to simulate this.

For example, lets say we define the legal state of the design for various power domains as follows:-

add_port_state VDD_HIGH -state {HighVoltage 1.08}
add_port_state VDD_LOW -state {LowVoltage 0.864}
add_port_state crc_sw/out -state {HighVoltage 1.08} -state {CRC_OFF 0.0}
add_port_state rx_sw/out -state {LowVoltage 0.864} -state {RX_OFF 0.0}

create_pst pst_0 -supplies {VDD_HIGH VDD_LOW VDD_HIGH_VIRTUAL VDD_LOW_VIRTUAL}
add_pst_state PRE_BOOT -pst pst_0 -state { HighVoltage LowVoltage CRC_OFF RX_OFF}
add_pst_state CRC_ON -pst pst_0 -state { HighVoltage LowVoltage HighVoltage RX_OFF}

From the above state table it is clear that, there are 2 domains which are going to be shut-down and their voltages are 1.08V and 0.864V.

If the simulator sees any state other than the one defined in the above state-table, it should flag it as an Invalid State. However, the simulator won’t be able to differentiate between the two voltage levels nor the ON/OFF Voltages. One way to handle ON/OFF Voltage for the switch is to model this behaviour in a testbench, as follows:-

always @(tb.dut.power_controller.shut_down)
if (tb.dut.power_controller.shut_down == 1′b0)
VDD_HIGH_VIRTUAL = 1.08;
else VDD_HIGH_VIRTUAL = 0.0;

So far we have only modelled the ON/OFF voltage, how about:-

(1) Voltage ramps, and
(2) How will the simulator flag a violation, when some activity is triggered during the ramping up cycle or ramping down cycle?
(3) How to Model Voltage Regulator?

Let us discuss this in my next posting.

One of the main advantages of using UPF is that it ensures that the low power nature of a design is taken into account during functional verification. If we look at the various factors that need to be validated in the RTL functional simulation w.r.t Low Power Techniques, here are some of them:-

(a) Functional Correctness of all the signals, when voltage is varying.
(b) When a block is shut-down, how will the outputs of this block be treated ?
(c) When a block wakes up, is the neighbouring block expecting/sending some signals to the block waking up, during ramp-up time ?
(d) Is the signal properly recieved by the block, which is still waking up?
(e) How to simulate Switch Behaviour as well as Power Acknowledge?
(f) Does the Voltage level through LS/ISO cells actually shift the voltage ?
(g) How do we save certain flop states, when a block is powered down?
(h) Did we restore the flop states properly after wake-up ?
(i) How to simulate data corruption of retention flops, when the voltage on the retention power is below the required value?

Now let us take a look at the various UPF constructs, which enable us to verify some of the above.

List of UPF constructs, which are useful for functional validation:-

(1) set_scope
(2) create_power_domain
(3) create_supply_net/port
(4) set_domain_supply_net
(5) create_power_switch
(6) connect_supply_net
(7) set_level_shifter
(8) set_isolation_control/set_isolation
(9) set_retention_control/set_retention
(10) create_pst/add_port_state/add_pst_state

I think for today, this is quite a bit of data ! In my next post, I will continue on the simulation aspects using UPF.

So far my posts have dealt with various power reduction techniques used by designers as well as some of the challenges faced using these techniques in the design flow.

Most of the complexity in using these techniques comes from the fact that we need to interpret virtual logical/physical power structures, since most of them are not specified in the RTL.

The implementation tools need to interpret these logical/physical structures based on the RTL and some tool specific commands. This leads to complicating verification flow in general. Can we prevent this additional complexity by adding these structures explicitly in the RTL ? That is the question!

All These days power intent/requirements are typically captured through a combination of:

(a) RTL
(b) TCL based tool specific commands
(c) Library model in Liberty Format
(d) Design Constraints file (SDC)
(e) Verilog Simulation models
(f) Customized Routines such as PLI’s for verification
(g) User Driven customized Assertions …..etc

If you look at the above list, the power intent/specification is available at many sources. There could be duplicates/redundant ones, which could lead to passing different set of information to verification/implementation tools. I think in the best interest of designing chips efficiently, power intent should be kept seperate from functional intent.

Fortunately, now we have a way to express the power intent through standards such as the Unified Power Format. I will try to take you through the complete flow from RTL to GDS implementation/verification using UPF, in my next few posts.

Briefly, the general idea of UPF is to keep your design Power Intent separate from the Functional Intent and to let each tool in the flow understand the power requirements through this format. Keep in mind that any Power Intent file is only representing your design’s power-related definitions. By itself, it will not guarantee an optimal low power design.

Guys jump in and let me know if you want to hear something in specific to UPF you are challenged with, while planning for your next chip.