Let me expand a little, think of power intent as an extension to the functional description that commonly and collectively refer to as "soft-IP". For the most part soft-IP is covered by the register transfer language (RTL) which captures the function and behaviour of our design. The RTL can be taken and configured by ARM licensees to differentiate and slot into their application SOC, but RTL doesn’t capture or model the power domains and power saving structures that will surely be needed to assist in that differentiation. Instead power intent has to be described by a separate and unconnected format or language. Today the industry provides and supports two alternatives, CPF and UPF. We have perhaps arrived at where we are now in a back to front way. Because the silicon tape out requires power saving, we should enable our implementation flows and our verification flows, but up until this point no one has really considered the specification. Consequently the power intent formats we have developed don’t easily conform to the requirements of specification and, perhaps even more importantly, they don’t easily morph through the stages of abstraction such that we can demonstrate at the end of the process (silicon tape-out) that what we ended up with is consistent with the IP.
This is where John's work on a new standard IEEE1801 has become important to me. My implementation role at ARM involves the translation through the layers of abstraction, from RTL to GDSII. And it’s becoming more difficult, as more complex and integrated power saving is required, so I need a better way to manage power intent through the design flow.
The IEEE1801 standard enables me to better describe the crucial inputs to my process. Right now I would probably refer to a design specification written in English, to understand the division of the design into power domains and how those power domains can be controlled and should interact to provide voltage scaling, shut off and thereby reduce static power or leakage. This method is fallible. It’s far from unusual to come across errors, to need to ask qualifying questions or perhaps even identify whole areas that are not described. Of course we can resolve problems through discussion, but that will take time and at the end of the process how sure am I that everything has now been considered? What I really need is a way to take a specification that is machine readable, making it available for reuse in downstream processes and one that I can finally verify - to show that my silicon tape-out conforms to ARM's description of power intent.
Okay so let’s not get into too much detail here, I can be succinct. The new standard allows something we call successive refinement so that the original description stays with me and only requires extension not modification as we move through the design process steps of verification and implementation. A key attribute we like at ARM is that the first refinement - configuration - can be synchronized and automated with RTL configuration. At every stage we can verify refinement and show that that the power intent within the design is true to the original ARM specification.
But of course, as is often the case there is a catch. It is tool support and we need industry co-operation to make everything work seamlessly with the new standard. This is where I come in. I'm currently building test cases that match our current IP developments and working with implementation and verification tool vendors to get that support build into the tools. It shouldn’t be a problem, the IEEE working group that John belongs to has collaborating membership from these same companies and in addition many of ARM's leading partners and licensees. It now feels like we are on the last lap. Collectively we can drive IEEE1801 adoption and bring forward a productive revolution. We are changing the capture of power intent, the way it is used in the design process and ultimately finds its way into the mobile communications device that you are almost certainly using to read this blog.
The power intent timeline: Accellara’s UPF 1.0 was donated to the IEEE in 2008. The current release, IEEE1801-2009 is a superset of UPF-1.0 and introduces the powerful concepts of supply sets and hierarchical power state as well as successive refinement. The next release is currently in ballot and, if all goes to plan should be ratified as IEEE1801-2013 early next year.
Stuart Riches, Principal Engineer, ARM. Stuart came to ARM via a network joining an eclectic mix of ARM partners, big and LITTLE. A background in software engineering initially writing in-house design tools lead into a career path working with and driving forward design automation tools. Most recently Stuart has worked with the Cortex-A7 team on implementation and currently contributes to the effort that will soon result in silicon solutions based on the V8 architecture. "Making it as easy as possible for ARM partners to realize the potential of ARM soft-IP is my key responsibility".
0 Comments On This Entry
Please log in above to add a comment or register for an account
ARM Cortex-A57 Test Chip on TSMC 16nm FinFET Process Optimizes Tools & Flows
on Yesterday, 08:48 AM
Seven tips for ARM Accredited Engineer exam success
on May 20 2013 09:22 AM
The Server in Your Hand - and the three new interfaces inside it
on May 09 2013 08:54 PM
A DATE with Computing Destiny
on Mar 18 2013 06:57 PM
CDNLive Paper Preview: RTL Performance Analysis of ARM Interconnect IP
on Mar 11 2013 01:40 PM