Golden Power Intent

By Luke Lang
A few months ago, I wrote about the rapid adoption of the power intent file for low-power designs. While this is certainly a step in the right direction, some design teams may be taking several steps backwards by not treating the power intent file with the proper respect. For example, I have seen one case where the verification, synthesis, and backend implementation teams each had their own power intent file. And these three power intent files were all different. This leads me to wonder what they were designing.

From the very beginning, we have been advocating the concept of a golden power intent file. A power intent file must be verified first and determined to be golden before it can be used to drive implementation tools. This is because the power intent file has a direct impact on the low-power cells inserted in the design. And we all know about garbage in, garbage out. Therefore, it is only natural to make sure that we don’t have garbage in.

Even with a golden power intent file, we could still get garbage out. This might be caused by a bug in the implementation tools or a human mistake in the implementation steps. Therefore, it is extremely important to verify the netlist from the implementation tools and make sure that all of the low-power cells are correctly inserted. We do this verification by making sure that the design is consistent with the golden power intent file.

If the power intent file is changed for any reason, the above steps must be repeated to ensure the correctness of the power intent file and consistency with the design.

This concept was really borrowed from the golden RTL concept. Typically, the RTL is verified through simulation and determined to be golden. After that, it is synthesized into a netlist. This netlist is then verified against the golden RTL using logic equivalence checking. The RTL is usually checked into some sort of repository. A designer cannot modify the RTL unless it has been checked out. After modification, he/she needs to run through the regression tests to make sure nothing has been broken. Upon successfully completing the regression runs, the RTL is checked back into the repository. Synthesis is run using the RTL in the repository.

Verifying the power intent file and then re-verifying the netlist against the golden power intent is what we call closed-loop verification. It is a very simple but crucial concept. Yet, it is sometimes difficult to convince designers to follow it. There are even tools that will accept power intent commands entered on-the-fly from the command line prompt. Designers have told me that this “feature” allows them to try out different power intents. Well, what good is this if they don’t know whether the power intent is any good? I’m sure these designers would not change RTL on-the-fly just to try it out. Why would the power intent be any different?

Yes, there are exceptions to every rule, and one size does not fit all. When it comes to low-power design, follow a proven flow. Make an exception only when you have to, not just because you can. Understand the full impact of this exception and then re-run all of the verification steps. Make your power intent golden and close the verification loop. Your chance for success will go way up.

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