Magic Blue Smoke


UPF Introduction

So far my posts have dealt with various power reduction techniques used by designers as well as some of the challenges faced using these techniques in the design flow.

Most of the complexity in using these techniques comes from the fact that we need to interpret virtual logical/physical power structures, since most of them are not specified in the RTL.

The implementation tools need to interpret these logical/physical structures based on the RTL and some tool specific commands. This leads to complicating verification flow in general. Can we prevent this additional complexity by adding these structures explicitly in the RTL ? That is the question!

All These days power intent/requirements are typically captured through a combination of:

(a) RTL
(b) TCL based tool specific commands
(c) Library model in Liberty Format
(d) Design Constraints file (SDC)
(e) Verilog Simulation models
(f) Customized Routines such as PLI’s for verification
(g) User Driven customized Assertions …..etc

If you look at the above list, the power intent/specification is available at many sources. There could be duplicates/redundant ones, which could lead to passing different set of information to verification/implementation tools. I think in the best interest of designing chips efficiently, power intent should be kept seperate from functional intent.

Fortunately, now we have a way to express the power intent through standards such as the Unified Power Format. I will try to take you through the complete flow from RTL to GDS implementation/verification using UPF, in my next few posts.

Briefly, the general idea of UPF is to keep your design Power Intent separate from the Functional Intent and to let each tool in the flow understand the power requirements through this format. Keep in mind that any Power Intent file is only representing your design’s power-related definitions. By itself, it will not guarantee an optimal low power design.

Guys jump in and let me know if you want to hear something in specific to UPF you are challenged with, while planning for your next chip.