Hierarchical LP Design

A successful low-power design flow needs to do more than just automate LP design, verification and implementation.


By Luke Lang
The rapidly shrinking process geometry is a double-edged sword. It allows unprecedented integration of circuits. But it also produces leakier transistors, which is one of the main reasons behind the need for low-power design techniques. Therefore, a good low-power design flow must not only automate low-power design, verification, and implementation, it must also support hierarchical design methodology.

Two key and unique features of the Common Power Format (CPF) that support hierarchical design methodology are boundary ports and a macro model. They help the designer with different levels of abstraction at different levels of hierarchy. This is best illustrated with an example.

Let’s consider a team of three designers. The chip-level designer integrates in a processor. The processor designer integrates in a memory. The memory designer works at the lowest level of hierarchy and delivers an IP. Traditionally, an IP can be fully described by a .lib file containing timing and power tables. For low-power designs, .lib alone is not sufficient. Most IPs have complex power architectures that cannot be adequately described by .lib. CPF macro model can describe built-in isolation and complex power modes that are not supported by .lib. In addition to the memory IP and the corresponding .lib, the memory designer will also provide a CPF macro model.

The CPF macro model hides the details of the internal circuits by simply specifying the expected power domain of the input pins and driving power domain of the output pins. In the example below, the input pin X will drive into PD1 and the output pin Y will be driven by PD2. This makes pin X a boundary port of PD1 and pin Y a boundary port of PD2.


With the memory CPF macro model, the processor designer will know how to integrate and connect to the memory IP. The boundary ports of the CPF macro model will essentially specify the power domain of every data pin. For those memory pins with built-in isolation, the interfaces to these pins do not need additional isolation to be inserted. For those memory pins with different voltage level, level shifters will need to be inserted.

The processor designer also needs to understand how to interface with the chip-level logic. Once again, we use the boundary port concept to describe the expected power domains driving the inputs and receiving the outputs of the processor. The processor designer can code up a CPF design model to completely describe the power intent of the processor and treat it as a stand-alone chip. This CPF design model will sufficiently drive low-power verification and implement of the processor.

In the example below, pin X is expected to be driven from PD3, and pin Y is expected to drive PD4. In the processor’s CPF design model, pin X is a boundary port of PD3, and pin Y is a boundary port of PD4.


When the chip-level designer integrates the processor, he/she has two options. The most common option is to integrate in the entire processor design (RTL or netlist, depending on the design stage). This is sometimes called the “white box” or “glass box” model. When using this option, the boundary ports specified in the processor’s CPF design model are ignored. These boundary ports were intended to represent the “expected” driving and receiving power domains of the chip-level logic. After integration of the processor, the “real” driving and receiving logic are known, so processor boundary ports are not needed.

The second option for the chip-level designer is to “black box” the processor. This approach assumes that the processor has been designed and can be treated as an IP. Like the memory IP, the processor IP also must have a CPF macro model to describe the power domains of the interface pins. The CPF macro model hides the complexity of the processor and still allows verification and implementation based on power domains of the processor’s data pins. The main reason for this approach is to reduce verification and implementation runtime. However, it is strongly advised to verify with the full processor netlist as a sign-off check.

This provides a very brief and simplistic overview of hierarchical low-power design methodology. It is intended to introduce the concepts of CPF macro model and boundary ports. A complete discussion of hierarchical low-power design methodology must include power intent partitioning (top-down) and integration (bottom-up). They are good topics for future blogs.

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


Leave a Reply

(Note: This name will be displayed publicly)