Richard Owen Blog

Cadence and Very Cool Stuff

Rich Owen — Tue, 03 Nov 2009 17:44:00 GMT

One of the very cool things about my job is that I get to see all kinds of new stuff early. I’m privileged to be involved in technology roll outs, and so get to be involved in early discussions with R&D, Product Engineering, and Marketing. And, I gotta tell you, there is very cool stuff coming out.

As I think we’ve established, I’m a geek. (And there’s my daughter again, rolling her eyes, and saying, “tell’em something they don’t already know, Dad.”) And so when I get a chance to see some of the new stuff being prepped by our R&D teams, I get pretty excited.

Here’s just one thing that’s on the burner – a method to explore the power solution space. I met a good customer today, and he very accurately pointed out that Power Shut Off (PSO) is a system function. The system designers very clearly know what blocks can be shut off when – it is a system function. But Multi-Supply Voltage (MSV) is another matter. Fundamentally MSV is about trading off speed for power – the faster you need it, the more power you’ll need. And this really means that any effective power estimation solution needs to consider the libraries, architecture, and expected implementation. If you don’t consider these, you’re not looking at the full picture. In the absence of the ability to estimate the impacts of timing, any kind of architectural analysis is largely meaningless. I mean, why not set the voltage on everything to 0.1v? You’ll save a ton of power. Of course timing closure might be a bit challenging.

So we’re getting ready to come out with something that will allow exploration of the power solution space; something that will really allow you to trade off speed for power. You set up the starting points – stuff like the libraries, constraints, and the like. You then set up the bounding conditions – the allowed solution space. The tool will then go off and run through the scenarios, identifying the best combination of voltages that will meet your timing and power targets. Under the hood, the tool is taking advantage of RTL Compiler’s target setting function to identify whether a given scenario will meet the requirements.

This will take the guess work out of MSV designs. What I really like is that this is the same technology that will then produce a production quality netlist. So correlation is not an issue – there’s no magic library conversions or RTL manipulations to produce this. You pour RTL, libraries, and constraints in, and you get the right scenario out. And you can then just push the button to implement the scenario.

As I mentioned, I was at a customer today. With me were two members of the R&D team – both PhDs and both widely known in the industry. We were presenting the challenges of low power design and how Cadence flows and methodologies solve those challenges. Now these are seriously smart people, and to see their passion and enthusiasm for the technology was contagious. These R&D guys really know their stuff, and they’re committed to making my customer successful. Cadence has (obviously) being going through a down cycle. But with guys like these, and with the technology we’ve got, no one should count us out. Nor should anyone discount our commitment to our customer’s success. We still have the best flows and tools and technology, and we’re still driving the innovation in the industry. We’ve not changed our passion or commitment one little bit – and don’t let anyone tell you differently.

Oh, and here’s a chance for you to hear about the latest innovations in the Front End Design space: Cadence is hosting the annual FED Event in San Jose on Nov 10. This is an event with R&D leaders discussing the new technology and innovations coming out in the next releases. You’ll hear from all of the R&D leaders in this space, and hear from other customers using our technology. And you’ll even get to see me – I’m on a panel offering my perspective about FED. Sign up at www.secure-register.net/cadence/ld_event2009 and I hope to see you there.

Rich Owen

Leakage Power and National Security

Rich Owen — Fri, 09 Oct 2009 13:00:00 GMT

I read an interesting article recently on EDN regarding a new way to determine cryptographic keys using leakage power. Differential power has long been documented to be a method of cracking keys. In this paper, the author, Milena Jovanovic of the University of Montenegro demonstrated that leakage power can also be used to predict the key contents.

I can’t pretend to understand the techniques behind cryptography (my knowledge of security doesn’t go much beyond looking for the little lock icon on my browser), but this does point out the importance of accurate activity files for all power optimization, not just dynamic opt. Modern libraries have state dependent leakage tables, and the Cadence tools can perform power optimization and analysis based on the activity factors and leakage tables.

In order to effectively use this state dependent leakage, you need to have accurate data. When I talk to customers, this routinely come up as a major issue – test benches are not naturally built to generate accurate usage. Instead, test benches are built to test things – to see whether or not the design meets the requirements. One solution is to run real use cases, and capture the activity. In reality, this is difficult to do, particularly with any kind of embedded software application. Hardware accelerators can solve this problem, allowing users to run real software, and to zero in on activity areas of interest – I’ve blogged about Palladium DPA previously.

But clearly, you gotta take leakage much more seriously now. As if heat, package, and battery life concerns aren’t enough, you’ve now got to worry about security and some guy with an ammeter dissecting your algorithms!!

Richard Owen

Accurately Measuring Power

Rich Owen — Mon, 09 Feb 2009 15:30:00 GMT

I was browsing low power news the other day, and came across an interesting announcement from AMD regarding some new processors being released. http://news.cnet.com/8301-1001_3-10149696-92.html.

These are follow up processors to their Shanghai core series. AMD has released both an energy efficient HE, and a high performance SE. These are AMD's entry into the quad core market, designed to compete directly with Intel's Xeon processor.

What I really found interesting was a mention of a new way of measuring power - Average CPU Power (ACP). The link to the white paper is: http://multicore.amd.com/resources/43761C_ACP_WP.pdf

Basically, ACP is measuring the power while running representative applications. The white paper specifically talks about the danger of looking only at peak power. From the story:

"It is of little value to measure power consumption by only looking at the spec sheets for different components, adding the totals together, because these generally only report the maximum power consumption. This scenario is like the car with a speedometer that tells you the maximum speed is 150MPH it's a maximum reading but it doesn't reflect daily usage."

This is the same problem many of my customers are also facing - how can they accurately determine the peak power of their chips while they can still impact the design? The old method of estimating switching activity just doesn't cut it. What I suspect really happens is that designers pad the estimate, leading to increased package and system cost.

"By utilizing ACP, customers can make a more educated estimate of their true power consumption. TDP, representing the thermal design power, is a rudimentary indicator of consumption, and may leave customers overestimating their data center infrastructure needs. In doing this, customers can potentially waste valuable data center space, resulting in un-optimized data centers that cost companies real dollars through their inefficiency."

AMD ran tests using a series of industry applications, and determined that the ACP reports are 23% to 34% less than the theoretical peak. So using this measurement can save a considerable amount of cost in building data centers.

Ok - that works for a server farm, but what about for a chip? How can you tell what is really running on a chip prior to tapeout, and how it affects power? Well, Cadence has had a solution for verifying actual operation for a long time - Palladium. And now we've enhanced it to perform Dynamic Power Analysis (DPA). This is up for EDN’s Innovation Award. The key thing is that this is not just counting activity - instead it is using RTL Compiler's power analysis capabilities to accurately capture the areas of peak power. Once identified, the design team can do something about it – maybe balance the load, maybe look at lowering the voltage. By having this knowledge before tapeout, the design team has been empowered to improve their chip's power profile (or ACP).

"AMD believes that ACP is a better way of thinking about typical CPU power that more accurately reflects the power consumption levels that customers can see in real life environments"

I couldn't agree more - measure the real power so you can take real actions.

ps: C-to-Silicon is also up for an EDN Innovation Award. I'll talk about ESL and power architecture selections in a future post.

What Was Cool at CES?

Rich Owen — Mon, 12 Jan 2009 16:00:00 GMT

First off, let me wish you all a very Happy New Year. I hope 2009 brings fun and success to everyone.

Second, I’d like to apologize for the lag in my posts. My loyal readers (thanks Mom!) have been wondering why I went quiet. Nothing dire; it just snowed. You see, I live in Seattle, and even though this is the northern-most city in the continental US, we don’t have a clue how to deal with it. So the city just shut down. As I hadn’t yet done any Christmas shopping, and since my high-tech kid needs, really needs the latest gizmo, this led to a scramble. But I’m back now, and ready for more low power and front end design posts.

I did a quick Google search for CES 2009, and got 79k hits for news stories. There are the usual:

Best 8 Products

Gadgets and Geeks

Tom Hanks at the Sony Booth

And a host of other stories.

But what I really want to hear from you – especially those fortunate enough to visit CES or see some of the reviews. What wowed you this year? What product or solution is going to change the game?

Also, what do these new products mean for chip and system design? I’m sure that there must be increasing levels of hardware and software interaction. What will this mean for verification, for system level planning, and for project management.

I’m happy to be back, happy to be out of the snow, and look forward to hearing from you.

What I'm Thankful For - The Geek Version

Rich Owen — Fri, 21 Nov 2008 13:53:00 GMT

Here in the US, it is approaching Thanksgiving. Traditionally at this time of year, people gather with their families and give thanks for their blessings over the year. Or at least that’s what the Hallmark Cards show. Blogs will traditionally be full of these kinds of happy, joyful thoughts. But not this one. While I am, of course, thankful for my health and my family (even if my daughter does think I’m a goober), this is an industry blog. So, let’s run through what this geek is thankful for:

I’m thankful that Moore’s Law continues to work. My first chip was about 16k transistors. My last one, in 2000, was about 2.5M. Now there are sub-blocks that big. And with the advance of Moore’s Law comes new and interesting challenges. Back in the day, we never worried about power or SI or multi-corner or Silicon Virtual Prototyping or any of that stuff. Every process node shrink brings new and interesting challenges – how to architect, how to verify, how to design, how to … Thanks to Moore’s Law, the job is never boring and probably never quite done.

I’m thankful for the invention of the Internet (thanks Al!), for all the collaboration tools and all of the timewasters, and, most importantly, for the invention of VNC. Way back in the dark ages of chip design, you had to physically be at your workstation to do stuff. And when you’re as poor a typist as I am, you would inevitably have errors in your script that would cause it to crash at 2am. The only way to check that it was still running was to drive into the office and see if the damn thing was still running. Or to never leave. VNC changed all that, eliminating the early morning drives. And greatly improving my social life too.

I’m thankful for Monty Python on YouTube. ‘nuff said!

I’m thankful for technology and all it brings me. My first record (yes record) was the Eagles Hotel California (I’m not really sure why I’m admitting this). 20 minutes a side, flip in the middle. My daughter has never even seen a record playing. Just the other day, she was complaining that her iPod was too small at only 4G. Of course, I nodded sagely, and said something about the March of Technology. She muttered something that I didn’t quite catch, but anyway I digress. Now my entire collection – greatly expanded from that rather poor start – is now stored on a server and streamed to my stereo via a Squeezebox. Very nice. And when I travel, as I do frequently, I carry a fair amount of my music on my mp3 player, which I listen to through my noise cancelling headphones. Thanks to technology, I may still feel the ill-behaved six year old’s knees in the back of my seat, but I can’t hear the little monster.

I’m thankful that I work with a group of scary smart people – not just smart in their field, but also incredibly imaginative in new and different ways people need our technology. A great example is with low power equivalence checking. On the surface, EC with low power is just more of the same – do the gates match the RTL? But when you start to consider domain crossings and the impact of constant optimization and clock gating across domains, the problem gets much meatier. As it turns out, the Conformal team already thought of those issues and more. Oh, and the stuff they’re working on today…

Finally, I’m thankful that we have a pretty vibrant high tech industry, and I am a part of it. Honestly, I have no useful skills outside high tech – I can’t swing a hammer, I can’t grow anything to save my life, and I’m a klutz. If the magic time machine deposited me 200 years back, it wouldn’t be long before I starved or was run out of town on a rail. After all, a village really only needs one idiot. But instead, I get to work with very smart people who are designing very cool products. I get to travel around the world, talking to smart people about their ideas, and how Cadence can help realize them. And I get to write about it. Not a bad gig at all.

I hope you have a happy Thanksgiving if you’re in the US. If you’re not, I hope you have a nice quiet week without being bothered by those of us who are celebrating.

Better Fix That Leak

Rich Owen — Tue, 18 Nov 2008 18:33:00 GMT

Things that leak are bad. If your hot water tank leaks, you might ruin your basement. If your furnace leaks, you might get blown up. And if your device leaks, you might not be able to sell your products in the EU.

Ok, maybe the later isn’t as bad as being blown up, but it will probably have more of an impact on the business of design. There are some new standards proposed for major devices. From an article on vnunet

The Eco-design Regulatory Committee this week endorsed standby limits proposed by the European Commission. These limits would be introduced through the 2005 Eco-design Directive, which provides a framework for rules covering any class of electrical device used in households and offices, such as TVs, computers and microwave ovens. The next stage in the EU legislative process will see the proposals debated by the European Parliament.The proposals aim to set a maximum power consumption for standby of either one or two watts from 2010, depending on the type of product. In 2013, the admissible power consumption levels would drop to 0.5W or 1W.

From the European Council for an Energy Efficient Economy (eceee)

"This first measure under the Ecodesign Directive ^[1]will drastically reduce standby electricity consumption of household and office products. It is a concrete contribution to reach the EU's energy efficiency and climate protection targets, while saving citizens' money", remarked Energy Commissioner Andris Piebalgs.

Just to see if the US is behind the times, or with them, I went and looked up the Energy Star 8.0 requirements:

B. Standby: To qualify as ENERGY STAR under both Tier 1 and Tier 2 of this specification, TVs, TV Combination Units, Television Monitors, and Component Television Units must not exceed power consumption of 1 watt in Standby. Additionally, this lowest power consuming Standby must be the default Standby for the TV as shipped to consumers. Measurements are to be taken without a POD module, if present on the product, installed.

So, with the increasing demands for functionality, how are systems designers going to accomplish these tight power requirements? Because this really is a system level problem – the person designing the TV must consider the tube, the electronics, the software – all the functions. And must consider them early enough in the design cycle to be able to do something about it. With these restrictions, it is no use to anyone to get to tapeout only to discover that the device consumes 2W.

The other interesting thing is that this really means that power is for everyone. I’ve been going around the world now for a number of years discussing the Cadence Low Power Solution. And, I’ve heard from a number of people that, “we’re not wireless, so we really don’t care about power.” Or if they did care about power, it was a just a system cost since they’d need bigger power supplies and bigger heat sinks, and the cost could be managed. Those days are over. With the standards above, and with the increasing attention paid to Green Initiatives, power is now a system requirement for pretty much everything.

I’d like to understand from the user community – what changes do you think this will have on the design environment? Will we start to see pre-qualified pieces of IP (hardware and software) with standby leakage modes measured and certified? Will we see different software development methods so as to minimize the average power? Are new performance metrics – flop per watt, say – in our future? How are we going to set and track system level power requirements throughout the design process, and throughout the design chain? And what have I not even thought of? Let’s get a dialog going.

Oh, and fix that leak. My first car, a1974 Plymouth Duster, leaked oil like a sieve. This certainly wasn’t green, and certainly didn’t help my car last too long. Leaks are bad no matter the source.

Plug of the Week

The Conformal 10^th Anniversary Celebration will be in San Jose on December 11. This event will look back over the past 10 years of formal verification, but more importantly, it will look forward to where Conformal is going. Don’t miss this chance to talk to the key R&D developers – we’re emphasizing customer/R&D interaction for this event.

More details and registration can be found at the registration site.

Actually, It Is Easy Being Green

Rich Owen — Thu, 06 Nov 2008 21:34:00 GMT

Ok, I’ll admit it, I’m a bit of a leadfoot. I like to go fast, especially off stop lights. Maybe it is the competitive streak in me, but I love to be the first off a light. Or maybe it is just me showing the BMW drivers that my Hyundai can go just as fast.

I also do a lot of traveling, and so end up in a lot of rental cars. Hertz might cringe at this, but is there anything better than winding up a rental car? Now before anyone yells at me, I’ve got a stellar driving record (touch wood). But there’s something about a new rental car and a light turning green that turns me into Mario Andretti.

On my last trip to San Jose, I hopped off the rental car bus (aside – is there another airport as, um, messed up as San Jose??). And found to my surprise that they had given me a Prius. Ok, why not? One advantage of traveling is you get to try different cars. I still get a smile on my face when I recall the cherry red convertible T-Bird I once got. I’d give the Prius a whirl. Could be fun. Or maybe I could figure out why the hype.

Now the thing about a Prius (forgive me if you know this) is that it has a big screen on the dashboard showing instantaneous mileage. So you can see at any moment in time exactly how much energy you’re consuming. And you can see the mileage over time – how are you doing during the trip. Pretty cool idea.

So here’s what happened. In a strange video game kind of way, I started to try to maximize the instantaneous mileage. I found that I could get better results if I didn’t blow off the light. If I coasted up to the light, the same results – 99MPG. I found myself getting irritated when the gas engine turned on, and the mileage dipped. In short, I started driving responsibly, all because of this dumb screen showing me how I was saving or burning energy.

Nirvana came to me on the third day, when I got the car up to the right speed, and then maintained that with a light touch on the pedal. The result – the car was only being powered by the battery. I ended up with 99MPG for about 5 minutes – YES!! Just by getting feedback, I changed from a leadfoot to maintaining the perfect balance.

Ok, there is a point to this (I’m imagining you saying, “Get on with it!!!”). As my colleague Jack Erickson has pointed out (here), getting feedback on energy use is the first step to doing something about it. And there are finally some EDA tools to help accomplish this. One that is particularly interesting is Dynamic Power Analysis with the Palladium system. DPA allows you to measure the power during real operation, including running software applications. The power engine is based on the power analysis built into RTL Compiler, so it is production proven. DPA was just named Product of the Month by Portable Design Magazine.

The nice thing about this is that there’s only a minor modification in methodology to get the feedback. So if a design team is using Palladium to validate system software or design operation, there’s no real reason why not to perform this power analysis. The same is true of other EDA power analysis and optimization engines – they’re largely there, waiting for use. Using these systems, you’ll measure the power of your design and system. And measurement is the first stage to doing something – balancing the software load, implementing shutoff or MSV, implementing clock gating – something. If you use these tools, it really could be easy to be green.

Pretty Scary, Huh Kids?

Rich Owen — Fri, 31 Oct 2008 06:20:00 GMT

In honor of Halloween, here are some horror stories about low power bugs. These are real bugs at real customers that would have led to real dead chips.

Horror story #1: It was a dark and stormy night… Ok, it was around lunch time. But a customer had just spent three weeks coding a UPF file to describe isolation between two power down domains. The customer’s synthesis tool required that the UPF only implement either from isolation (from a power domain) or to isolation (to a power domain), not both. So in order to prevent redundant isolation between separate domains enabled by the same power net, he had to specify specific nets between the domains, and specify them as no_isolation. Only, and here’s the scary bit, he had made a mistake, and had incorrectly identified a couple of pins that really went to always on logic. So, when the block was powered off, the always on logic would get nuked. *Shudder* Fortunately, one of my guys got static checks operational in an hour or so (shameless plug – Conformal Low Power). The static checks structurally proved that isolation was missing between the power off block and the always on logic. The dead chip was saved.

Horror story #2: The door creaked slowly open, revealing… Ok, he was in a cubicle. But a customer was doing power shutoff on a processor based design. The power controller was essentially a register bank. The real time OS would get an interrupt from the power down timer, and would execute the power down routine. The routine would hit the bit enabling isolation, and would then hit the bit disabling power to the power down block. All well and good, and pretty routine. The design was operational, and had passed all the static checks – everything was perfectly isolated and looked fine. But there was terror lurking – the processor’s secondary cache was in the power down block. The processor could execute the code to turn the power off, but would never get another instruction – ever! *Shiver* Fortunately, one of my guys got low power simulations operational with a high performance low power simulator (shameless plug – Incisive Design Team Simulator). Since there wasn’t a significant overhead to the simulation, they ran a lot more test cases. As a result, they caught the issue and moved the cache to an always on block. The processor lived to execute another day.

Horror story #3: There was a sound, and he turned around slowly to see the maniac raise his… Ok, it was his boss (hey, that is scary!) But a customer had defined the power intent for a big chip, and had proven the netlist and power intent was correct. This was a big device, requiring feedthroughs across a power off domain. His implementation tool, however, didn’t understand the power intent. So it didn’t understand the always on cells, and so didn’t understand that they needed to be powered by special routes connected to an always on supply. As a result, the feedthrough buffers in a power down domain were powered like all the other cells in that domain – by a switchable supply. *Eeeek* Fortunately, one of my guys got physical netlist checks operational. These checks check that the always on power pins specified in the LEF are actually powered by always on power rails (shameless plug – Conformal Low Power). The always on nets remained always on, and the chip made it.

So are you terrified yet? As Count Floyd said on SCTV, “pretty scary, huh kids?” Again, these are real stories – nothing made up here. My point with these stories is not to scare you, but instead to point out the need for a complete verification strategy that includes both static and dynamic checks, and to continue to run these checks throughout the flow. There are some nasty things that can happen when you do low power design, and these can quickly lead to some very dead chips. I don’t know about you, but I find the thought of that much scarier than goblins and monsters and kids in Sarah Palin masks.

Happy Halloween, everyone.

Oh, and… BOO!

The History of CPF

Rich Owen — Tue, 28 Oct 2008 01:03:00 GMT

I’ve shied away from getting into the power format wars – honestly, the whole question kind of bores me. I think everyone can agree that specifying your power intent in a single file that drives all the tools in the flow is a good thing. The specifics of which create_power_domain is used are less interesting.

But I think it is important to see how this whole thing was created, since it represents one of the more interesting developments in EDA in the past few years.

CPF began as an initiative in the RTL Compiler team in 2005. RC had introduced Low Power features the previous year, including isolation cell and level shifter cell insertion, and true top down Multi-Mode, Multi-Library synthesis. But the team was surprised that customers were slow to adopt this technology. They asked customers, and soon figured out that the main reason was because there was no real mechanism to validate that the power spec was correct. Since the isolation cells change the functionality, that new functionality needs to be tested. Without a way to ensure that the cells have the right values, there was just too much risk to the adoption.

Now, people had been working around this risk for a while, using home-grown PLI routines or even just force statements. But these techniques are limited and are costly to maintain. With the increased emphasis on LP design, a different, more structured technique was needed. And so the concept of a single power spec, driving every tool in the chain was born. This represented a significant investment for Cadence. In addition to developing a spec to drive a complete RTL to GDSII flow, all the tools in the flow would need to be updated and enhanced.

By the second quarter of 2006, a draft spec was ready and the initial tool implementations were available for deployment. Something like 300 person-years was spent to bring the prototype low power flow to customers. But the team realized that the flow needed industry test cases and validation. The spec needed to be proven, and needed experienced designer’s eyes on it. As a result, the Power Forward Initiative (PFI) was founded. The original ten members included AMD, ATI, ARM, NXP, Freescale, Fujitsu, NEC Electronics, Applied Materials, and TSMC. These are industry leaders who have a strong need for more automation in advanced low-power techniques. The PFI members agreed to review the spec and provide feedback that would refine the CPF specification and how it interacted with the tool chain. In addition, they agreed to do real projects, Proof Point Projects, to validate the requirements.

During the next 6 months, the PFI team provided over 500 separate inputs into the specification team. These new requirements and suggestions dramatically changed the spec, adding support for hierarchy, increased wildcards, tighter specification, and many other items. In addition, the first chip using CPF taped out around the end of 2006. This first tapeout proved the concepts and value of the single spec concept. There were real problems found in simulation, and real productivity enhancements.

By the end of 2006, the PFI team realized that the specification was production worthy and a standardization process was needed to take CPF to the next level of adoption. The decision was made to transfer the spec to Si2 for industry standardization. A Low Power Coalition (LPC) was set up inside Si2 to manage future updates to the spec. Si2 is now responsible for the specification with member companies having well –defined role in defining CPF’s evolution. At the same time, PFI membership grew – additional companies joined, including some EDA companies, additional design service companies, and more fabs. Currently, PFI membership stands at 36. PFI continues to do Proof Point Projects, proving new and advanced concepts in power specification for a range of design applications and low-power IP.

In my next post, I’ll talk about the future of CPF.

Si2 Low Power Coalition

Power Forward Initiative

Coarse PSO and the new Apple MacBook

Rich Owen — Thu, 16 Oct 2008 14:54:00 GMT

After a long day, I like to browse around the web, looking for interesting stories. Ok, yes, I’m a geek (as my daughter continues to remind me, accompanied by a roll of her eyes).

But I found this story about the new MacBook too interesting to pass up. I agree with Seth that the most interesting feature is the use of multiple graphics. But for a different reason – this is the ultimate in coarse Power Shut Off.

What I find particularly interesting is that I bet each of these graphics sub-systems also have some pretty advanced power management capabilities. But by themselves, it wasn’t enough for Apple. For Apple, the additional cost of a graphics system was worth the extra 25% of battery life. And, of course, cost here is not just the chip price. There’s also the additional real estate, the software development and qualification costs, and the potential reliability impact of having additional components.

So I’m wondering if this can explain why I’m not seeing that many DVFS (Dynamic Voltage Frequency Scaling) or AVS (Adaptive Voltage Scaling) designs being done. A quick refresher – AVS is changing the voltage based on the application requirements. Higher horsepower requirements will cause the voltage to be increased. DVFS is taking that one step further, and changing the voltage and frequency based on sub-application needs. The I-frame decoding takes more oomph than the P-frame, so amp up the voltage and frequency during I-frame.

But voltage scaling takes some sophisticated software and hardware control. Maybe it is cheaper to just put extra stuff on the chip (or in the case of Apple, on the motherboard) and switch between them based on the user requirements? I’ve also heard of this approach being used by some networking companies – they’ll just turn off some of the switch circuits if they’re not needed.

What do you think? Are multiple potentially redundant power shut off blocks the way to go? Are we going to see more layered PSO like the Apple approach? And what does this mean for power design and estimation?