Dueling Power Formats

By Ed Sperling
Multiple power formats and increasingly complex SoCs don’t sound like a winning formula. So just how bad have things become? Low-Power Engineering asked Sorin Dobre, senior staff engineer at Qualcomm, for a real-world assessment of the situation.

LPE: There are three power formats—CPF, UPF and IEEE 1801. How big a problem is this for Qualcomm?
Dobre: Actually we have CPF 1.1 and 2.0 and UPF 1.0 and UPF 2.0, which is also called IEEE 1801. In the CPF area there is a unified approach. There is backward compatibility and consistent methodology for power intent and verification. In the UPF area there are many inconsistencies between UPF 1.0 and IEEE 1801. Instead of parallel formats there is a level of confusion about what can be used in a consistent fashion.

LPE: Which standard should everyone be using?
Dobre: On the UPF side, IEEE 1801 is the standard that can be used by the EDA community to develop all their tools, and it can be used consistently by designers. Keeping both UPF 1.0 and IEEE 1801 is creating problems. There should be a consistent power intent and a road map for tool development. That’s well defined in the CPF camp, and there is a path toward convergence to have one format in 2012.

LPE: What holds you back from just choosing one or the other?
Dobre: Today we can use IEEE 1801, but not all the EDA tools vendors support that standard. Even if you have a very good standard, you are limited by the set of tools.

LPE: And you have every vendor’s tools?
Dobre: Yes.

LPE: So as a result you have to support both?
Dobre: That’s correct.

LPE: How do you get around this problem?
Dobre: There is no easy way. It adds a lot of complexity. We have to define the power intent files and maintain the power intent files. Having a consistent, fully automated power intent flow for verification is difficult. You need translation from CPF to UPF and back to CPF. And it is not a straightforward translation process.

LPE: What do you want to keep from CPF?
Dobre: We believe we can take the hierarchical methodology, which is very well defined in CPF, and have that ported to the next version of UPF. We also need the automated macro-modeling generation, and it all has to be put into an agnostic format. If we have all of that we can have a very strong and powerful single standard.

LPE: Is there any movement in that direction?
Dobre: There is a big effort by Si2.

LPE: If you’re designing a chip now, what do you have to do now?
Dobre: Today, we define power intent at the system level for the product. We define the power domains and power modes. It’s a high-level description. From this high-level description you create UPF and CPF files and provide a reference to the block-level owners. They have to generate CPF and UPF files. Then there’s an integration process where the lower-level files are integrated with the higher-level power format files. You create a complete power intent file for the whole SoC, which can be used for functional verification and design implementation.

LPE: Do you need separate models for UPF and CPF?
Dobre: With power intent files you are dealing with multiple voltages. There are two ways to describe the models. One is multi-models. The other is libraries. If I have 10 voltages, I can use 10 libraries. It’s a much bigger port to have 10 libraries. It’s much more power efficient to have one model rather than a family of libraries.

LPE: If you have an engineering change order, do you have to adjust both formats as you go forward?
Dobre: That’s a very important aspect of power intent work. You need to define an integration methodology. You need custom integration capability for every change. What is required is to have an integration methodology. All changes at the system level or block level must be integrated with the top-level power intent file. As long as you don’t impact the macro model it won’t impact the top-level power intent file.

LPE: Does having more than one power format increase the risk of something going wrong?
Dobre: Yes. I get more power intent information in CPF than in UPF. Without it you are missing some power intent information. But there also is a lack of consistency. You need to pay attention if you do a check in UPF, you need to make sure you do all the checks with CPF so you have complete information.

LPE: What are the real-world ramifications of this?
Dobre: The biggest impact is in the overall design flow. You don’t have all the verification capabilities.