Experts At The Table: Low-Power Verification

By Ed Sperling
Low-Power/High-Performance Engineering sat down to discuss power format changes with Sushma Hoonavera-Prasad, design engineer in Broadcom’s mobile platform group; John Biggs, consultant engineer for R&D and co-founder of ARM; Erich Marschner, product marketing manager at Mentor Graphics; Qi Wang, technical marketing group director at Cadence; and Jeffrey Lee, corporate application engineer at Synopsys. What follows are excerpts of that conversation.

LPHP: What’s new in the 2013 version of the UPF 1801 standard and why was it so necessary?
Biggs: We addressed a number of issues with the 2009 standard. But we also took the opportunity to improve the semantics and syntax, we cleared up the existence of a lower boundary on power domains and we cleared up precedence rules. We also identified some constructs to facilitate better interoperability and added in some new features. We new have improved macro cell modeling. Although that could be done in the past, the way it’s done now is clearer and crisper. We also have new sections on attributions of pins and cells in the library.
Marschner: This may sound like a laundry list. We have made many changes that appear to be small changes, but they all integrate fairly well. The goal was to improve a number of things, such as the fine-grain control that users have over specifying what their low power strategy is and how it’s applied to the design. Second, the fidelity of the modeling, such that what they specify actually represents what will happen in hardware. For example, one of the changes we made was in the modeling of retention registers, which can be very detailed in their behavior. We have much more focus on modeling the behavior represented in the specification so users can understand how to get the behavior they want by controlling things in a particular way or by using objects in a particular combination. The third thing we focused on is the incremental nature of design, implementation and verification. We put a lot of effort in taking the capabilities in UPF 2.0 for incremental specification and incremental refinement and extending them to provide even more levels of incremental specification, implementation and verification along the way.

LPHP: We’ve been heavily focused on the mobile world, where energy efficiency can save hours of battery life. Now the mainstream is beginning to focus on the same power-related issues as those encountered at the most advanced nodes. What does this mean for them?
Biggs: Power is now a prime design constraint for everyone.
Honnavara-Prasad: The first consideration is that this is a system-design problem, not just an implementation or an architecture problem. You need to save power at all levels, from the architecture to the design, and to be able to verify things up front. When you’re dealing with things like power gating and state retention, there are a lot of opportunities for introducing design bugs. That’s why you want to be able to verify this early on. It puts a lot of stress on how you verify the design, how you guarantee coverage, and there is more emphasis on hardware-software co-verification or emulation. You need to be cognizant of how software affects power. Because power management is so intrusive it affects every phase of the design, whether it’s RTL or sensors or DSPs. Nobody is spared. You just have to adapt to it and adopt a power-management strategy. A standard like 1801 helps us combine all these different phases together. It also allows interoperability—especially between multiple vendors. You want to be able to hand off one phase of a design and not lose information in the process, making sure that what you verified is what you’ve implemented.

LPHP: What’s still missing from the power format?
Wang: One trend we’re seeing is that more and more small companies are doing low power. Previously it was only the big design houses doing complex designs. For those small companies, the standard is helpful but the most important thing is to get the methodology right. One good thing about the new version is that it has an appendix for low-power design methodology. That gives you a very big head start to get into the right methodology and then leverage the standard for a low-power design.
Marschner: Over the last 30 years we’ve been developing new technology and methodologies at various stages. When hardware-description languages were new, and most people were doing designs with schematics and schematic capture, there was a lot of resistance to adopting hardware-description languages. Many times I hear, ‘I don’t want to be a programmer. I want to be a designer.’ That has changed quite a bit. The same is happening with power intent. There’s a migration from ad hoc methods people developed internally—and in many cases it’s the large companies that developed sophisticated ad hoc proprietary techniques—to more standard techniques for power management and development and verification of power-managed designs. That needs to be captured in UPF. There’s a need for coming up to speed on what methodologies have been working, and that’s where the standard comes in. What we’re doing is taking ideas that come from many places on how power management can be done most effectively. That’s what the standard encompasses. Becoming aware of the terminology, concepts and approaches that are out there is essential for users, because that’s the way to adopt the best methodologies and practices that the industry as a whole has developed and incorporated into the standard.

LPHP: Power formats involve everything that was done wrong as well as what was done right. Where are we now with UPF 1801 and CPF?
Wang: A lot things need to be looked at before the format. A good example of that is IP. Before you start a low-power design, you need to look at the IP, because that can impact the design and the low-power architecture. The new release of the standard does significantly improve the interoperability between CPF and UPF. But what makes them both useful is for all the EDA vendors lining up under UPF 1801 with all the new features so we have true interoperability.
Marschner: You can’t ever have one approach to something. There is thesis-antithesis at worst, and there are often many environments in which we have competing approaches. The goal is to push the envelope in many directions and develop new ideas, and eventually to come together to provide the best solution for a community. Just as VHDL and Verilog co-existed for many years and have come together in SystemVerilog, we’re on the right track with UPF and CPF.
Biggs: A few years ago a colleague of mine used to joke that UPF and CPF were the same in every intent and different in every detail. With UPF 2.1, I’m not sure that people are aware that in 2011 Si2 contributed the entire text of UPF 2.0 to the IEEE for our consideration. During the development of UPF 1801 2013 we were looking at the way that works. CPF is not converging with UPF—that’s too strong a statement—but there is a degree of methodology convergence. We’re on the path of convergence. We haven’t gotten there yet, but it’s moving in the right direction.