Experts At The Table: The Trouble With Low-Power Verification

By Ed Sperling
Low-Power/High-Performance Engineering sat down to discuss low-power verification with Leah Clark, associate technical director at Broadcom; Erich Marschner, product marketing manager at Mentor Graphics; Cary Chin, director of marketing for low-power solutions at Synopsys; and Venki Venkatesh, senior director of engineering at Atrenta. What follows are excerpts of that conversation.

LPHP: What’s missing these days from low-power verification.
Marschner: I would like to see the industry focus more on thinking about what we’re doing, rather than expecting a tool to be a magic solution.
Clark: Higher levels of abstraction will help. The details are great, but to verify those details are correct we need an abstracted view that is more comprehensible by the team as a whole.
Marschner: Abstraction does help, but it also introduces new translation layers. It helps everyone get on approximately the same page so they’re well prepared to get down to the next level. But abstraction doesn’t solve the problem by itself.

LPHP: But you have to start somewhere, right? In the past, the starting point for power wasn’t at the architectural level.
Chin: Power isn’t what we’re used to abstracting at a high level. But that’s one of the reasons why this idea of a complete top-down approach for any problem isn’t realistic. You have to understand where you’re going, and in all of our methodologies and algorithms you always pop back and forth. That’s what we’re doing with UPF and power, in general. We understand more of what should have been in UPF 1.0, so we’re putting more of that stuff in. It gives us better capability of being able to specify at a higher level with less detail, but we still have some kind of assumed outcome at the lower level. It’s that process we have to iterate through several times before we get it right. That was the case with RTL, as well.
Venkatesh: Now you can do supply sets and match attributes. That’s an abstraction, but it’s a great beginning.
Marschner: There are more significant areas of abstraction, such as power states and domains and even whole IP blocks. That allows you to start at an abstract level when you’re not even thinking about what technology you’re using, what routing you’re going to do, how you’re going to implement the supply network. But that evolution of the high-level abstraction to get everyone on the same page, and the mapping down to the details is critical. As an industry, we have to have a better understanding of that hierarchy of abstractions and mapping, because that’s what enables people to use tools effectively. If you write something you don’t understand, it’s very easy for someone to interpret it in a different way.
Venkatesh: Some of that is subtle and tricky. Some of it is really straightforward. We need to have more of this, though.
Clark: It’s really good to talk about what’s going to happen in the future, but in my job I need to know where to go today and tomorrow and for final synthesis next week. One of the problems we have is that the power intent will change based on context. We have a lot of very large IP blocks. In some groups they expect UPF to be delivered with RTL. That makes sense if the power intent is fully contained within the IP, but a lot of time the power intent of the IP changes in the context of the chip. For example, you may have a chip where the analog and the digital are at the same voltage and you may have a chip where they are not, or where the digital is on or off or higher or lower. Within your IP you can connect those power pins differently. Are there solutions coming in terms of context?
Marschner: UPF 2.0 is a huge step forward in that regard. There are capabilities for defining power intent that in some sense can be relocated. If there is power intent to an IP block based on certain supply sets coming in, you won’t know what they are. It changes.
Clark: That implies that we need a power intent to travel with an IP block even if that IP block inherently doesn’t have power intent.
Marschner: To me, power intent means these are the power characteristics that are invariant for an IP block. If you shut this IP down, these outputs need to be clamped because they are important somewhere else, or these inputs need to be clamped because I’m depending on this control signal. It’s information about how many different supplies you may need in order to create the different power domains that you’re expecting are possible inside this IP block, even if in a given application the user doesn’t create all those power domains.
Clark: But it requires the IP block owner to think ahead to a lot of different possible scenarios. They didn’t worry about that in the past.
Marschner: The IP block owner needs to define the envisioned uses of this—not necessarily all the possible uses. They have to define the target market for this block.
Venkatesh: That’s not that unusual. If you write an IP block, even outside of the power intent you have to define what mode it will work in.
Clark: It’s not different conceptually, but it’s one more thing that we, as chip architects, are imposing on our deliverables. It’s hard to push that and get quality results and get it delivered in a consistent manner.
Marschner: It’s not a large step away from defining the functional interface of an IP block, which we’ve all gotten used to doing. It’s just defining the power interface.
Venkatesh: It’s one more thing to do.
Clark: And it’s not out of the question. But if you’ve ever worked with IP designers who are deliver IP for five different projects, they don’t want to do it.

LPHP: Are we making progress?
Chin: This is the same argument used in test 30 years ago. My guess is that in 10 years it will be part of the specification of the IP. That’s where everything is headed. Even the idea of RTL plus UPF may not be here in 5 or 10 years. But at some point there will be specification of the design that will include power. One of the things we’re still struggling with today is this assumption that the logic is separate and that the function is different than the power behavior. More and more, that will not be the case. We started with retrofitting what we had into a new parameter, and originally that was simple. You could turn it on or off, and that was it. That was a big change in functional verification, though, because you assumed everything was on. It created big ripples. The idea that increasingly power becomes part of the device is inevitable. Eventually, we’ll either reach such a high level of complexity that it will be required, or we’ll want to optimize so much at a low enough level that it also will be required. Those levels of hierarchy also are somewhat dynamic.
Venkatesh: Why do you think power intent will be integrated? The power intent view is very important, and there is value to having it separate. We started like that, but it got so complex that it was no longer feasible so we pulled it out.
Chin: If you look at the requirements for verifying what we’re doing even today, and certainly when you look forward a couple years, the complexity is getting so high that pulling things out or keeping them separate will get harder to maintain. If today, for example, you want to do a more fine-grain shutdown in a chip and specify that in UPF, you’d end up with UPF that is much longer than your RTL. You may not want to do it today. But as complexity grows exponentially, keeping these things separate that increasingly are part of the function of the device will change. We’re seeing that today with simulation.
Marschner: That’s happening now with power-aware simulation.
Chin: Exactly.
Marschner: We may keep things separate at the top level, but what happens at the bottom level? Verification models have PG (power and ground) pins on them. Liberty models have PG pins. At the bottom level, when information becomes more stable the information merges because it’s more convenient to have it coupled, as opposed to having two files instead of one and forgetting to read the other.
Clark: Or updating one interface and not the other. At the fine-grain level, it would be great to have it integrated in the RTL. At the high-level, though, where you’re bringing blocks together, you would need some unified high-level language like UPF to describe how they interact.
Marschner: You need a methodology to pull in different features separately from different places.
Clark: It would be nice to have power intent at the synthesis level merged into the RTL.
Venkatesh: That gets very complicated with the RTL.