Virtual LP

By Luke Lang
Several months ago, I introduced the concept of virtual domain in association with hierarchical CPF. It is a relatively simple concept with a concise definition. It is powerful and flexible in supporting large designs with complex power architecture and hierarchical power intent. However, to the UPF coders, virtual domain is sometimes a mystery. I hope this blog will clear up any possible confusion.

A virtual domain is a power domain that does not have any instances.

I will illustrate the importance this concept with three scenarios. First scenario is based on low-power IP. In the example below, a low-power IP cell is instantiated three times. The diagram shows the internal power structure of the IP cell, but it is treated as a black-box in the design.

Instances u1 and u2 are switched off by the same control signal, en1_b. Therefore, the net driven by u1 into u2 is not a domain crossing and does not require isolation. Instance u3 is switched off by en2_b. Therefore, the net driven by u1 into u3 is a domain crossing. If u1 can be switched off while u3 is on, this net will require isolation. Virtual domain helps us describe this power architecture clearly to enable low-power verification and implementation.

To use an IP cell, we will use a CPF macro model to describe the power architecture.

set_macro_model IP_cell
…
create_power_domain –name PDsw –boundary_ports {in out} \
-shutoff_condition en_b …
…
end_macro_model

PDsw is inside a CPF macro model and is not visible at the top level. To represent it at the top level, we will create a virtual domain and map PDsw into it.

create_power_domain –name PDv1 -shutoff_condition en1_b
create_power_domain –name PDv2 -shutoff_condition en2_b

set_instance u1 –model IP_cell –domain_mapping {{PDsw PDv1}}
set_instance u2 –model IP_cell –domain_mapping {{PDsw PDv1}}
set_instance u3 –model IP_cell –domain_mapping {{PDsw PDv2}}

PDv1 and PDv2 are virtual domains because they don’t have any instances. For u1 and u2, the internal PDsw are mapped to PDv1. For u3, the internal PDsw is mapped to PDv2. Once they are mapped, we can specify isolation rules for domain crossing.

create_isolation_rule –name ISO1 –from PDv1 –to PDv2 …

With UPF, it is not possible to describe this power architecture because UPF does not have the concept of macro model or virtual domain. Isolation can be specified for the input of u3, but the UPF code cannot explain why isolation is needed. Also, there is no way to verify it structurally because there is no way to describe which internal domains are switched off together.

The second virtual domain example is based on block-level boundary ports. In the diagram below, block u2 has a switchable domain. At the u2 block level, the input port IN must be associated with a power domain.

In UPF, IN can only be associated to one of the existing power/ground pair. A non-standard command is used to describe this.

set_related_supply_net –object_list {IN} –power VDD2 –ground VSS

Once we take u1 into consideration, we can see that IN is not associated with VDD2/VSS. It is, in fact, associated with VDD1/VSS. This discrepancy can cause some confusion in the best case and perhaps design error in the worst case.

Using CPF at the u2 block level, a virtual domain can be defined with IN as a boundary port. Now, a level shifter rule can be defined based on the virtual domain.

create_power_domain –name PDsw –shutoff_condition en_b …
create_power_domain –name PDv –boundary_ports {IN}

create_level_shifter_rule –name LS1 –from PDv –to PDsw

At the top-level, PDv will be mapped to the power domain associated with VDD1/VSS. If the VDD1/VSS domain has the same voltage as VDD2/VSS, then the CPF integrator will optimize away the level shifter rule. If not, the level shifter rule will ensure electrical compatibility at this domain crossing.

The third virtual domain example will help to explain one difference between CPF and UPF coding. We will use the previous example and focus on VDD2 in block u2. In UPF, VDD2 is just a supply port and supply net that drive into the power switch. There is no power domain associated with VDD2/VSS. Instantiation of block u2 at the top level simply requires connection of the VDD2 supply port. In CPF, instantiation is done based on domain mapping. Therefore, a virtual domain must be defined in block u2 for the VDD2/VSS pair. If you ever find different number of power domains between CPF and UPF power intent, this is probably the reason.

–Luke Lang is engineering director at Cadence Design Systems.