Hierarchical LP Design 3

By Luke Lang
Last month, I wrote in favor of top-down approach to coding the power intent. This month, let’s take a look at the bottom-up approach.

With the top-down approach, we code the full-chip power intent without having to worry about all the nets that cross power domain boundaries. Then we issue a few commands, and a tool writes out the block-level CPF. Pretty simple and straightforward! So, why would we want to code power intent bottom-up?

The most common reason is design re-use. Some designers take a building-block approach to assemble a SoC. Every block is a soft IP. It can be re-used in several designs or instantiated several times in one design. In these cases, it makes a lot of sense to take the bottom-up approach.

For bottom-up, one must architect the power scheme with a vision of how this block could be used. For example, a sub-circuit could be switched off to save power, so we need to create a switchable power domain. With a shutoff domain, we also need to create an isolation rule. Of course, boundary ports, state retention, and level shifting all need to be considered. Once the block-level power intent is coded, this block is ready to be used with all of the power-saving techniques that have been architected.

CPF has the concept of hierarchical integration. This is best explained with an example. We have a soft IP that has been architected to accommodate power shutoff. One instance of this IP will indeed shut off, but another instance will be always on. The manual approach to implement this would be to copy over and modify the CPF file to remove all references to switchable domain, isolation rules, and state retention for the always-on instance. The automated approach is to take advantage of the power intent integration capability in Conformal LP. When the always-on block is instantiated in the top-level CPF file, we can map the lower-level switchable domain to a top-level always-on domain. Conformal LP will understand this power intent and automatically remove all block-level CPF commands associated with the switchable domain.

Another feature of power intent integration is to resolve conflicting LP rules and remove redundant LP rules. For example, the block-level rule specifies isolation high, but the top-level has a conflicting rule to isolate low. What do we do? Even if there is no isolation output conflict, do we want to insert two isolation cells when one will be sufficient? Conformal LP resolves all of these issues during the integration process.

Finally, any discussion about hierarchical LP design would be incomplete without mentioning two key CPF constructs – virtual port and virtual domain.

A virtual port is an LP control signal port that does not exist in RTL but will be added once the corresponding LP cells are inserted. For example, when isolation cells are inserted, an isolation control signal must be connected to all isolation cells. This connection requires adding ports to every module hierarchy. We certainly don’t want to add these ports manually in the RTL. Once we split up the hierarchy, we must have a way to reference this port and the LP control signal that is driven from the top level. In CPF, we use virtual ports.

A virtual domain is a power domain that does not have any instances. This usually occurs in the top-level CPF, where a switchable domain is defined in the block-level CPF. The lower-level switchable domain is not visible at the top-level, but it must be referenced to specify power modes. Virtual domains are created in the top-level CPF and mapped to the lower-level real domains.

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