Unified Power Format

It is well-known fact that power is an important driving factor for today’s complex electronic designs. The advent of portable and smart electronic devices have forced engineers to change the way they think (or made them think if they were not doing so earlier!) about power consumption of their designs.

Various techniques have been around for how one can reduce power consumed by his/her design. However, usual approach was to design the RTL and then add power intent into the netlist level. The problem with this approach is that it may result in unnecessary respins in the design cycle as it may take longer time to come up with optimum power strategy for the RTL which was designed irrespective of power strategy.

So, the idea is to introduce power strategies at the early stage of the design phase. However, the hardware description languages have not been designed taking “power factor” in account. Hence, there is no consistent way to describe the power strategies in the design. The Unified Power Format (UPF) provides an easy and effective way of describing “power intent” of the design and hence introduces power reduction techniques in the RTL stage itself.

The advantages of UPF are:

• » It is HDL independent.
• » It consists of simple and verbose TCL commands to describe the power intent.
• » Standardized as IEEE 1801-2009.
• » No need to modify the RTL explicitly.
• » It allows power-aware simulation of the design by appropriately controlling the power strategies described in the power intent.
• » It can be used for electronic designs or IPs.
• » It allows power to be considered at the earliest stages of the design. This helps in two ways:
• » Precious time in the design cycle is saved.
• » Consistent power strategy is maintained from start to the end by having the same UPF file as reference.

UPF has the following capabilities as far as the power intent of the design is concerned:

• » Working at different hierarchy levels in the designs.
• » Creating different power domains for the design at different levels in the design hierarchy.
• » Creating power ports, nets and power supply network that lets power flow through the design components.
• » Creating power switches that control the power gating for different power domains.
• » Creating Retention strategies that can store the last states of design elements and restore them to those values when waken up from the power off.
• » Creating Isolation strategies for power domains.
• » Introducing Level Shifters for multi-voltage designs.

We will have a look all these features one by one and then we will explore each of them in detail with an example.

Setting Design Scope

Every practical design will have a hierarchy of design elements or components. The level at which one can introduce the power control strategies at different levels in the design.

The upf allows this by setting the scope of the design. There are two relevant upf commands: set_design_top and set_scope. Syntaxes of both are as shown below:

set_design_top < hierarchy_level_element >

set_scope < hierarchy_level >

The common practice maybe to set the scope as design top and specify the design elements with respect to that level in design hierarchy. The top level module need not be the design top for upf as one may be interested in working at some intermediate level in the hierarchy. The following example explains this:

set_design_top top/dma/state_mc
set_scope top/dma/state_mc
or
set_scope

Creating Power Domains

Power domain is the collection of design elements. One can define a power domain at different levels of design hierarchy. It may be a single design block or a collection of few such blocks. The following figure shows the example of power domains in a hierarchical design. The upf syntax for creating power domain is as follows:

create_power_domain < power_domain_name > -elements { < list_of_design_elements >}

• » Creating Power Supply Network
• » Creating Power Switches
• » Creating Isolation Strategies
• » Creating Retention Strategies
• » Creating Level Shifter Strategies

Supply Network

Supply network consists of following components:

Supply ports

Supply nets

Power switches

All the above components can be easily created for a power domain using UPF commands. Supply network is specified apart from the logic design; logic design specification remains independent of specific power supply network. Supply network is said to be complete, when at least one ground power supply is created.

Creating Supply Ports:

Supply port is basically used for connecting the ports of the module to the main power supply. It is a port that originates a supply state and voltage value. Each supply port has one or more supply state defined. The port can drive only one state at a given time. Supply ports provide the ability to connect a supply net to the design element. Supply ports provide supply interfaces to the switches. Supply ports and supply nets can be created either in UPF or HDL. If the net or port is created in HDL, that will be of type supply net created in UPF systemverilog. The name of supply port cannot be the same with the existing net.

Supply ports have two halves. The first half is known as Highconn and the second half is known as Lowconn. The Highconn is visible external to the design elements whose interface contains the port whereas the Lowconn is visible internal to the design elements whose interface contains the ports. When a supply net in the active mode is connected to the logic port in the child instance, the supply port is connected to highconn. The supply port is connected to lowconn when a supply net in active mode is connected to the logic port of same instance. UPF provides create_supply_port command to create supply ports. This command creates a port on power domain. They are defined for switches in create_power_switch. Each supply port has one or more supply nets defined by itself. The supply port can drive only one state at a given time.

The basic syntax for creating supply port is:

create_supply_port <port_name> –domain power_domain_name //creates a port on power domain.

Creating supply nets:

As mentioned earlier, supply ports can drive one state at a time. The driven state is propagated by the supply net. To understand supply nets better, we can just mention it as a simple wire which is used for connecting two elements. Supply nets are connected to supply ports and logic gates. They propagate a supply state. The supply states are 0, 1 and voltage values. Each supply state has one or more supply state defined in it. Supply nets carry an electrical current. During simulation, each supply port and supply net maintains two kinds of information: a supply state and a voltage state. The supply state consists of two states: on/off state and full/partial state. Each pair of supply nets, a power and a ground supply net, connected to one or more design elements belongs to a simulation process. Supply nets are automatically connected to supply ports of design element in the power domain. They propagate the state (on, off, voltage value). Individual supply net can be connected to supply ports using the command connect_supply_net. This command connects the supply port to supply net. The name of supply nets or ports should not conflict with the existing port or net designed for the element. This command can be used only once per net until the –reuse is specified. Resolution mechanism determines the state and voltage of the supply net from the state and the voltage values supplied by each of switches. Individual supply nets are connected automatically to the supply ports. The basic syntax for creating the supply nets is:

create_supply_net <net_name> -domain <power_domain_name>
[-reuse] [-resolve < unresolved | hot state | parallel>] //resolution mechanism explained above.

If power_domain_name is specified, the net is created in the logic hierarchy in the same scope of design; else the net is created in the active region. If both the power and ground supply nets are on, the design element instances connected to the given supply pair is turned on. If either the supply net is off, the power to the design element instances is turned off. It is simply creating wires to each and every modules input and output to the power supply.

After creating the supply nets, we need to connect the supply nets to the ports of the module. The basic syntax for connecting the supply nets is:

connect_supply_net <net_name> -ports <port_name>

Retention Cell:

Sometimes, modules will be switched on and off in order to reduce the current consumption. But for some of the modules, there is a necessity that they need to retain their values. In order to retain the values, retention is used. In retention, current is consumed more than that required. But the module values are recovered very fast after getting up from sleepy mode. At the gate level, special retention cells like flip-flops are used to provide retention capability. The retention modules are instantiated in the DUT but are part of power intent. The simulator communicates with the model and connects the model to the clock, reset, and power.

There are two types of signals associated with retention, save signal and restore signal. These two operations are triggered either by using a single control statement or using two control statements. But problem occurs if race condition occurs between the two control statements. If the race condition occurs between the save and restore signal, the retention value stored in the retention register may be corrupted. Therefore, UPF provides a mechanism for such scenarios. Some registers have retention ability. They can preserve their value after a shut down also. There are separate simulators that support this kind of retention behavior.

Sometimes we need a fast restart of operation before entering into sleepy mode. Here, it is necessary to save the present state of the design before it goes into sleepy mode. In such situations, save signals are useful. After entering into active mode (non-sleepy mode), it is necessary that we need to restore the previous value. In this way restore signal is useful. The retention cells are not instantiated in the Device under Test (DUT) but, they are the part of the power system. Using a high level retention model allows us to match the behavior of the retention cells and then the cells will be inserted at the gate level. We need to verify that proper timing of control signal (save) is provided for retention registers to save the values before the power is off. Proper timing of control signals are provided to the retention registers to store the values of the registers when the power is on. Clock or reset signals should not be provided to the power gated system with which the registers are storing the information.UPF provides set_retention and set_retention_control commands to instantiate the retention environment in the design.

The above figure explains the concept of retention clearly. During simulation, each registers which are to be retained creates two processes: one with respect to the save signal and another with respect to the restore signal. A retention memory is also created for each element which needs to be retained. This retention memory is called shadow register. Whenever the save signal changes the values and matches with the corresponding save sense, the value is stored and updated in the shadow register. If the save signal is X or Z, the shadow registers are stored with their default initial value. If the restore signal is X or Z, the registers are stored with the default values. The basic syntax for the initiating the retention environment in the design is:

set_retention <retention name> –domain <power_domain_name>
-retention_power_net <net_name>
set_retention_control <retention name> –domain <power_domain_name>
-save_signal { net_name} // represents net_name in the above figure
-restore_signal {net_name}

Mapping capabilities can be enhanced using map_retention_cell command port mapping enables the connection of cell ports to the signals . Identifying incorrect retention behavior is very important in the design. Incorrect state of registers like clocks, set can cause incorrect retention vales on the memory. Therefore it’s necessary to identify the proper behavior of the retention during the simulation. Sometimes retention may be absent in the retention register. This error occurs usually when the save or restore signal operation fails. The current value of the register is not stored due to the failed save signal operation which obviously results in the failure of the restore signal operation.

Isolation:

Sometimes the modules get switched off and they cannot drive their outputs anymore. In this case, the modules outputs become floating modes. This might be a problem. The main reason behind this unexpected value is of some inappropriate logic levels. To overcome this problem, isolation cells are used. Isolation cells are always placed between the power domains which drive 0, 1 or latches the old value. It ensures that the output has some predefined value. It also sees that active domains are not affected. Isolation logic can be categorized under static verification in structural part which looks for the missing isolation cells in the design. Isolation is used to clamp the output value. UPF provides set_isolation and set_isolation_control commands to add isolation cells in the design. These two commands are used to determine which ports are to be isolated and where the isolated cells are to be placed. The following figure gives a clear picture of the isolation strategy. UPF provides few commands through which the isolation cells can be inserted in the design.

set_isolation <isolation_name> –domain power_domain_name>
-isolation_power_net <net_name>
-clamp_value <value>
set_isolation_control <isolation_name> –domain <power_domain_name>
-isolation_signal <signal_name>

Isolation can be performed by clamping the output values to either 0, 1, z or latch. It is not mandatory that only output values are clamped but the isolation can be performed by clamping the input vales also. The clamp value when set as ‘0’ works as a basic AND gate. On the other hand, initializing the clamp value ‘1’ can be inferred as OR gate functionality. Application of clamp values depends on many factors like the logic to be implemented, the designers requirement, etc. Pull up transistor clamps the output to ‘1’ and pull down transistor clamps the output to ‘0’ when it receives the isolation signal from the power controller. When the isolation signal goes low, isolation cell becomes low and clamps the output of the signal to 0; else the isolation cell becomes inactive. In some cases we want to map the isolation to a specific cell within the same driver or sometimes different one. map_isolation_cell command supports this facility mapping cells.

During simulation each signal corresponds to the process which is sensitive to both the non-isolated and the control commands. Every time the control signals value changes, the new value is compared with the isolation value. If the control signal and the isolated values are same, then the clamp value is the isolated signal, else the non-isolated signal is driven as the clamp value. Sometimes, the designs are very complicated that it may include much number of power domains, supply ports and nets. In such cases, it is difficult to identify whether the isolation cells are placed at the right place or not. It’s still tougher to identify the scenario during the simulation time. Therefore identifying the missing isolation cells plays a vital role. The following algorithm helps in finding the missing isolation cells:

1. Ensure that the isolation strategy is created in the design which can be done using set_isolation command.

2. If set_isolation command is not specified, and if the signal is going from one active domain to another, implies that the isolation strategy is required by the particular signal. The simulator generates an appropriate message stating that the isolation cells are missing.

Creating power switch:

A switch is an element that connects one or more input supply nets to the output supply net according to the logical state of the nets. Power switch is used to connect the power to the power domain from the main power supply. The power switch is created during the simulation process, which plays a key role in understanding how the blocks are switched on and off. It always enables two inputs. This corresponds to the process which is sensitive to the changes in the input as well as the control ports. Whenever the control value changes, the Boolean values are evaluated. The switch is closed when the on state function is true. At this stage, the input port is switched into the output port. In the other case, if the switch is open, the output port is assigned OFF state. Here, there is no specific voltage value. If the control signals are X or Z, the input supply is undetermined. The diagrammatic representation of the power switch makes us easy to understand the concept of power switch in a better way.

The basic syntax for creating power switch is.

create_power_switch <switch_name> –domain <power_domain_name>
-input_supply_port { <port_name> <supplynet_name>} //input supply
-output_supply_port { <port_name> <supplynet_name>}//output supply
-control_port {port_signal net_signal} //enable the switch
-on_state { <state_name> input_supply_port {operation}} //on state
-off_state { <state_name> output_supply_port {operation}} //off state

Level Shifters:

Another important concept involved in UPF is level shifters. They are also known as buffer-type level cells. Level shifter insertion is done based on the Power State Table along with some additional information extracted from the set_level_shift command. Level shifters are placed on the connection between two domains that operate at different voltage levels. The placement of level shifters is very important. The output driver for the level shifter requires more power that that of the input stage. Therefore, level shifters are usually placed in the destination side of the domain. They are usually not placed when the voltage difference between two power domains is less than that of threshold value. Level shifters are taken into account when the logic conversation of signals from one voltage domain to another is required. The main purpose of level shifter is to convert the signal voltage to the correct voltage.

There are two cases:

Shifting the voltage down: This is an easy process. Shifting the voltage from high to low can be just a simple inverter or buffer.

Shifting the voltage high: This is a bit complex process. Careful placements of the cells to minimize the area are required.

Level shifters are used to manage the voltage dip between two domains, in which both the domains are operating at different voltages. Let us consider we have two domains, Domain 1 and Domain 2. Domain 1 has voltages operating at 0.9v and 1.2v and Domain 2 has two operating voltages at 1.2v and 1.6v. There may be chances of wrong detection of voltage levels in these two domains i.e., an input 1010 in domain 1 can be detected as 0101 in domain 2. This may happen because of the variation in voltage level. In order to avoid these voltage variations between the domains, the level shifters are used. Its core function is to ensure that there is no flip in the voltage.

UPF provides various commands like create_power_domain, set_domain_supply_net which facilitates the users to easily insert level shifters strategy in their design. The set_level_shifter command is automatic rule based insertion. Users can separate the design based on the primary and ground power supply using create_power_domain. It also allows the users to add instances in the RTL design. The set_domain_supply_net identify the primary and ground supply net in the designs. These pins are implicitly connected to all the logic ports. The supply power is necessary for normal operations.

UPF provides the following constructs to build level shifters environment in our design.

set_level_shifter <shiftername> –domain <power_domain_name>
-applies_to_outputs
-location fanout
set_level_shifter <shiftername> –domain <power_domain_name>
-applies_to_inputs
-location fanout

Detecting incorrect level shifters also plays a key role in designing UPF. If the user has specified a level shifter strategy saying “high to low level shifter”, the simulation tool checks whether the level shifter is placed between the main power at a higher voltage than the other one. This is possible because the simulation tool is aware of the exact voltage values at which the port operates. Absence of any level shifter or if incorrect values are provided, the tool immediately displays a message saying that the incorrect shifter values are given. Assertions are also used to check the consistency of the level shifters in our design.

Power state table:

Inside UPF, there is a very important part called power state table (PST). Any power management strategy starts with PST. Power states can be referenced by object_name. They are attributes of object. The following objects may have power states assigned to them:

Power domain.

Supply nets.

Supply ports.

We won’t list PST’s on objects. The definition of PST state should refer to the definition of another PST state. It defines at what power stage the design is working and when the design can be switched can be on and off. The power state table is basically used for implementation, especially for synthesis, analysis, etc. Each power state represents regions (power-domains) and the voltage values supplied to it. They define all the possible power state combinations which can exist at the same time during the operation of design. An error occurs if the declared supply net has not been created earlier in the design. UPF provides create_pst command to create power state table (PST) in the design. Power state table is used for verification. It also verifies isolation gates and level shifters.

The basic syntax for the power state table is:

create_pst –supplies lists

Let us consider we have three power rails main, VDD_domain1, VDD_domain2. First we need to define the voltage values for these power rails.

add_port_state main -state {HV 1.2}
add_port_state VDD_domain1/vout -state {HV 1.2} -state {LV 0.8} -state {OFF off}
add_port_state VDD_domain2/vout -state {HV 0.8} -state {LV 0.2} -state {OFF off}

// implies that the voltage values are either 1.2 or 0.8 or 0.2.

We need to add valid states to the table using the syntax:

add_pat_state <statename> –{voltage levels} //on or off

An error occurs if an add_pst_state command defines a state in which the same supply nets or ports have different values. Any state defined by add_pst_state is by default a legal state.

User Guide for using Assertion file for low power

Assertions for low power

Low-power designers can effectively use the power of assertions to detect hard to find bugs and design problems. Assertions can be manually generated, but user-instantiated assertions need to be design-specific and complete.

Knowledge of low-power design techniques can drive EDA tools automatic generation of assertions for such designs. For example, in low-power design the clock should not toggle for a powered down domain.

Terminologies in this guide

Term Definition

clk Clock signal for the design

reset Reset signal for the design

power_ctrl The control signal for the power switch. Where power switch controls the power input to design.

high_fanout_net Inputs or outputs signals to the design. This signals will be connected to actual inputs and output of the design in testbench.

isolation_ctrl Isolation signal that controls the isolation of domain when that will be off

save The signal that specifies when the output should get retained into retention register

restore The signal that specifies when the data should get restored from retention register

power_control_for_all_domains This is a signal for controlling the power input for all the domains.

NO_OF_DOMAINS This is the parameter where the user can mention the number of domain elements.

ISO_SENSE Parameter which signifies the voltage level at which isolation of specified signal takes place

Parameters

These are the variables whose value can be changed according to the design specification or domain requirements. These variables make this assertion file reusable for any kind of design. These value are constant values whose values will be fixed by user according to their requirements.

NO_OF_DOMAINS

Collection of design elements that share a primary supply . A power domain may also have additional supplies, including retention and isolation supplies.

This parameter specifies how many such domains the user design consists of. User can specifies the number of the domains.

POWER_OFF,POWER_ON :

These signals are mainly used to make any signal active high or active low. According to the values of these signals the signal may act as active high or active low.

RESET_OFF,RESET_ON :

These are the constants mainly used for checking the value of reset signal. User can fix these signals according to specification.

WIDTH_n:

This is the parameter which specifies the width of the high_fanout_net. User can specify the width of the high_fanout_net. Where n value depends on the input output width of the domains.

Assertion rule 1 :

Clocks, resets and other high fanout nets of off islands must be gated inactive when the island is powered off. Here different properties will be there for clock, reset and fanout to check is that signals of particular domain are inactive when that domain is off.

property check_clk_inactive_power_off;
@(clk)
(power_ctrl==POWER_ON) ;
endproperty
clk_inactive_power_off:assert property (check_clk_inactive_power_off)
else
$error($time,"ASSERTION FAILURE:CLOCK TOGGLING DURING POWER OFF\n");

Here property includes boolean logic at a clock to verify weather clock is inactive or not. When clock is toggling even though that domain is off then assertion fails and displays an error message.

property check_reset_inactive_during_power_off;
@(reset)
(power_ctrl==POWER_ON) ;
endproperty
reset_inactive_during_power_off:assert property (check_reset_inactive_during_power_off)
else
$error($time,"ASSERTION FAILURE:RESET ACTIVE DURING POWER OFF\n");

This is same as that of above example but here it asserts for reset.

In the same way we have to assert the fanout whether it is inactive or not. This will be done by following property. Where n specifies the nth fanout.

property check_high_fanouts_inactive_on_power_off_n;
@(high_fanout_net_n,power_ctrl)
(power_ctrl==POWER_OFF) |-> (high_fanout_net_n == POWER_OFF_VAL_NETn) ;
endproperty
high_fanouts_inactive_on_power_off_n:assert property (check_high_fanouts_inactive_on_power_off_n)
else
$error($time,"********ASSERTION FAILURE:HIGH FANOUT NET-1 SHOULD BE INACTIVE DURING POWER OFF********\n");

Assertion rule 2

Software addressable registers known to be in on/off islands must have assertions to verify that access happens only when they are in ON state.

Following assertion verify the addressable register at read signal(rd_enable)

property check_software_register_access_during_power_off_1;
@(rd_enable,addr)
(power_ctrl==POWER_ON) ;
endproperty
software_register_acess_during_pwr_off_1:assert property (check_software_register_access_during_power_off_1)
else
$error("********ASSERTION FAILURE:REGISTERS ACCESSED DURING POWER OFF********\n");

Following assertion verifies the addressable register at write signal(wt_enable)

property check_software_register_access_during_power_off_2;
@(wr_enable,addr)
(power_ctrl==POWER_ON) ;
endproperty
software_register_acess_during_pwr_off_2:assert property (check_software_register_access_during_power_off_2)
else
$error("********ASSERTION FAILURE:REGISTERS ACCESSED DURING POWER OFF********\n");

Assertion rule 3

Assertion to check that the control signals are not X or Z. This assertion will takes place at the event activity_of_ctrl_signals.

property check_for_control_signal_val_as_X_Z;
@(activity_of_ctrl_signals) not ($isunknown(save) || $isunknown(restore) || $isunknown(isolation_ctrl) || $isunknown(power_ctrl));
endproperty

control_signals_values_as_xz :assert property (check_for_control_signal_val_as_X_Z);

In this assertion the property checks for any signal are not X or Z. In this $isunknown() command returns 1 if data is having X or Z value. not operator returns 1 if data is not having any X or Z value.

Assertion rule 4

The domain should be powered off atleast once during isolation. This assertion checks whether the domain is off during isolation or not. If domain is not off during isolation otherwise the isolation would be redundant and the output of the domain would be unnecessarily freeze to clamp value. Here the isolation_to_power_off_flag will be asserted to to verify that domain is off or not. This assertion will takes place at the event `INACTIVE_ISO_EDGE isolation_ctrl. Where INACTIVE_ISO_EDGE is the variable which is declared as posedge.

always @(`INACTIVE_ISO_EDGE isolation_ctrl)
begin
NO_REDUNDANT_ISOLATION: assert ( isolation_to_power_off_flag )
$display("\n******* ASSERTION SUCCESS:APPLIED ISOLATION IS NOT REDUNDANT *******\n");
else
$error("\n******* ASSERTION FAILURE:REDUNDANT ISOLATION FOUND *******\n");
end

Assertion rule 5

Guard Against Multiple Rail Changes: If there is power switching activity in more than one domain, at the same time, there could be caused rush currents in the design which may lead to a lot of noise on the power rails. This assertion checks if such a switching activity is occurring. for loop to check all the domains and power_control_for_all_domains of each domain. Accordingly PWR_SIG_STATUS will be varied for all the domains.

This assertion will be activated based on the event PWR_SIG_STATUS.

for(i=0; i < NO_OF_DOMAINS-1; i++)
begin
always @(power_control_for_all_domains[i])
begin
PWR_SIG_STATUS[i]=1;//i-th power signal altered.
end
end

Assertion which is activated based on the event PWR_SIG_STATUS. Here $onehot() command returns true if PWR_SIG_STATUS is having only one bit high or else returns false if it is having a high value for more bits.

always @(PWR_SIG_STATUS)
begin
NO_MULTIPLE_RAIL_CHANGES_SIMULTANEOUSLY:assert($onehot(PWR_SIG_STATUS))
$display("\n******* ASSERTION SUCCESS: NO MULTIPLE RAIL CHANGES ON POWER SWITCHING ACTIVITY! *******\t@time:%g\n", $time);
else
$error("\n******* ASSERTION FAILURE: MULTIPLE RAIL CHANGES! *******\t@time:%g\n", $time);
PWR_SIG_STATUS=0;
end

This assertion file can be binded to any kind of the design. User can bind design with any specification to this assertion file. But only changes user has to do is that. The parameter values in this file are to be changed according to the design specification.