Power Management Vs. State Machines

In the last several years, contemporary SoCs (systems-on-a-chip) have become very complex silicon solutions. They now consist of hundreds of millions of gates, 100 or more discrete Semiconductor Intellectual Property (SIP) blocks, high-speed data channels, megabytes of volatile and non-volatile embedded memory, increasing amounts of analog/mixed signal functionality, multiple CPU cores and multiple operating systems. In addition, robust, high-speed wireless connectivity is a prime requirement. All these features require millions of lines of application code to provide the rich feature sets the market demands today.

All these capabilities come at a high price. Silicon and software design costs have continued to increase with each new process node, becoming a major issue in the industry.

The following chart shows how SoC complexity has risen over the last 15 years with a forecast through 2020. These numbers are derived from data Semico has collected that look at the average gate counts in these solutions with 2002 average gate counts set to 1 and then dividing each succeeding year by that value to calculate the growth factor over time. The data indicates an advanced SoC designed in 2016 had more than 60X the gate count as a part designed in 2002. The high growth rates in 2003 to 2008 are due to the early adoption of the SoC methodology. During the past five years, the growth rate has stabilized.

Rising Device Complexity: 2002 – 2020

Looking at the data this way highlights the role that third-party semiconductor intellectual property (SIP) has played in the evolution of the SoC market. In order to design semiconductors of such complexity within an acceptable time frame and budget, extensive use of SIP is necessary.

It is not unusual to see 200 or more SIP blocks being used in high-performance SoC designs today. This is not news, but it does the stage for this article, namely what can be done to manage power consumption in SoC designs that continually must meet rising user expectations for performance and richer feature sets and functionality.

There are several reasons for this increase in design complexity for meeting power management goals.

• Transistor budgets continue to increase at each process node allowing more features to be added to the design.
• Market requirements for this increased functionality continue to rise coupled with demands for the right level of device performance to provide an adequate user experience.
• There are several avenues open to designers to manage power in their silicon solutions:

1. Power domains,
2. Power islands,
3. Clock gating,
4. Adaptive voltage scaling,
5. Adaptive frequency scaling,
6. Gate back-biasing,
7. Dark silicon, and
8. Others.

All these methods can help reduce power consumption and increase the control designers have over their solutions, but they come with the cost of higher complexity in both the silicon and the software to control these features. Essentially, we are adding layers of complexity to control the complexity we put into the system to manage different problems like power management. Carried to the extreme, this is a losing proposition in the long run.

Semico conducted an informal survey late last year in which we asked SoC designers questions about their power management solutions. One of the questions was related to the number of state machines resident in the design. This is one way to get a reading on the complexity levels designers are dealing with.

We received answers that indicated a range in the number of state machines between 15 and 225, depending on the complexity of the part. This is not surprising given the fact that most SIP blocks contain at least one state machine and the more complex blocks could have many more than one.

Looking at the list of power management design solutions, notable by its absence, is any mention of direct control of state machines. This can be important because most state machines are intended to facilitate some process in the part that the designer did not want the main CPU to be burdened with. Much of this mundane computational work is handled by state machines put into the design to control very low-level processes like accepting a handshake from another process, signaling the start, suspension or completion of a task. These handshakes are important on system start up and shut down since they can gate how long the actual process takes.

Admittedly, the duration of these handshakes and acknowledgements is very short in duration, but there can be many state machines in a design. Any delay in prompt handling of these actions can cause a delay in overall system responsiveness. Delays mean more power being consumed unnecessarily, which is the problem most designs face today. In some cases a part may consume more power than the simulation said it should. Why?

Today, the Unified Power Format from the IEEE exists as a standard for specifying the designers’ power intent in silicon designs and is used as a method to capture and preserve this data when using EDA tools on other parts of the design. Beyond this there are no formal standards to design power management features into SoCs, and there may never be given how many designs are being done and how many different power management solutions exist.

However, there is one solution from Sonics that places control of power management features down to the state machine level, the ICE-Grain Power Architecture. This allows for placement of localized state machines that can implement control over clocks, power switches and voltage sources either singly or collectively to implement a finer granularity of control over these functions. Because these features are local, there is very little latency involved in control of these functions which would otherwise be seen with an interrupt driven control system implemented through the main CPU and the Operating System. The Sonics solution attacks the problem where it lies – at the state machine level.

This is a much better approach since it places control over the power management functions at the lowest level of abstraction in the design and not higher up in the system hierarchy as seen in most systems today. Implementation of such a control system using the Sonics ICE-Grain Power Architecture allows designers to work at a higher level of abstraction, and does not require them to be power management experts. Designers can continue to leverage their existing software investment in power management features but with an added granularity that was not possible without a great deal of extra design work. The Sonics ICE-Grain Power Architecture frees designers from the need to create the control gates themselves at the state machine level, using instead the Energy Processing Units provided by Sonics.

All around, this is an innovative approach to the problem of infusing the right level of power management functionality and control into a complex SoC design.