For decades, tracing back to the days of Deming, the way to tackle complex engineering problems has been the pareto chart. Charting conditions and their contribution to the problem leads to mitigation priorities.

In the case of SoC power management, the old school pareto chart said the processor core was the biggest power hog and needed to be managed first. The industry developed lower power cores, dynamic voltage and frequency scaling (DVFS), power and clock gating, big.LITTLE clusters, and lower leakage transistors and processes. Power got lower.

But, did it get better? In the world of dark silicon, where there are bazillions of transistors and uncertainty over exactly who is doing exactly what to whom at any given time, it can be very hard to say. (Batterygate, the story of the difference between Apple A9 as fabbed at Samsung and TSMC, is a great example.) Techniques to manage power become increasingly difficult. More importantly, if we look at a typical SoC, the processor core may have several challengers on the new school power consumption pareto chart.

When the CPU cluster no longer dominates power usage, CPU-centric approaches to power management run into limits quickly.

Managing IP hardware blocks as power/clock domains illustrates the problem. Setting up boundaries at bus interfaces and creating power islands is tempting, but inefficient using only a conventional interconnect. If an IP block were independent, fine grain and automatic coarse grain clock gating would be enough to slow or shut down an idle block.

In complex designs, IP blocks are highly interdependent, especially if a network-on-chip is used. Fabric must remain powered if any attached block is still powered, meaning the fabric is “always-on” or needs partitioning with many wires at the domain crossing. If there are many transactions between blocks, idling a target may actually be counterproductive, causing system-level congestion and power thrashing as blocks are constantly turned on and off.

A better approach is to group the IP into affinity domains that are on or off together, and partition the domains across a minimally wired hardware interface with a software power management protocol. The catch is there is no industry standard scheme for this. ARM has defined several channels in AMBA, including C-, P-, and Q-channel, with each serving incompatible needs and not compatible with other stuff. Using these hardware channels does little for the software side. If a design team controlled all the IP blocks and could integrate these channels into each block accordingly, it might be possible to use them, but it would take a sizable design team working on just power issues – something most SoC design efforts cannot afford.

Using a NoC is something most SoC design efforts can afford, and the SonicsGN architecture strongly comprehends power management. Redrawing the partitioning into power islands including the network components captures three huge benefits.

First, the wires in the hardware interface are greatly reduced – in the SonicsGN case, to a 4-wire power management interface. There is a power down request and acknowledge, and an auto wake request and enable, setting up a wake-on-demand function (similar to Ethernet wake-on-packet capability).

Second, the NoC knows what its traffic looks like and can manage it safely. Software can look at in-flight transactions across the network and make sure they reach their target before it is idled, rather than abruptly shutting down a block unexpectedly. This amounts to a power flush operation, where initiators vote and paths to a target are cleared prior to idling. Initiators can then handle a request to turn a target block back on. If the network is fast enough, the target block can come back on before the driver receives an error – virtually appearing on.

Third, all this management capability happens in the NoC and software without extensive modifications to hardware IP blocks to implement the protocols. Designers can choose their power management style, using gating techniques in combination with the channel-based approaches and the SonicsGN capability.

Using the Sonics power islands approach, designers have fewer limits and more capability in power management, without massive investments tied up in creating proprietary schemes. Sonics teams remain abreast of power management developments, and continue advancing their SonicsGN architecture to enable the latest ideas. By staying in the NoC and out of each IP block (some of which may be very, very dark in power management terms), IP block obsolescence or reengineering is avoided should power management tactics change.

Related Blog