Employ hierarchical methods for power intent specification(4)

Article By : Luke Lang

Another feature of power intent integration is to resolve conflicting power intent rules and remove redundant ones. 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 […]

Another feature of power intent integration is to resolve conflicting power intent rules and remove redundant ones. 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? Tools that automate integration, such as Conformal Low Power, need to resolve all of these issues during the integration process.

Finally, any discussion about hierarchical low-power design would be incomplete without mentioning two key CPF constructs C virtual port and virtual domain. Between them, these constructs allow us to specify power intent rules early in the flow for artifacts in the design that do not exist yet, but will be introduced later.

A virtual port is a low-power control-signal port that does not exist in RTL but will be added once the corresponding low-power 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 low-power 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 within it. 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.

The future
We have highlighted how CPF constructs can be used to specify power intent hierarchically, in low-power designs complex enough to benefit from a hierarchical approach. As discussed earlier, hierarchical power intent and successive refinement are also supported in UPF, especially by UPF 2.0 constructs defined in the IEEE 1801-2009 specification, but are not sufficiently supported by UPF 1.0, which is the Accellera version of UPF currently in common use. Since Cadence tools are used in both CPF- and UPF-based flows, we see designers being successful with UPF 1.0 in designs with simpler power architectures that can easily be handled flat, while companies needing to complete more complex designs are either using CPF or driving better tool support for UPF 2.0.

One of the main improvements added in UPF 2.0 is supply sets, which allows the supplies to power domains to be specified more abstractly. This is supported by an improved way of specifying power states. However, for specifying power intent of library cells and macros, UPF 2.0 still relies heavily on Liberty, and as explained in more detail in the EETimes article previously referenced, IEEE 1801 needs to evolve to include some of the advantages of CPF, such as library CPF constructs and the macro model. There is no barrier to achieving this, following Si2’s contribution last year of the CPF specification to IEEE 1801.

Hence, looking to the future, we expect two trends. First, the complexity of low-power designs will only increase, making hierarchical techniques to manage complexity more essential. Second, those designers using UPF will migrate quickly to use the improved hierarchical design provisions in UPF 2.0 once these are widely supported in available tools, then migrate further to future versions of IEEE 1801 that will support methodology convergence with CPF.

About the author
Luke Lang is an Engineering Director in the Cadence Low-Power Product Engineering group focusing on low-power architecture, methodology, and deployment. Before joining Cadence, Luke worked on ASIC and mixed-signal IC design and application at TI, Philips Semiconductor, and IBM. He received a BSEE degree from Santa Clara University, a MSEE degree from Stanford University, and holds two U.S. patents.

To download the PDF version of this article, click here.

Subscribe to Newsletter

Test Qr code text s ss