Power intent formats exist to express the design's low power
techniques separately from the design's functional description. This promotes
portability of the design across different power schemes. So why are most
commercial IP providers forced to bury this critical information deep in
gate-level simulation models and library files?
Advanced low power design techniques, such as Power Shut-Off
(PSO) with or without retention, Multi-Supply Voltage (MSV,) and Adaptive
Voltage Scaling (AVS) are becoming common in today's designs. Over the last
couple of years, the industry has adopted either of two leading formats to
express the parts of the design these techniques apply to (power domains), and the
circumstances in which voltages can be reduced or switched off (power modes).
From this information, collectively known as "power intent", the control logic
and structure to implement the techniques can be derived. The two power intent
formats are the Unified Power Format (UPF) and the Common Power Format (CPF).
Why keep power intent separate from the RTL description of the design in a
dedicated file? It's to promote easy reuse of the design blocks in different
designs that may have very different power intents.
However, commercial IP blocks including processor cores,
graphics blocks, display drivers and interfaces make up an increasing
proportion of today's designs. These are often complex enough to be
pre-designed with appropriate advanced low power design techniques embedded in
the IP. There may be multiple power domains needing multiple switched and always-on
supply rails, and you need to understand whether the I/O ports of the IP blocks
have isolation or level shifters built in, or not, in order to successfully
integrate these into your design.
Some IP -- particularly processors -- may
implement advanced techniques like dynamic voltage and frequency scaling
(DVFS). Memories may have a retention mode, with lower voltage levels and
back-biasing to control leakage. Where these are hard IP blocks, the power
intent is buried in the netlist and the cell information (commonly in .lib
format) and (if you're lucky) is modeled in the Verilog gate-level simulation
model. But there's usually no separate power intent file, which means designers
often struggle to integrate the block with the design's overall power intent
without going to simulation at the gate level.
Recently, CPF has been extended with some constructs to
allow an IP block provider to describe the types of power domains, multiple
types of supply voltage ports, and input/output ports with and without
isolation, level shifting and retention. We refer to these constructs as macro modeling. Now a separate power
intent file can be provided with the IP block. What's the advantage? It allows the
IP integrator to move the power intent integration and verification earlier in
the flow from the gate-level to the RT-level. In short, it enables power-aware
simulation of the IP at RTL. Additionally, analog IP blocks can be handled the
same way, enabling a consistent solution for digital and mixed signal designs.
you rely on .lib to understand the power intent, then you can only use tools
that read .lib. That's too late in the flow to verify correct IP integration. That's why power-aware IP models are needed.