Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Industry Insights > designer view getting the best use from static low power verification
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights 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: *

Designer View – Getting the Best Use From Static Low-Power Verification

Comments(0)Filed under: low power, broadcom, Cadence Theater, DAC 2014, static verification, Harshat Pant

Do you want assurance that your system-on-chip (SoC) netlists are "power clean?" In a recorded presentation on the Cadence web site, Harshat Pant, principal engineer at Broadcom, shows how static low-power verification can provide that assurance, and notes advantages, challenges, and best practices for this important technique.

Pant was a speaker at the Cadence DAC Theater at the Design Automation Conference (DAC 2014) in June, where over 40 speakers - mostly customers and partners -- offered informal half-hour presentations. Audio recordings and slides are now available for most of those presentations, including Pant's presentation, at the Cadence DAC microsite.

Pant first outlined the low-power implementation flow that Broadcom uses. It's a hierarchical flow based on the Unified Power Format (UPF). He then discussed the UPF to CPF (Common Power Format) translation that's done inside the Cadence Encounter Conformal Low Power static low-power verification tool. Finally, he talked about the advantages of using Encounter Conformal Low Power and the ways in which Broadcom engineers have learned to get the best value out of the tool.

Complex SoCs

As a supplier for makers of top-tier smartphones, Broadcom is very familiar with complex multi-voltage, multi-power domain SoCs. These SoCs may contain modems, 64-bit applications processors, GPUs, and a number of hard and soft IP blocks. An SoC could have as many as 45 or 50 power islands that switch on and off independently.

In his presentation, Pant described the "hierarchical UPF" power implementation flow used at Broadcom. "We start with UPF for each block, and then we take each block through the whole implementation flow," he said. "That block becomes a standalone entity, and in the end we combine it with the top-level UPF." Broadcom is currently using the Accellera UPF 1.0 standard but is also starting to borrow some constructs from the more recent IEEE 1801 UPF standard. (The latest standard is IEEE 1801-2013 or UPF 2.1).

Broadcom engineers do a UPF to CPF translation inside the Encounter Conformal Low Power tool. Pant noted that Broadcom uses CPF for a number of things, including RTL power-aware dynamic verification, power-aware logic equivalence checking, and low-power static verification. The translation involves a three-step process. These steps include pre-processing the UPF file, performing the translation itself, and post-processing the CPF file.

A Tricky Translation

The most challenging part of Broadcom's static low-power verification flow is preparing the "golden CPF" file, Pant said. Why are pre-processing and post-processing necessary? "There are some differences between UPF and CPF that cannot be directly translated," he said. "At times it needs some hacks that are not part of the tool."

Pant provided some examples of cases in which UPF pre-processing is needed. For example, suppose you have a 1.8V PLL with some virtual power supplies inside it. In conventional UPF there is no way to tell the tool what these supplies are related to in the outside world. It's thus necessary to add several lines to UPF code that tell the tool (for example) that the internal virtual supplies are the same as the outside core supplies.

CPF post-processing, Pant said, is the "biggest pain point right now and the biggest part of our time in the UPF to CPF conversion." Part of this step is adding in back biasing information. UPF 1.0 does not have the semantics to define back biasing, so this must be added into the text manually.

UPF 1.0 does not have the semantics to define externally switched domains, so the constructs that define external shutoff conditions have to be added to CPF. Another issue is that the "full off" power condition is not exactly the opposite of the "full on" condition of UPF 1.0. Designers have to post-process the CPF to change the domain shutoff function to match the inverse of the UPF full-on definition.

Pain Relief

Once the golden CPF is created "the pain part of it is gone" and the Encounter Conformal Low Power run is "straightforward," Pant said. "It's a very comprehensive tool and it catches all known issues of power implementation," he noted. "We are very confident that when we use Conformal Low Power on a power-aware netlist, and the whole report is qualified, that there are no real bugs still pending in the netlist."

Pant said that Encounter Conformal Low Power easily catches issues like incorrect buffering of control signals of NOR-type isolation cells. The tool can also quickly catch transmission gate issues without a lot of additional setup. The tool offers fast runtimes and good capacity, but it may not be able to read in a full-flat SoC netlist, he said.

There are several challenges with static low-power verification. First, golden CPF creation is a complex process, and it requires a knowledge of issues and workarounds. UPF 1.0 and CPF are very different, and while IEEE 1801 UPF 2.0 is an improvement, vendor tools have varying levels of support. And iteration over multiple back-end databases remains an issue because the UPF to CPF translation cannot always be scripted.

Pant recommended the following "best practices" for using static low-power verification:

  • Full-flat checks are difficult, so break the problem down into checks for the individual place-and-route blocks and then run one full check at the top level with power-aware .lib (Liberty) elements at the bottom level
  • One issue that remains is the presence of transmission gates at the inputs of place-and-route blocks. One way to clean this up is to "hack" the UPF blocks to have a more SoC-centric view of inputs so Encounter Conformal Low Power can catch any transmission gates.
  • Use IEEE 1801 constructs like find_objects along with TCL in UPF to reduce the size of the file and to reduce the chances for error
  • Don't ignore warnings
  • Be careful with Encounter Conformal Low Power waivers. Given the amount of information that Encounter Conformal Low Power reports, it may be tempting to write generic waivers for various issues. These can prove fatal because further iterations may not test them. Don't add a waiver without completely understanding the problem.

The IEEE 1801 group is working on UPF/CPF interoperability and, in the long run, towards "convergence" into a single standard. This convergence "is the way forward that will eliminate the complications that arise out of power format conversions," Pant said.

To listen to this presentation and see the slides, click here and scroll down to 5:00 pm Monday June 2. No registration is required.

Richard Goering

Related Blog Posts

DAC 2014 Cadence Theater - Customers, Partners Outline Challenges and Successes

DAC 2014: 30+ Customer, Partner Presentations Now Available on Cadence.com

Video: What the Newly Approved IEEE 1801-2013 Low Power Format (UPF 2.1) Includes

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.