To reduce the design and packaging cost, SoCs are usually developed satisfying a superset of demands of multiple customers. To target the customers who do not need the complete functionality the usual solution is to offer them only a subset of that functionality through the judicious use of packaging and pin out options. This, however, leads to inclusion of logic which might be needed by one customer and not by others.
A byproduct of this strategy is that the extra unused logic is not used in the lower functionality variants of the SoC and still contributes to the overall leakage. This is because it still also shares the same power network as the rest of the logic. Described here is a way to use power domain partitioning to reduce the leakage in lower variants by taking advantage of package configuration information.
The basics of chip-level power management
As per Moore’s law, we know that as the feature size has been scaled down the average chip size has increased over the period of time as indicated in the Figure 1 below:
Figure 1: IC transistor feature size has decreased and number of transistors per chip has gone up, but in relatively higher proportion. (Source www.ieee.org)
This indicates the intent of incorporating more and more functionality into a single SoC, which leads to to increased complexity, production cycle time and thus the associated development cost. The cost involved in the development, packaging and activities related to ‘Ramp To Production’ constitute a major portion of the total cost.
One common way to deal with this problem is to come up with an overall SoC design which meets the superset of all customers’ requirement and then to market to the specific subsets within it with limited functionality devices, through judicious use of various packaging and pinout alternatives.
Figure 2 below shows an example of the same, where a single die
is shown to be packaged into three package variants. While the higher
pin package provides all (or most of) the functionality, the smaller pin
packages provide just right functionality.
Thus, we can control the available memory, supported communication
protocols, peripherals, ADC/DAC channels etc to a customer who does not
Figure 2: An example of a die going into different package variants
Motivation for saving leakage power
This technique enables us to develop a single SoC and sell multiple variants to various customers and also reduces the design cycle turnaround time. But the strategy calls for the integration of more logic/ IPs than required for a limited variant, with the result that the customer/user has a substantial amount of ‘phantom Logic’ sitting on the SoC.
Because, though unused, these phantom devices are still powered up and tend to leak and increase the leakage power budget. As we run more and more devices on battery, the leakage budget tend to be differentiating factor compared to alternative, but similar solutions.
Since it is still necessary to power up these phantom devices, they add up to leakage statistics that may reduce the competitiveness of an otherwise brilliant design. A comparison of leakage numbers for 3 devices of same family (MPC522x) which are available with different RAM and flash size configurations is provided in the Table 1 below:
Table 1: The STOP3 mode current is same for all the packages.
As the leakage numbers (STOP3 Mode) are same it can be inferred that the phantom devices do nothing but ‘leak’ in the limited functionality variants.The figures in red indicate the possibility of saving the leakage power. These numbers are huge. For example., the phantom device with 32KB of RAM, and with 256KB of Flash could have saved roughly 25% of the leakage current, in comparison to the device with highest amount of memories.