Power Intent Formats: Reality Check

By Luke Lang

It is January once again. In addition to wishing everyone a Happy New Year, I would like to wish everyone a lower-power 2012.

This month, I will continue with the CPF/UPF power format discussion and examine more complex power architectures. Also, the focus will be only on CPF 1.1 and UPF 1.0. These are what the current tools support. IEEE 1801 is up and coming, but there is not much tool support for it right now.

For many designers, nested power domains present significant challenges. One example is the donut power domain, PD2, in the figure below.

From PD2, there is one domain crossing but two hierarchy crossings – pin A and B. To specify the domain crossing in CPF is very straightforward.

create_isolation_rule –name ISO1 –from PD2 –to PD1 …

Since UPF isolation policy is hierarchy based, complete domain crossing must include two hierarchy crossing:

set_isolation ISO1 –domain PD2 –applies_to outputs …
set_isolation ISO2 –domain PD1 –applies_to inputs –elements {u1/u2/u3/A} …

Notice that pin A must be specified. Otherwise, we will pick up the input pins of u1, which are not part of crossing from PD2.

For designers that are more used to coding UPF, a common CPF coding mistake is to translate:

set_isolation ISO1 –domain PD2 –applies_to outputs …

into:

create_isolation_rule –name ISO1 –from PD2 …

This CPF command will pick up both hierarchy crossings because CPF is domain based. “-from PD2” means any signals leaving PD2, regardless if leaving to parent or child hierarchy. A correct translation is:

create_isolation_rule –name ISO1 –from PD2 –pins {u1/u2/u3/B} …

Using the same nested architecture, here is a more interesting example.

Pin A is both a domain crossing and a hierarchy crossing from PD3 to PD2. Pin u1/u2/u3/B1 is only a hierarchy crossing from PD3 to PD2. Pin u1/u2/B2 is only a hierarchy crossing from PD1 to PD1. There is no domain crossing from PD3 to PD2 or from PD2 to PD1 involving the B pins. There is only a domain crossing from PD3 to PD1 because this signal is a feedthrough for PD2. This makes isolation on the B pins very different between CPF and UPF.

To isolate the B1 pin in the parent hierarchy:

CPF: create_isolation_rule –name ISO1 –from PD3 –to PD1 …
update_isolation_rules –name ISO1 –within_hierarchy u1/u2

UPF: set_isolation ISO1 –domain PD3 –applies_to outputs …

We must be very careful when we do this. If there is a mode where both PD2 and PD3 are shut off, then the isolation cell in u1/u2 cannot perform the isolation function.

To isolate the B2 pin:

CPF: create_isolation_rule –name ISO1 –from PD3 –to PD1 …
update_isolation_rules –name ISO1 –within_hierarchy u1

UPF: set_isolation ISO1 –domain PD2 –applies_to outputs …

Once again, we need to be very careful. PD2 is a feedthrough domain. It can be off and not affect the signal from PD3 to PD1. If we isolate the B2 pin, then it is possible to activate this isolation cell when PD2 is shutoff. This would end up blocking the signal from PD3 to PD2.

Correctly isolating the B pins is not an easy task in UPF. One must isolate the B2 pin when PD3 is off but isolate the C pin when PD2 is off. This requires different isolation policies with different isolation control signals. One must also figure out the correct list of pins to isolate or not isolate. However, this is very easily done in CPF:

create_isolation_rule –name ISOa –from PD3 –to PD2 …
create_isolation_rule –name ISOb –from PD3 –to PD1 …
create_isolation_rule –name ISOc –from PD2 –to PD2 …

In general, complex domain crossings is very difficult to specify in UPF. That job is best handled by CPF 1.1 or IEEE 1801.

–Luke Lang is a senior product engineering manager at Cadence.