Power Intent Formats: Power Domain

Making sense out of UPF, CPF and IEEE 1801; what’s similar and what’s different.

popularity

By Luke Lang
Starting this month, I will be writing a series of blogs inspired by “Dueling Power Formats”. The article correctly points out that there are currently three power formats: CPF, UPF 1.0, and IEEE 1801. Some designers will find themselves in a position of having to choose a format. Others will need to work with both formats. Regardless of which position one is in, these LP designers must understand the fundamental similarity and differences between the formats. My goal is to help them achieve this understanding.

Often, the term “power domain” causes great confusion because the same words have similar meaning in different format but are not quite the same. This month’s blog will focus on this fundamental concept.

In CPF, a power domain is a collection of gates powered by the same power and ground supply. This definition is based on electrical connection. The terms “voltage island” and “power island” mean exactly the same thing. In UPF 1.0, “power domain” refers to a logical hierarchy in the design. In IEEE 1801, a new concept of “supply set” is introduced to bridge the gap between UPF 1.0 and CPF’s definition of power domain.

Let’s illustrate the difference with a simple example. Module instances u1 and u2 belong to PD1 and are connected to the same PG (Power/Ground) nets. Module instance u3 belongs to PD2 and is connected to different PG nets. We would like to isolate the signals from u1 & u2 to u3. This means that outputs B and C should be isolated, but not output A.

luke1

In CPF, we would code something like:

create_power_domain –name PD1 –instances {u1 u2} …
create_power_domain –name PD2 –instances {u3} …
create_isolation_rule –name ISO1 –from PD1 –to PD2 …

If we coded the following UPF 1.0:

create_power_domain PD1 –elements {u1 u2}
set_isolation ISO1 –domain PD1 –applies_to outputs …

We would also isolate output A because UPF 1.0 defines the u1 hierarchy as PD1 and A is an output of u1. In CPF, output A drives into u2, which is still PD1. Therefore, output A does not cross domain boundary and does not need to be isolated.

In order to achieve the correct result in UPF 1.0, we need to add:

set_isolation ISO2 –domain PD1 –no_isolation –elements {A}

This provides an additional specification to not isolate output A.

Designers that use UPF 1.0 must pay attention to this. They must manually find and specify the outputs that should not be isolated.

In 1801, we would code something like:

create_supply_set SS1 –function {power VDD1} –function {ground VSS}
create_supply_set SS2 –function {power VDD2} –function {ground VSS}
create_power_domain PD1 –elements {u1 u2}
create_power_domain PD2 –elements {u3}
set_domain_supply_net PD1 -primary_power_net SS1.power \
-primary_ground_net SS1.ground
set_domain_supply_net PD2 -primary_power_net SS2.power \
-primary_ground_net SS2.ground
set_isolation ISO1 –domain PD2 –source SS1 –diff_supply_only TRUE \
–isolation_power_net VDD2 –isolation_ground_net VSS …

1801 adds the concept of electrical or voltage domain, which does not exist in UPF 1.0. This is specified with supply set. The above 1801 code says that we are going to add isolation cells in PD2 but only for signals that are driven from supply set SS1.

For UPF 1.0 coding, one way to work around the need to manually identify the no_isolation output is to add a wrapper around u1 and u2. If we specify PD1 to be the wrapper, then the only outputs are D and E.

Luke2

The UPF 1.0 code would look like:

create_power_domain PD1 –elements {u_wrapper}
set_isolation ISO1 –domain PD1 –applies_to outputs …

This looks a lot cleaner, but adding the wrapper may not be a trivial exercise.

For those that are used to CPF power domain, it would be much easier to think of UPF 1.0 power domain as hierarchy. For those that are used to UPF 1.0 power domain, it would be much easier to think of CPF power domain as voltage island. Regardless of how you want to think about CPF and UPF 1.0 power domains, make sure you know that they are not exactly the same.

–Luke Lang is senior product engineering manager at Cadence.



Leave a Reply


(Note: This name will be displayed publicly)