Hierarchical LP Design 2

By Luke Lang
Last month, I discussed two key features of the Common Power Format (CPF) that support hierarchical design methodology: boundary port and macro model. These are commands that need to be written to describe the power intent and drive the tools. Without these commands, it is extremely difficult to do hierarchical design. But with these commands, hierarchical power intent files are not always easy to write and will need tool support.

For a hierarchical LP 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 full-chip power intent is first coded and verified (through LP structural and functional checks). After successful verification, the full-chip power intent is partitioned and written 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 first coded. After that, the full-chip power intent is formed by merging all the block-level power intent files.

I firmly believe that top-down is the right way to go. First, coding the full-chip power intent is much easier than the block-level power intent. 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 and not have to worry about exactly how many nets are crossing these domain boundaries. With today’s design complexity, a sub-block can easily have more than 10K ports. Does anyone in his/her right mind want to trace these ports and manually determine the power domains (boundary ports)?

Second, in a top-down flow, the full-chip power intent has already been verified. Any block-level power intent generated/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, we also must also go through several iterations of merging and verifying of 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.

If I have not convinced you by now, your next question will surely be 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 and the design (RTL or netlist), 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, etc. This is very similar to characterizing timing of a sub-block and writing out a block-level SDC. And this has been used by many design teams for a long time.

In reality, today’s LP designs are far too complex and highly integrated to use a purely top-down flow. These designs use a wide variety of LP IP blocks that are described by macro models. The chip-level power intent must instantiate these macro models, which has some bottom-up flavor. Since these macro models are usually pre-written and pre-verified, we will not complicate the issue.

So, are there designers that use the bottom-up flow? Yes, because they don’t have the tool to help them partition the full-chip power intent. But if you look closely, they have already done a full-chip power intent either in their head or on some drawing. It is just not possible to code a block-level power intent without a full-chip power intent in one form or another.

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