Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Power/Alternative Energy
Power/Alternative Energy??

Employ hierarchical methods for power intent specification

Posted: 19 Oct 2012 ?? ?Print Version ?Bookmark and Share

Keywords:power intent? hierarchical design? macro modeling?

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, 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 subsystem. The memory designer works at the lowest level of hierarchy and delivers a memory IP block. This arrangement is illustrated in figure 1.

Figure 1: An illustration of the arrangement of a team of three designers.

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.

Figure 2: 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.

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 figure 2, 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.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page

Article Comments - Employ hierarchical methods for powe...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top