Reusable Power Models

Power is not a new concern, and proprietary models are available for some tasks, but the industry lacks standardization. The Silicon Integration Initiative (Si2) is hoping to help resolve that with an upcoming release of IEEE 2416, based on its Unified Power Model (UPM) work.

The creation of any model is not to be taken lightly. There is a cost to its creation, verification and maintenance. For models that only get used for one function, this can be difficult to justify. As power and thermal become an increasingly important concern, teams are looking for power models at all stages of the development flow, but so far those power models tend to be applicable to one function only, and there is no continuity between them.

The Si2 organization has been looking at power models for more than a decade with a view to making them more valuable. One such piece of work was the standardization of the Common Power Format (CPF), which was used to define the power network. An alternative version, the Unified Power Format (UPF) was created shortly after that within Accellera. The merger of these became IEEE1801.

Ten years ago, two additional efforts were started within the IEEE, tagged as 2415 and 2416. IEEE 2415 was looking at power from a software perspective and this effort appears to have cooled. However, 2416 looked to bring power analysis to the system level. IBM donated its work on power models to Si2, which subsequently was donated to the IEEE to become the basis for IEEE 2416. The first release of the standard was in 2019, and Si2 is now getting ready for its second major release at the beginning of 2025.

As the industry evolves, new models and tools are created to solve an immediate need. Later, when the problem space grows, this can lead the industry to look for more robust solutions.

“We have a rich set of models, including a chip thermal model, a chip power model, a chip signal integrity model,” says Marc Swinnen, director of product marketing at Ansys. “The question is, can I take a chiplet, or design from one system, or another tool, and fit it into my 3D-IC? These models are proprietary right now. It’s not that this is jealously guarded. It’s just that there was no demand for it before. These models were developed internally for internal reasons, and most companies are using tools in vertically integrated flows. But there is a growing demand for standardization on these models.”

Many tasks involve different teams, and in some cases that can create difficulties. “Models have to be universally consumable,” says Chris Meuth, new opportunities business manager at Keysight. “Today, you have a lot of different manufacturers or EDA players who can create different types of models, but they’re not interoperable with other tools. You need to be able to interchange models, and that’s something that’s not easily done today. Design requires a lot of collaboration between teams and sharing of information.”

Semiconductor Engineering spoke with three members of the Si2 committee working on these problems: Nagu Dhanwada, a senior technical staff member at IBM, chair of the IEEE 2416 working group, and co-chair of the Si2 unified power and thermal coalition; Sri Chilukuri, a sign-off engineer at Qualcomm and co-chair of the Si2 unified power and thermal coalition; and Daniel Cross, principal solutions engineer at Cadence.

Each of them describes a different problem associated with the lack of model continuity:

• Dhanwada: “System architects have access to SystemC models, but many of them say I can do it using pen and paper or a spreadsheet. But those spreadsheets never get re-used, and what may have been learned from them is lost when you get to RTL development.”
• Chilukuri: “No design starts from scratch. You are trying to incorporate technology specific scaling, or architectural scaling. We are trying to create continuity by building a model on top of a signed-off database. Then we can take previous assumptions, to see how architectural or technological parameters will impact them.”
• Cross: “We want to leverage multiple abstractions, to expand the capability of doing full system modeling, including power, to include analog as well as digital. But today there is no way to include power from the digital part of the circuit in that analysis, because if you’re simulating RTL there are not even power pins. There is no power network.”

No one model can do everything. “One of the reasons for IEEE 2416 was to create a continuous model that is multi-level,” says Dhanwada. “One of the pillars of the standard is to be able to formalize the abstractions top-down, but being able to build that model with the bottom-most level of data you have. They both go hand-in-hand to address the problem.”

A model needs to support both bottom-up and top-down methodologies. “With advanced nodes, it’s no longer just the architectural things that affect power,” says Chilukuri. “It’s also the processes themselves and how you take into account things like the fins of the nano sheets. These cannot be captured in a spreadsheet but are going to play a big role, and make a big difference, in power. How do you create a process or PVT agnostic model? It requires a model where I can have something at the architectural level, and as I proceed through the various design phases, something that will keep adding accuracy without changing the model, without having to go to a different set of models, or outside the parameters. I can keep expanding the accuracy of the same model. I can keep improving it.”

Lower-level information needs to propagate all the way to the highest levels. “My real interest for using UPM is having multiple abstractions,” says Cross. “I want to be able to propagate low-level power estimates up to higher levels of abstraction and included in a full system power analysis. My ideal result is that you can write digital assertions against your power estimates, so that your functional verification will flag if you have a power failure as well as a functional failure.”

Top-down is equally important. “Consider a RISC-V processor where you have a cycle-accurate performance model at the highest level,” says Dhanwada. “It has cache hits, cache misses, branch, etc. A power model can be set up to have power numbers associated with them. The next level breaks that down so that my RISC-V has a fetch unit, decode unit, all these units. I am going to have a traditional RTL macro model for some of these blocks. At the lowest level, there are gate-level models for that same set of functional blocks. That is the part which brings together the whole top-down aspect and connects things into a single model, which can interface at different points. As your design evolves, you can add more detail into your simulation hierarchy.”

Adding thermal
Initially, the back-end focus was on timing. Then came power, but power and timing are interlinked. Today, we are adding thermal as a concern, and it is also linked to power.

“Thermal has a big impact on the power,” says Chilukuri. “The model that I create has certain assumptions of thermal variation within the chip. As we start to consider chiplets, you have to be concerned about your thermal envelope, the gradient changes. The model has to account for these. That is why we’re trying to add this thermal component to the UPM model. Getting a model that interacts with both is really what you need. Today, we have models which are power, timing, thermal. Each is a separate model. We need to build the models that can talk to each other, and change the values or the parameters based on what the other model actually has.”

This lack of unified models makes some optimizations difficult. “With classic system-level optimization, you may be trying to implement dynamic voltage and frequency scaling,” says Dhanwada. “As a system architect, when I bump up the frequency, what are the correct voltages and how accurately can you ascertain that? That is a classic example of the need for a PVT independent model. You built up your power model, which is accurate enough with links to the lower levels, and your architect — who’s trying to explore a DVFS scheme — will use the simulation model trying to set some DVFS parameters. Then you are able to simulate the power model with that signature, which is parameterized by voltage, frequency, everything else.”

While this is possible today, it is proprietary. “Each company is trying to do their own internal modeling,” says Chilukuri. “We are trying to replace that with a standard PVT agnostic model that can go across the various design stages. Another problem comes when analyzing PVT corners for sign-off. The addition of UPM would allow me to test at different operating conditions. Today, if a customer asks me to bump up the performance on one thing and is willing to take a compromise with the power on this, or wants to bump up the voltage, the analysis can be done. But it’s a very heavy solution today to re-tune all my methodologies, all my margins. This should not be the case. With UPM, it allows me to do a different analysis, which I couldn’t do before.”

But can one model do it all? “Another aspect of thermal is self-heating,” says Dhanwada. “Device self-heating, wire self-heating. Can you characterize your thermal resistances and make that available at the module level. For power grid analysis, you should probably capture a lot more in the model, so the handoff between, let’s say, the package person and the chip person is going to be easier. You have to decide, how much is too much?”

Different kinds of power
Ask members of a development team what aspect of energy, power or thermal they are most interested in, and they will each provide a different answer. For example, a system person may be concerned about the total energy consumed for a task, which relates to battery life, while a power grid engineer may want to know about peak power, or rate of change of power. The package engineer may be more concerned about peak thermal and thermal gradients.

Each of these requires a different set of data and analysis. “For electromigration, you want instantaneous power,” says Dhanwada. “For static IR drop, you’re okay with average power, but dynamic IR drop, requires cycle by cycle power. The most common need that we started with was average power driving static IR drop analysis, and total power. These help with the most common scenarios. There is also transient power grid analysis. Are there hooks you can build into the standard to make it a little easier? The model doesn’t preclude doing a cycle-by-cycle or peak analysis. They can use the standard today.”

What is in the model is separate from how you use it. “In your analysis, you can choose your window of time that you want to average over,” says Cross. “If you want to do a very detailed analysis, you choose a very small window of time, and now you’re capturing very fine transient effects.”

It is important to focus rather than attempt to do everything at once. “Today, we are all talking about average power,” says Chilukuri. “We also want to model other power aspects, but they are not all supported within the same model. Instead, I can have one model that is representing the average and a different one where I’m capturing the peak values.”

Finding worst-case power can be pessimistic. “Worst-case conditions for analog may be different than your worst-case conditions for digital, and across different functions,” says Cross. You never hit the worst-case for everybody at the same time. You also want to make sure you don’t miss something that can happen, that’s worse than what you planned for. A classic example is a design for a Bluetooth radio. Theoretically, Bluetooth is a half-duplex radio protocol, so you never have to transmit and receive at the same time. You never have to have them both powered on at the same time. You can size your power grid based on that analysis. Then you find the radio guys were planning to use the transmitter to calibrate the receiver, which means they both have to be on, at least for calibration, and suddenly the power grid has to be appropriately sized for that.”

Most companies look at scenarios. “I will be looking for the worst-case scenarios that push my design to the maximum,” says Dhanwada. “For every design, you put in the effort of creating several different workloads. All of this will reflect as bookkeeping for your power lead. In that context, that information is going into the model and even being parameterized on workloads to some degree.

The new standard
Several issues are being addressed with the new standard, including mixed signal, multiple voltages, and gate leakage. These are issues that members raised as being important additions.

But a standard is only useful if it is adopted. “The bigger thrust next year is going to be to get some EDA vendors on board,” says Dhanwada. “We need adoption by EDA companies, IP companies, system houses, and foundry support. We have a couple of irons in the fire with the foundries assessing the value-add, and we have system houses deep into it.”

“A foundry would be a very important piece of that because the first IP that we get is from the foundry,” says Chilukuri. “The current solution is not scalable with the number of corners that a product company like Qualcomm might ask for. Having a model that is PVT-independent makes it easy for the foundry and for the customer.”

The new standard is expected to be released in January 2025.