Power-sensitive mobile devices are driving the bulk of semiconductor activity. The system-level tools to design them with power more in mind are still yet to be embraced.
By Ann Steffora Mutschler
With consumer demand—much of it for power sensitive mobile devices—driving the bulk of semiconductor design activity, it would seem obvious that the way chips are designed would have changed to reflect that. But have they?
From an EDA perspective, the term ‘system level’ is used to mean ‘product level’ but this may not be enough, especially when it comes to optimizing the power for the device. Venki Venkatesh, senior director of engineering at Atrenta does not see enough tools at the system level to assess power properly. It’s all about the RT level. “At this point in time, at the RT level, we can do a good job of assessing power, area and performance and have a reasonable amount of accuracy to do tradeoffs.
Abhishek Ranjan, senior director of engineering at Calypto Design Systems agreed that assessing power at the system level is difficult. “There are things you can do at the system level that are not possible at RTL. And there are things you can do at RTL that are not possible at the gate level. Different levels provide different levels of abstraction and measuring power. In terms of different methodologies out there—you can debate how accurate they are—but they do provide some value. For example, if you are deciding on a memory vendor, then of course there are datasheets and memory libraries that do provide enough information on how that memory is going to work even at a very high level, at the system level. But if you are going to make decisions about whether you should go single core or quad core and you are trading off performance versus power, RTL is too late. You really want to do it at the system level, and such tradeoffs can be made easily at the system level. But if you are trying to assess the impact of clock gating, then good luck. System level is not the place where you want to do clock gating or memory gating.”
He said that RTL is a good place to make minor microarchitectural changes, particularly those that are localized. The system level is better for sweeping changes. “The technologies are there, and knowing the limitations of the technology is important.”
Knowing the limitations is definitely important, noted Arvind Shanmugavel, director of applications engineering at Apache. “We all have different ways of modeling our power budgets and understanding the limitations of high-level synthesis or ESL models, and understanding the limitations of RTL level power optimization is important and each of them brings their own value. Right now, if we say that we are analyzing power at the gate level, we are obviously too late. We are looking at design cycles that are compressed into six months or three months and it’s not really practical to try to compute power at a gate stage. You need to be able to pick the right architecture with the ESL, you need to be able to implement with the RTL and you need to be able to verify with the gate level.”
Further, Ranjan said, power cannot be an afterthought. “You cannot leave it until the later stages. It has to be determined very early on. In addition, the designer must determine where power is being wasted because this is where the power savings will be realized.” For this reason, he stressed power analysis and optimization technology must be part of the same tool and analysis must guide the optimization.
A set of problems
Low power isn’t a single problem, though. It’s a global problem, and it shows up throughout the design flow.
“Very often we say, ‘We need to solve the low power problem,’” said Lawrence Loh, vice president of worldwide applications engineering at Jasper Design Automation. “Low power is not a problem. It’s a set of problems. We have to divide and conquer. If you don’t do a good system-level design, you can do as much optimization as you want and you’ll never be done. If someone understands what the performance requirements are, then they can use that information to feed back to the system level to understand, based on previous requirements, what they can get. That’s the part of the previous chip that has seen the market, so you have real live data, then you pass onto the RTL designer and give them a budget. Then, it’s that person’s job to keep within the budget and provide some data for power estimation. Then it goes to verification to make sure nothing got broken so the RTL designer can feel good about putting optimization in there. And then software; the architecture has to give room to software to manipulate power so it’s really a big team effort.”
Still, Shanmugavel said, “When we have a high level of abstraction, it’s very difficult to get an understanding about what type of architectural changes we are going to do to reduce power, but the first level where we have microarchitectural implementation as a chip design company or a system design company, that’s basically our RTL design. That’s the first stage where we can do efficient power optimization, efficient power estimation, and use that throughout the design phase as a metric to do power regressions and deliver a reliable product with a power target.
But remember, Ranjan argued, while RTL is just one of many checkpoints, “if you really want to tradeoff one core versus many cores, RTL is too late.”
And then, when it comes to optimizing not only power but area and performance as well, at least three things are needed here, Venkatesh explained. “First of all, you need to have a good methodology. The next thing you need are good models of power area and timing at each of these levels. Of course after the models, tools for estimating power, performance and area are needed to estimate, to a reasonable level of accuracy.”
Overall, he stressed the need for one person within the company to make the tradeoff. But given that architectural tradeoff decisions are based on the end product, it is extremely difficult to find a single person responsible for that task. And while the industry has a pretty good handle on dealing with power from the RTL perspective, is it behind in its thinking about dealing with software and systems when it comes to power optimization?
This is actually good news as it leaves room in the market for novel approaches to managing the ubiquitous system-level power optimization challenge, which will only grow more challenging with the technical issues of successive manufacturing node and as additional features get added.