The intent of this design article is to provide a comprehensive tutorial on both the value of and the “how to” in using a hierarchical low-power design methodology. The article first shows how to express power intent top-down in a hierarchical design, which allows the designer to set rules abstractly without worrying about the details of all the power domain crossings lower in the design hierarchy. The article then describes the concept of macro modeling to capture power intent for IP blocks. Next, it illustrates a bottom-up hierarchical approach that enables the designer to integrate the same block in multiple situations that require different uses of the block’s internal power intent capabilities. Finally, the article describes how to use virtual ports and virtual power domains to simplify specification of rules for design objects that will later appear lower in the hierarchy, as the design implementation is refined.
Although the Common Power Format (CPF) is used as the main format to illustrate these capabilities, not all of these hierarchical capabilities are truly unique to CPF. The hierarchy support currently provided in the IEEE 1801 standard, Unified Power Format (UPF) 2.0, is also covered. The article concludes by reviewing recent developments toward methodology convergence between the Silicon Integration Initiative Low Power Coalition, which is responsible for CPF, and IEEE P1801.
Why is hierarchical low-power design necessary?
Semiconductor companies today are able to produce integrated circuits (ICs) of unprecedented scale, with tens to hundreds of millions of transistors on a single die becoming commonplace. This complexity, enabled by rapidly shrinking process geometries, which relentlessly continue to obey Moore’s Law, is a double-edged sword. It allows unprecedented integration of circuits, enabling many different functions to be integrated in a single system on chip (SoC). But it also produces leakier transistors, driving the need for low-power design techniques (such as power shutoff or power gating) that specifically address leakage power.
Complex SoCs are designed hierarchically, with many different low-level functions integrated together into sub-systems, which in turn are integrated onto the SoC. Therefore, a good low-power design flow must not only automate low-power design, verification, and implementation—it must also support a hierarchical design methodology. In practice, hierarchical design is almost always a combination of top-down specification and bottom-up integration, with partitioning of design tasks, some of which are designed from scratch and others are provided by reused IP blocks in the form of hard or soft design macros. The blocks are integrated and verified bottom-up, but along the way, the designer must validate that the integrated design (the result of the bottom-up integration) fully meets the system specification. Thus, functional design and verification for these SoCs tend to be iterative, working both top-down and bottom-up to divide and conquer the massive quantity of details, while maintaining a clear view of the whole SoC.
The same approach works for power intent specification too. The low-power architecture, consisting of power domains, their states, and the resultant power modes, follows from the top-level system functionality and architecture, and is specified top-down early in the process. However, to be able to design leaf-level functions and integrate IP blocks that fit into this architecture, and to verify them, we must also have a hierarchical understanding of power intent. The following sections show how to describe and use power intent for top-down design, IP blocks and macros, and bottom-up design.
Top-down low-power design
For a hierarchical low-power design, one of the first decisions that we must make is whether to code the power intent file in a top-down or bottom-up fashion. In a top-down flow, the designer codes the full-chip power intent and verifies it through low-power structural and functional checks. After successful verification, the designer can partition the full-chip power intent and write it out for each sub-block. The block designers take these block-level power intent files and implement the sub-blocks. In a bottom-up flow, the block-level power intent is coded first. After that, the full-chip power intent is formed by merging all the block-level power intent files.
We discussed earlier how the power domains, states, and power modes tend to follow from the high-level system functions and architecture. This implies that top-down is the way to go, but there are other reasons that often make top-down the best choice. First, coding the full-chip power intent is much easier than coding the block-level power intent. The reason is that we can use abstraction and successive refinement to our advantage.
What this means is that we can code only the information needed for the stage we are at in the design flow, and details pertaining to lower-level blocks can be added later when we get there. For example, we don’t need to deal with the boundary ports of the internal power domains. We only need to specify isolation or level shifter rules between power domains, not worry about exactly how many nets are crossing these domain boundaries.
With today’s design complexity, a sub-block can easily have more than ten thousand ports. Tracing all of these ports and manually determining the power domains from the bottom-up would be a daunting and prohibitive task. Abstract specification and successive refinement of power intent is supported by both leading power format standards: IEEE-1801 (UPF) and CPF. However, for reasons more fully explained in an EETimes article published earlier this year , this hierarchical approach is poorly supported in the UPF 1.0 subset of IEEE-1801 that is still currently in widespread use.
Second, in a top-down flow, the full-chip power intent has already been verified. Any block-level power intent generated or derived from this known-good full-chip power intent must also be golden to drive the sub-block implementation. In a bottom-up flow, not only is the block-level power intent difficult to code, but we also must also go through several iterations of merging and verifying the full-chip power intent. For example, if we specified an incorrect boundary port at the block level, there is no way we can verify and debug this until we interface with the other blocks’ power intent.
A frequently heard objection to this top-down approach (and justification for a bottom-up approach) runs something like “You have to code the block-level power intent anyway for the block designers.” This is where the tool support comes in. With a full-chip power intent file and the design (at the RTL or netlist level), a tool should be able to trace the design, establish the power domains, and write out the block-level power intent automatically. It can figure out all the boundary ports, where isolation rules should be specified, and so forth. This is analogous to a hierarchical synthesis methodology that involves characterizing the timing of a sub-block and writing out the block-level constraints in a standard delay constraint format. And this practice has been used by many design teams for a long time.
In reality, today’s low-power designs are far too complex and highly integrated to use a purely top-down flow. These designs use a wide variety of low-power IP blocks that are described by macro models. The chip-level power intent must instantiate these macro models, which thus introduces some bottom-up flavor. These macro models are usually pre-written and pre-verified, and we will describe how this is done in the next section.
So, do some designers use the bottom-up flow? Yes, often because they don’t have the tools to help them partition the full-chip power intent. But if you look closely, they have already created a full-chip power intent either in their head or on some drawing. It is just not possible to code power intent at the block level without an understanding of the full-chip power intent in one form or another.
Describing and integrating power intent for design macros
Two key features of CPF that support hierarchical design methodology are boundary ports and macro models. 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 a processor at the top level. The processor designer integrates a memory into the processor sub-system. The memory designer works at the lowest level of hierarchy and delivers a memory IP block. This arrangement is illustrated below.
Traditionally, a library cell can be fully described by a .lib (Liberty) file containing timing and power tables. For low-power designs, .lib alone is not sufficient. Complex IP blocks such as embedded memories often have complex power architectures that cannot be adequately described by .lib. A 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’s 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 levels, 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 standalone chip. This CPF design model will sufficiently drive low-power verification and implement of the processor.
In the example below, pin A is expected to be driven from PD3, and pin B is expected to drive PD4. In the processor’s CPF design model, pin A is a boundary port of PD3, and pin B 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 the entire processor design at the chip level (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 block. 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, we would strongly advise the designer in this case to verify with the full processor netlist as a signoff check.Bottom-up low-power design
While there are some advantages of a top-down approach to coding the power intent, in reality, a combination of top-down and bottom-up approaches is often required. Now, let’s take a closer look at the bottom-up approach.
To recap, 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 reuse. Some designers take a building-block approach to assemble an SoC. Every block is a soft IP. It can be reused 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 design, we 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 EDA tools such as Cadence® Encounter® Conformal® Low Power. 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 Low Power 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 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 – 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.References
Chau, Dobre, Hardee, Holehouse & Lagerquist, Power Intent Formats: Light at the End of the Tunnel? EETimes, 2/13/2012Author: Luke Lang
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.
This posting is part of the EDA Designline
power series and is archived and updated. The root is accessible here
. Please send me any updates, additions, references, white papers or other
materials that should be associated with this posting. Thank you for making this a success - Brian Bailey.