Although the use of power gating technique is essential to manage standby leakage power, it brings in a host of new design and verification issues. This list of new design and verification issues include putting together a power switch network, incorporating appropriate isolation and retention, addressing x-propagation, dealing with current spikes, and ensuring retention works well. Switching power on and off is a slow event, and more so in a higher performance design where timing management can become a big issue too.
With the advances in CMOS process technology, scaled down devices needed lower threshold voltage to keep up with performance scaling. The leakage power grew exponentially with the decreasing threshold voltage and has led us to the leakage power problem that we have at hand today.
Adaptive body bias (ABB) technique helps reduce leakage by controlling the device body voltage leading to an increase in the threshold voltage. Although leakage cannot be eliminated, it can be significantly reduced. Since you don’t have to switch power off, it eliminates the need to deal with the host of design and verification issues listed above.
The implementation of ABB has its own challenges but it is an attractive alternative in many applications and likely to play an increasingly important role in managing leakage power. It also provides a way to deal with the variability issues that are becoming more critical with the advances in the process technology.
And the high performance requirements for some applications will also make the use of power gating impractical. When you are communicating at 10gbps on Ethernet links, it might take too long to wake up a sleeping link if it was put all the way to sleep as associated packet loss may not be tolerable.
Wednesday, October 6, 2010
Monday, August 30, 2010
Challenges in Creating Power-Managed IPs
Creating low power IPs worked fairly well until the process technology nodes for which leakage power wasn’t a big issue and clock gating was able to address dynamic power optimization. For 90nm and more advanced process technology nodes, not only leakage power became a dominant issue but the dynamic power also needed better optimization. The use of voltage-based power management techniques such as adaptive voltage scaling, dynamic power switching, standby leakage management, forward and reverse body biasing, and state retention required changing voltages and that tied power management closely to the process technologies.
ARM is known to have worked closely with companies such as Texas Instruments and QualComm over the years to create processor IPs that are used in application platforms such as OMAP and Snapdragon. The power management techniques used are not only process technology node dependent (such as versions of TSMC’s 65nm and 40nm nodes)
but also on application platforms support for various techniques. For example, ARM provides two hard IP cores for its Cortex-A9 processor – one that targets high performance applications and another that targets low power applications.
It is not clear if an IP provider can effectively provide a soft IP along with power specification written in IEEE p1801 format and hand it over to the SoC vendor as a soft power-managed IP. There are many more challenges to enabling this kind of handoff in addition to some mentioned above such as:
• A power-managed IP has to work closely with system’s power controller unit and appropriate considerations must be taken into account and this is further complicated in situations where platform creator also ties power management ICs to the platform.
• Power management cells within the IP such as isolation cells, level-shifters, power switches, and isolating level-shifters are process technology dependent. Any analog circuit has to be re-created for each process technology node.
• If your technique ties you to other components on the SoC such as a state-retention technique utilizing RAM then that is another application platform dependence that you have to take into account.
• If the IP itself has complex power management in place then its validation in the system context can truly only happen at the system-level and at times only using the system software.
All of these issues make creation of a power-managed IP a challenging task and it is not clear if a complex power-managed IP can be created without working closely with the full-chip vendor. For IP vendors, this further points to services becoming even more integral part of IP selling process in future.
ARM is known to have worked closely with companies such as Texas Instruments and QualComm over the years to create processor IPs that are used in application platforms such as OMAP and Snapdragon. The power management techniques used are not only process technology node dependent (such as versions of TSMC’s 65nm and 40nm nodes)
but also on application platforms support for various techniques. For example, ARM provides two hard IP cores for its Cortex-A9 processor – one that targets high performance applications and another that targets low power applications.
It is not clear if an IP provider can effectively provide a soft IP along with power specification written in IEEE p1801 format and hand it over to the SoC vendor as a soft power-managed IP. There are many more challenges to enabling this kind of handoff in addition to some mentioned above such as:
• A power-managed IP has to work closely with system’s power controller unit and appropriate considerations must be taken into account and this is further complicated in situations where platform creator also ties power management ICs to the platform.
• Power management cells within the IP such as isolation cells, level-shifters, power switches, and isolating level-shifters are process technology dependent. Any analog circuit has to be re-created for each process technology node.
• If your technique ties you to other components on the SoC such as a state-retention technique utilizing RAM then that is another application platform dependence that you have to take into account.
• If the IP itself has complex power management in place then its validation in the system context can truly only happen at the system-level and at times only using the system software.
All of these issues make creation of a power-managed IP a challenging task and it is not clear if a complex power-managed IP can be created without working closely with the full-chip vendor. For IP vendors, this further points to services becoming even more integral part of IP selling process in future.
Wednesday, June 9, 2010
What’s difficult about SoC power management verification coverage?
What’s difficult about SoC power management verification coverage?
Sometimes we hear that the number of power domains in SoCs have increased significantly and that makes power management verification difficult. True, the numbers have gone up from say 2-3 to 7-10 but these are not large numbers by any means and you can write tests to ensure that each of these power domains are covered for power related tests. Power related tests refers to ensuring that sequencing related to power down and power up (timings of clock gating, reset, switching supply, isolation, and retention) as well as increasing and decreasing voltages in connection with voltage scaling are being done correctly. One point to note here is that power up sequence of a domain is completely distinct from power down, and similarly, voltage going up is distinct from voltage going down.
Then we sometimes hear that the difficulty really arises because of the number of possible power states and not just because of the increasing number of domains. This is backed up with a statement such as: If you have 7 power domains in a design then you could be dealing with 128 power states if you only consider on/off states and many more if you include different on voltages. True, but that’s not what you really see in practice. Let’s take an example of a cell phone processor (such as the one presented by Infineon at ISSCC 2006) and we find that the chip has 7 power domains and has only 11 possible power states. These power states account for the device being used states such voice call, voice call with hands-free, sleep idle, paging idle, 3 different types of data download with different download bit-rates, video encoding, video telephony, music replay, and music replay with paging. It has 11 power states but not 128 or even more that can possibly exist. One can again write tests to ensure that each of these power states are covered for power related tests. So where’s the problem in getting power management verification coverage?
Each of these power states assign on and off power states to each of the power domains. The on state of a domain is further differentiated with different voltage/frequency possibilities. The real problem in verification coverage is in ensuring that all possible power state transitions are covered. On a cell-phone chip, a switch from the music mode to a video mode is completely different than a switch from the video mode to the music mode. It’s because of the points that we noted at the end of the first paragraph. And with only 11 power states, where you allow all possible transitions of power states, you are looking at 110 distinct power switching possibilities. This creates a verification coverage challenge. Since the number of possible power state transitions grows quadratically with respect to the number of power states in the design, future complex and feature rich power-managed devices are likely to find power management verification coverage even more challenging.
Sometimes we hear that the number of power domains in SoCs have increased significantly and that makes power management verification difficult. True, the numbers have gone up from say 2-3 to 7-10 but these are not large numbers by any means and you can write tests to ensure that each of these power domains are covered for power related tests. Power related tests refers to ensuring that sequencing related to power down and power up (timings of clock gating, reset, switching supply, isolation, and retention) as well as increasing and decreasing voltages in connection with voltage scaling are being done correctly. One point to note here is that power up sequence of a domain is completely distinct from power down, and similarly, voltage going up is distinct from voltage going down.
Then we sometimes hear that the difficulty really arises because of the number of possible power states and not just because of the increasing number of domains. This is backed up with a statement such as: If you have 7 power domains in a design then you could be dealing with 128 power states if you only consider on/off states and many more if you include different on voltages. True, but that’s not what you really see in practice. Let’s take an example of a cell phone processor (such as the one presented by Infineon at ISSCC 2006) and we find that the chip has 7 power domains and has only 11 possible power states. These power states account for the device being used states such voice call, voice call with hands-free, sleep idle, paging idle, 3 different types of data download with different download bit-rates, video encoding, video telephony, music replay, and music replay with paging. It has 11 power states but not 128 or even more that can possibly exist. One can again write tests to ensure that each of these power states are covered for power related tests. So where’s the problem in getting power management verification coverage?
Each of these power states assign on and off power states to each of the power domains. The on state of a domain is further differentiated with different voltage/frequency possibilities. The real problem in verification coverage is in ensuring that all possible power state transitions are covered. On a cell-phone chip, a switch from the music mode to a video mode is completely different than a switch from the video mode to the music mode. It’s because of the points that we noted at the end of the first paragraph. And with only 11 power states, where you allow all possible transitions of power states, you are looking at 110 distinct power switching possibilities. This creates a verification coverage challenge. Since the number of possible power state transitions grows quadratically with respect to the number of power states in the design, future complex and feature rich power-managed devices are likely to find power management verification coverage even more challenging.
Wednesday, April 7, 2010
Slow and Steady Wins the (Low Power) Race
Power is a key reason behind the shift in processor design to leverage multi-core architecture as it promises increase in performance without a proportional increase in energy consumption. For an application developer, today’s processors (microprocessors as well as embedded system processors such as cell phone application processors and wireless sensor network nodes) provide multiple cores with a handle on scaling voltage and frequency to manage energy consumed by processors in running various applications. You have to manage both dynamic power (consumed by running applications) and leakage power (to be controlled both in active and standby modes) effectively for these applications.
As you change frequency and voltage, switch cores on and off, and transition among multiple possible modes of operations, you are left with many possibilities to solve the problem under a given performance constraint. It turns out that the best policy to reduce energy is to go slow (operate at lowest possible frequency to achieve application goals) and steady (avoid power state changes) as far as possible.
While this may sound counterintuitive, power efficiency as a result of scaling frequency and voltage has nearly a cubic impact on dynamic power. This is assuming a linear relationship between voltage and frequency. In reality, it may not be an exact linear relation but arguments still hold very well for the typical behavior exhibited. But the time required also increases by the scaling factor leading to a quadratic reduction of dynamic energy. Leakage energy consumed remains nearly the same in the two situations assuming a constant leakage current.
As a result, if you are able to slow things down by a factor of 2, you are looking at nearly 75% reduction in dynamic energy. Assuming dynamic and leakage are equal partners in draining the battery at 65nm, you are looking at nearly 37% overall energy reduction by going slow and steady.
A multi-core processor implemented utilizing dynamic voltage and frequency scaling gives you an option to slow things down provided there is enough parallelism in the application. And such gains are possible in all variations of multi-core architecture utilizing symmetric, asymmetric, and dynamic cores when you can go slow and steady.
As you change frequency and voltage, switch cores on and off, and transition among multiple possible modes of operations, you are left with many possibilities to solve the problem under a given performance constraint. It turns out that the best policy to reduce energy is to go slow (operate at lowest possible frequency to achieve application goals) and steady (avoid power state changes) as far as possible.
While this may sound counterintuitive, power efficiency as a result of scaling frequency and voltage has nearly a cubic impact on dynamic power. This is assuming a linear relationship between voltage and frequency. In reality, it may not be an exact linear relation but arguments still hold very well for the typical behavior exhibited. But the time required also increases by the scaling factor leading to a quadratic reduction of dynamic energy. Leakage energy consumed remains nearly the same in the two situations assuming a constant leakage current.
As a result, if you are able to slow things down by a factor of 2, you are looking at nearly 75% reduction in dynamic energy. Assuming dynamic and leakage are equal partners in draining the battery at 65nm, you are looking at nearly 37% overall energy reduction by going slow and steady.
A multi-core processor implemented utilizing dynamic voltage and frequency scaling gives you an option to slow things down provided there is enough parallelism in the application. And such gains are possible in all variations of multi-core architecture utilizing symmetric, asymmetric, and dynamic cores when you can go slow and steady.
Wednesday, January 13, 2010
Use of Formal Methods in Validating Power Controllers
Power domains are required in the design due to stringent active and standby power specifications. Depending upon various modes of operation of a chip, power domains allow parts of a chip to be powered on/off independently from the rest of the chip. This has become common in all handheld and portable applications where stringent power requirements are a major competitive concern.
Even with a design with a few power domains, say 4 or 5, a set of power on resettable registers are needed that provide appropriate controls for turning on/off power domains, power domain isolation control, and clock gating control for power events. Add state retention techniques to the mix, then you also have to include save and restore controls in you power manager.
Power manager or power controller is critical to the correct functionality of your chip and needs to work correct with the software interface since typical software commands include switching power on/off to a domain, enabling/disabling clock, and reset. Power states can be altered in many different ways and a pure-simulation based approach to validate all of this can be challenging. Power management features can be written as formal properties or assertions that can be formally validated by formal tools such as Synopsys’ Magellan.
Once the power management architecture is well understood, the rest of the task involves writing assertions using a properties specification language such as SystemVerilog Assertions (SVA). Some examples are as follows:
• Power Manager sequences through a set of possible states that are determined by different modes of operation of the chip. A set of properties can be written to ensure valid transitions and sequencing in this power manager under all possible circumstances.
• Various power states correspond to appropriate register values in the registers that can be programmed by software for enabling/disabling power domains and clocks. These values can be formally checked to be present upon reset. Ensuring that soft reset control does not conflict with hard reset controls leading to lock up situations.
• Power manager would typically follow a power sequencing protocol which includes relative timing of control signals which can be written as assertions with reference to appropriate number of clock cycles.
• Power domains themselves may be related in the way they power on/off. Hierarchical power domains are used which place constraints on how lower-level power domains are powered depending upon the state of higher-level power domains.
• You have to sequence power domains in test mode and JTAG access to the power controlling registers must be present by ensuring both system and JTAG clocks are running. If JTAG is connected then none of the domains on the path can be in power down mode.
Formal validation of power manager has several obvious advantages: i) It reduces the number of test cases that need to be written for validating complex power managers, ii) It reduces the amount of simulation cycles you may end using in validating some of the corner cases and difficult to target power manager bugs, iii) It allows simulation resources to be focused on remaining issues and coverage areas, and iv) It increases your verification confidence and reduces possible chances of re-spin due to a power issue. An area of further improvement from automation standpoint is more direct support of power architecture specification in terms of automatically figuring some of the formal needs for a given design.
Even with a design with a few power domains, say 4 or 5, a set of power on resettable registers are needed that provide appropriate controls for turning on/off power domains, power domain isolation control, and clock gating control for power events. Add state retention techniques to the mix, then you also have to include save and restore controls in you power manager.
Power manager or power controller is critical to the correct functionality of your chip and needs to work correct with the software interface since typical software commands include switching power on/off to a domain, enabling/disabling clock, and reset. Power states can be altered in many different ways and a pure-simulation based approach to validate all of this can be challenging. Power management features can be written as formal properties or assertions that can be formally validated by formal tools such as Synopsys’ Magellan.
Once the power management architecture is well understood, the rest of the task involves writing assertions using a properties specification language such as SystemVerilog Assertions (SVA). Some examples are as follows:
• Power Manager sequences through a set of possible states that are determined by different modes of operation of the chip. A set of properties can be written to ensure valid transitions and sequencing in this power manager under all possible circumstances.
• Various power states correspond to appropriate register values in the registers that can be programmed by software for enabling/disabling power domains and clocks. These values can be formally checked to be present upon reset. Ensuring that soft reset control does not conflict with hard reset controls leading to lock up situations.
• Power manager would typically follow a power sequencing protocol which includes relative timing of control signals which can be written as assertions with reference to appropriate number of clock cycles.
• Power domains themselves may be related in the way they power on/off. Hierarchical power domains are used which place constraints on how lower-level power domains are powered depending upon the state of higher-level power domains.
• You have to sequence power domains in test mode and JTAG access to the power controlling registers must be present by ensuring both system and JTAG clocks are running. If JTAG is connected then none of the domains on the path can be in power down mode.
Formal validation of power manager has several obvious advantages: i) It reduces the number of test cases that need to be written for validating complex power managers, ii) It reduces the amount of simulation cycles you may end using in validating some of the corner cases and difficult to target power manager bugs, iii) It allows simulation resources to be focused on remaining issues and coverage areas, and iv) It increases your verification confidence and reduces possible chances of re-spin due to a power issue. An area of further improvement from automation standpoint is more direct support of power architecture specification in terms of automatically figuring some of the formal needs for a given design.
Monday, December 7, 2009
On the Selection of Power Delivery Network in SoCs
The design and selection of a SoC power delivery network (PDN) presents unique challenges and its design is critical to achieving power consumption goals of the design. This is true when your PDN is external and based on off-the-shelf components as well as when it is being designed on-chip as part of the SoC. This article explores the external situation.
Power architecture of a given power-managed design determines various power modes of that design. Each power mode implies a set of power supply voltages and load current requirements for the PDN. These requirements drive the selection of voltage regulator modules (VRM) that supply the design with appropriate voltage and current levels in different power modes of the design. This process is a lot more challenging that it appears to be.
To begin with, you have the task of establishing target impedances to be met across a range of frequency values for the PDN and then of designing in appropriate decoupling capacitors to meet impedance goals. This is a challenging process in itself but addresses only part of the problem. The selection of appropriate VRMs to supply the design can be equally challenging. Here are some of the factors to consider:
• There are a large number of regulator suppliers such as Texas Instruments, National Semiconductor, Linear Technology, and Analog Devices to name a few.
• The PDN designer needs to carefully look into the switching and linear types of regulators to meet power efficiency and current goals.
• Input and output voltage as well as load current requirements are some of constraints to limit your search
• Power efficiency and consumption goals for the design under consideration must be met.
• Cost of the design places a limit on cost of regulators.
• You can potentially use a hierarchy of regulators to meet these goals.
All of these requirements and given a large number of choices to begin with make this task a challenging one. And it can get more complex when if you bring variable voltages into the picture. It is critical that PDN is done right because an efficient PDN is equivalent to saving a lot effort in optimizing power of the design and the job done well can give you a clear edge in time-to-market with your low power device.
Power architecture of a given power-managed design determines various power modes of that design. Each power mode implies a set of power supply voltages and load current requirements for the PDN. These requirements drive the selection of voltage regulator modules (VRM) that supply the design with appropriate voltage and current levels in different power modes of the design. This process is a lot more challenging that it appears to be.
To begin with, you have the task of establishing target impedances to be met across a range of frequency values for the PDN and then of designing in appropriate decoupling capacitors to meet impedance goals. This is a challenging process in itself but addresses only part of the problem. The selection of appropriate VRMs to supply the design can be equally challenging. Here are some of the factors to consider:
• There are a large number of regulator suppliers such as Texas Instruments, National Semiconductor, Linear Technology, and Analog Devices to name a few.
• The PDN designer needs to carefully look into the switching and linear types of regulators to meet power efficiency and current goals.
• Input and output voltage as well as load current requirements are some of constraints to limit your search
• Power efficiency and consumption goals for the design under consideration must be met.
• Cost of the design places a limit on cost of regulators.
• You can potentially use a hierarchy of regulators to meet these goals.
All of these requirements and given a large number of choices to begin with make this task a challenging one. And it can get more complex when if you bring variable voltages into the picture. It is critical that PDN is done right because an efficient PDN is equivalent to saving a lot effort in optimizing power of the design and the job done well can give you a clear edge in time-to-market with your low power device.
Wednesday, November 11, 2009
Is Power-Aware Simulation a Must-Have?
"Power-Aware Simulation" here refers to power-aware simulation-based verification. This question has been frequently asked by the designers and becomes an even more important one in the context of potentially increased cost of simulation, with or without recessionary environment.
Those contending that it is not a must-have point to:
• Power-managed designs were being done even when there was no power-aware simulation. The use of rule-based checking addressed most of power related issues and could be custom developed for a design methodology.
• The use of power format brings in a new variable and associated design methodology challenges.
• You could modify the design in a way to see the effects of power shutdowns in a regular simulation context.
• You could modify the design library for simulation to include the effects of power shutdowns. For example, the simulation definition of an AND gate would also include the supply variable VCC and could model the AND gate using the following table: (X implies a 0 or a 1, and Z means a floating value)
A | B | VCC | OUT
1 | 1 | 1 | 1
0 | X | 1 | 0
X | 0 | 1 | 0
X | X | 0 | Z
All of these are valid points but there are some significant issues that are not addressed by these solutions and there are some significant issues which are created by using these solutions. Here are some points for using power-aware simulation:
• There are several power management issues that can only be validated over a few simulation cycles and static checking of the design will not be sufficient. Some of these may indeed get addressed through the use of formal techniques. Ensuring that the proper sequencing of clock gating, power shutdown, isolation, reset and retention occurs is an example pointing to the need of a dynamic method.
• One would like validate a design early in the design cycle and not wait until gate-level simulation. This is an argument against the use of modified library for power-aware simulation. Simulations are lot slower at gate-level leading to higher costs and issues found later in the design cycle will end up costing a lot more through delays in TTM.
• Validations via design modification are effective but introduce another source of error and extra design version management costs. When you are dealing with designs with several power domains, it becomes quickly unmanageable.
• While there are issues related to the use of newly created power formats (i.e., IEEE p1801), it is much better to capture power intent once to coordinate various design tasks. Not only different tools will have a single view of intent, the verification needs to be carried out at various levels of abstraction can now be driven by the same intent.
There is a clear need for power-aware simulation in power-managed designs. While techniques based on design and/or library modifications can do the job, there is an indirect cost to using such methodologies. As power-aware simulation becomes a more mature technology and power-management of designs continue to get more complex, power-aware simulation will become a must-have starting point for chip design creation.
Those contending that it is not a must-have point to:
• Power-managed designs were being done even when there was no power-aware simulation. The use of rule-based checking addressed most of power related issues and could be custom developed for a design methodology.
• The use of power format brings in a new variable and associated design methodology challenges.
• You could modify the design in a way to see the effects of power shutdowns in a regular simulation context.
• You could modify the design library for simulation to include the effects of power shutdowns. For example, the simulation definition of an AND gate would also include the supply variable VCC and could model the AND gate using the following table: (X implies a 0 or a 1, and Z means a floating value)
A | B | VCC | OUT
1 | 1 | 1 | 1
0 | X | 1 | 0
X | 0 | 1 | 0
X | X | 0 | Z
All of these are valid points but there are some significant issues that are not addressed by these solutions and there are some significant issues which are created by using these solutions. Here are some points for using power-aware simulation:
• There are several power management issues that can only be validated over a few simulation cycles and static checking of the design will not be sufficient. Some of these may indeed get addressed through the use of formal techniques. Ensuring that the proper sequencing of clock gating, power shutdown, isolation, reset and retention occurs is an example pointing to the need of a dynamic method.
• One would like validate a design early in the design cycle and not wait until gate-level simulation. This is an argument against the use of modified library for power-aware simulation. Simulations are lot slower at gate-level leading to higher costs and issues found later in the design cycle will end up costing a lot more through delays in TTM.
• Validations via design modification are effective but introduce another source of error and extra design version management costs. When you are dealing with designs with several power domains, it becomes quickly unmanageable.
• While there are issues related to the use of newly created power formats (i.e., IEEE p1801), it is much better to capture power intent once to coordinate various design tasks. Not only different tools will have a single view of intent, the verification needs to be carried out at various levels of abstraction can now be driven by the same intent.
There is a clear need for power-aware simulation in power-managed designs. While techniques based on design and/or library modifications can do the job, there is an indirect cost to using such methodologies. As power-aware simulation becomes a more mature technology and power-management of designs continue to get more complex, power-aware simulation will become a must-have starting point for chip design creation.
Subscribe to:
Posts (Atom)
