Home > Community > Blogs > Low Power > a call for power aware ip models
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Low Power blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

A Call For Power-Aware IP Models

Comments(0)Filed under: low-power, low power, PSO, voltage, shutoff, MSV, UPF, AVS, IP, power-aware, CPF, DVFS

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.

If 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.

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.