Last summer at 53DAC in Austin, Sonics rolled out a seminar with a formative strategy for its Energy Processing Unit, or EPU. After that session, I summarized the idea in my SemiWiki blog:
“The premise of an EPU is that power savings using software, even in a dedicated microcontroller, is relatively slow, perhaps 50 to 500 times slower than what hardware-based power control can handle. Faster speeds mean narrower moments of idle time can be exploited to save energy, and distributed, autonomous, deadlock-free ICE-Grain controllers mean many more of those moments can be processed all over the system-on-chip (SoC) – leaving the CPU to do real work.”
There is some great material on the Sonics website going more into depth on the ICE-Grain Power Architecture and the recorded seminar presentation itself (registration required). The cornerstone of that presentation was a study of power savings in an implementation of the widely available Google G2 VP9 Decoder intellectual property (IP) block. With the ICE-Grain Power Architecture applied, a 94% energy reduction in 480i60 playback was uncovered. Sonics also went after a 2160p60 video pipeline looking for savings in line-oriented processing. In this scenario, power gating during “horizontal retrace” (HSYNC) idle moments of only 1.7 usec at hardware speeds saves 41% of the energy.
You’re probably thinking: that’s nice, Sonics has some super-cool hardware IP for energy management and knows how to optimize the heck out of one domain of IP blocks for that kind of power savings. What’s an average SoC designer with randomly selected IP blocks supposed to do? Or, how does the designer working under the “god” architect who is already heavily invested in an SoC power management architecture sell the idea of third-party distributed IP?
Well, I’m not from Sonics corporate, but I am here to help. If you’ve looked at the background on the Sonics site, you’ve probably surmised that ICE-Grain controllers are little chunks of configurable hardware with a simplified interconnect for easy timing closure across long distances. (We should point out that the EPU is not based on Sonics NoC IP optimized for data interconnect and throughput.)
Sonics recognized early on that without automation, designing their ICE-Grain IP into a large scale SoC could take a small army of people and months of effort. That’s why they invested in both the IP and a design automation tool to help deploy it. Behold, the EPU Studio Configuration Trial running in SonicsStudio Director:
5 reasons to go get the free EPU Studio Configuration Trial right now:
- It’s Eclipse. You’re probably already using the Eclipse IDE somewhere in your EDA tool stack. Resize panes, move them, add and subtract until your environment fits your workflow.
- It’s abstracted design. While it helps to understand UPF concepts, it’s not required to create an energy management solution. ICE-Grains are configured using tables and state transitions.
- It’s scalable. The example in the configuration trial is small, but the tool supports ICE-Grain configurations with thousands of distributed grains working together.
- It’s doable. It took me about 1 hour to install the demo and complete it. At each step, there is a verification check, and in most cases a picture showing what the result should look like.
- It’s ready to go. The trial download is fully functional – its only limitation is a 2-week demo license. Designers can explore a more complex ICE-Grain configuration by setting up a self-guided project.
The configuration trial sets up one cluster of three grains just to illustrate the concepts of designing with the EPU IP. Following the demo, grain controllers are configured for a simple set of transitions between on, sleep, and doze using a transition matrix and an event selection table.
Trivial? Perhaps, from a first glance. The trial is supposed to show how easy working with EPU IP can be. Part of the idea is to orient designers who are used to creating UPF statements in a text editor, or worse yet blasting away in raw RTL to add logic, to a more visual toolset.
There’s more happening, however – a lot more. When completed, there are many views of the configuration that aren’t explicitly visited during the guided steps of the configuration trial. Out of curiosity, I clicked the Registers tab in the center window:
Right. This “trivial” demonstration creates 277 registers. Taking a closer look at the grayed-out fields shows many of these registers are read-only, saving substantial area. Still, a lot is going on under the hood. Imagine how many registers a bigger SoC power management configuration would have. Oh, wait – maybe you don’t have to imagine it, especially if you’ve ever tried to write power management software.
This is the biggest barrier to traditional SoC power management schemes: laying the hardware in is usually doable, but the software teams then spend the rest of their careers figuring out how to program all the transitions. Trying to change the scheme creates a huge mess, which is why that architecture “god” usually just overrules anyone even thinking of touching it.
A key point in all this: by default, an EPU operates independently from power management software – leading to many of the registers being read-only. Software can choose to interact with the EPU hardware, giving teams more control if they want it.
Large, well-established teams working on big SoC designs may be begging for a way forward as they press the limits of their power management architecture. Sonics’ CTO Drew Wingard says he’s working with such a team with 15 people doing power management alone, and two other design groups intertwined. It begs the question, can companies really continue to afford 15 people working on SoC power management, or can those 15 designers be put to better use adding value?
In the post-mobile world, including things like IoT devices, projects tend to be smaller and more numerous and chip variants need to be spun quickly. A consistent energy management architecture would help reach some of the more aggressive goals for always-on devices. These design groups may also be coming from a base of less experience with IP-based SoC design, perhaps realizing the limits of merchant microcontrollers and looking to optimize their devices for power consumption.
What SoC design team wouldn’t benefit from IP automation? EPU Studio is way more than a spiffy UI to just create a configuration. Sonics’ automation knows where all those auto-generated registers in the EPU IP live, and the required hardware sequencing to get the best results. Auto-generated IP means the time to the first working simulation is much faster. With automation, design teams have time to explore multiple energy management implementations and optimize more use cases.
Judge for yourself. Getting started is easy:
- Visit any page on https://sonicsinc.com
- Click the “Free Trial” button in the upper right corner.
- Fill out the form and request a download of the EPU Studio Configuration Trial.
- In an hour or maybe two, you’ll see the completed results and can explore what’s going on.
- You can then try creating a more advanced configuration on your own.
Sonics has created a formidable competitive weapon for SoC teams with the EPU concept. Taking back battery power in those idle moments could be the difference maker for consumers considering a device. Freeing up teams from the drudgery of a software-based power management implementation is a huge plus. Exploration might be the biggest win – instead of rushing a best-guess attempt to the finish line, teams can really dive in and evaluate several energy management approaches to select the best one. It’s worth a shot just to get a look at the technology via this trial.