Power Panel: IP And Other Key Issues For Future Development

By Ed Sperling
Low-Power Engineering chaired a DesignCon panel of low-power experts with Bhanu Kapoor, president of Mimasic; Kesava Talupuru, DV engineer at MIPS; Prapanna Tiwari, CAE manager at Synopsys, and Rob Aitken, an ARM Fellow. What follows are excerpts of their presentations and the panel discussion that followed.

Prapanna Tiwari: UPF and CPF are text files that capture the power intent of the design.

Power management is one of the main problems we’re trying to solve in every design. The goal is to operate every given part of the chip at the lowest voltage you can get away with. If you can shut it off, you do that. If you can’t shut it off—and you can’t shut off memories—then you reduce the voltage to the lowest possible level so you don’t lose as much through leakage. From a verification standpoint, what you used to write in Verilog would appear in silicon and that was all there was to it. That’s no longer true. Now there is this idea of power intent that has to be captured. It has structure to it. It has semantics, and it has simulation sequences. It impacts every part of a design. (See Fig. 1)

Fig. 1

The product behavior has two components. One is the design. The other is the power. Verification needs to take care of this.

The power intent itself has two aspects. One is static. What are the regions? How are the regions partitioned? How do they map onto my design hierarchy? That’s where UPF comes into play. It says these are the domains. These are the different level shifters you’re going to insert in your design. That’s the structure.

But there’s a second aspect, which is dynamic. How are you going to exercise these different voltage regions on a chip? What is allowed, what isn’t allowed? If ARM or MIPS delivers cores to their customers, they need to let them know here’s how you should use it. There is no way in our current methodology, when you deliver a Verilog model, what voltage levels its supposed to be instantiated at. There’s nothing in Verilog that lets you do that. Different customers will use ARM and MIPS cores using different power management techniques, different voltage levels, different process nodes. How do you let them know you’re not supposed to do certain things?

If an IP can provide constraints that you can’t use IP in a different way, that’s where power intent comes in. You can do that from a functional standpoint today. You cannot do that it in a power-aware model. There’s no way to figure out where IP gets used. Context is missing. (See Fig. 2)

Fig. 2

Even within the same semiconductor company you will see different modules have different design owners. You don’t want anyone to be using IP in the wrong way even years from now. There is IP in designs where no one has any clue where it came from. That’s one of the key challenges for an IP provider—to generate behavioral and verification IP, not just with the VHDL view but with the power-aware view to go with it. If you can deliver this, it will eliminate an enormous amount of risk that it will reduce the cost.

For any verification, there are three pieces. There is the testbench, the design itself and then assertions and coverage. (see Fig. 3)

Fig. 3

In the overall verification, the testbench needs to be power-aware. IP users need to be able to monitor any region of the design. The way IP is growing, it may have many power domains inside. It may even have its own power controller that reacts to events from outside the IP. A customer testbench needs to know power events and sequences in different parts of the IP. Otherwise you have no idea if the IP really shut down or not.

You also need to be able to write models for the IP. One user may be at 1.2 volts. Another might be at 1.0 volts. Different signals will react differently. All this behavior needs to access the power information.

All of that power information needs to be available, and it should be context-free. And last but not least, assertions need to be power-aware. When the system is shut down, how is the IP being isolated, what are the level shifters being inserted?

To solve this, you need to be able to merge UPF and HDL into one. In your RTL you should be able to query information and build models around it.

Rob Aitken: If it’s not clear what are the issues are involved, what would make it clear?

There’s an existence proof. In one chip we had some RTL and a power spec and it turned into a chip and the chip worked. There were multiple decades of ARM experience, the latest IP and EDA tools, access to IP designers, skill in all available EDA tools and some magic smoke. But what if you don’t have all that? How many of those things do you need?

In addition, there’s no one thing called IP and there are lots of different uses for the same IP. There’s one group that says, ‘Whatever it is, give it to me, I want it to work and be done.’ Then there’s another group that might say, ‘I don’t care what you think should be done with this IP. Give me the parts and I’ll do it myself.’ What we really want to make sure of is that the standards don’t interfere with the use models and that they cover all of the possible use cases.

Context also matters. We like to talk about something like an always-on buffer. If it’s in a system where there’s a battery connected to it and part of the processor is shut down, that has a different meaning than when it’s plugged into the wall and the system is turned off. That always-on buffer isn’t always on anymore. It’s just sometimes on.

And what happens if I run my IP at 0.6 volts? If no one designed it for that, will it work? Maybe.

There are all sorts of other clever things we can do. An SRAM will retain data at much lower voltage than you can read or write it. You can have SRAM-dependent behavior. If it operates at a very low voltage you can store data, but if you write it, it will fail. Trying to model that in a high-level language is an interesting challenge.

From a soft IP standpoint, you can say here’s some RTL and here’s a power description. You only need four things:

1. What are the atomic power domains? Are there more than one?
2. If you shut it down, some key element of the state needs to be retained. If you haven’t thought about that initially, it’s pretty much every flip-flop.
3. You need to know the signals that need to be isolated.
4. And you need to know the legal power states and the transitions between them.

If you have those four things you have the power intent for soft IP. That’s not enough to actually build something. Then you take the low-power intent and refine it. (see Fig. 4)

Fig. 4

Based on the various failures we’ve had, here are some things not to do. First, avoid non-contiguous power domains. When in doubt, align it with the logic hierarchy.
Second, don’t use clock gating on both ends of the clock. That ties you to specific libraries. Third, avoid partial retention within a power domain. Don’t try to retain some things but not all. It leads to weird behavior. And make sure that your power domains clocks and resets can be controlled externally. One other thing I would add is avoid test power or scan chains crossing multiple domains because that leads to interesting test challenges.