Smart phones and tablets mandate that designers place equal, if not more, emphasis on optimizing power consumption. Everyone wants a fast device, high resolution graphics, and light weight, but they don’t want to be chained to their battery chargers. Reducing power consumption is high on everyone’s list.
There are several different approaches to reduce power consumption and thereby produce a smaller, lightweight battery. One is to run the device slower and display low-resolution graphics; this is not acceptable! It is acceptable to power down any applications that are not in use at a given point in time. It is also okay to use different voltages for different operations, lowering power by judiciously lowering voltage levels. This is what most chip companies are doing. But you can improve upon all of these techniques by finding the actual power consumption of an SoC and using that information to intelligently design the correct battery power.
There are many things to consider. Low-power management allows designers to divide designs into several power domains. Each domain can be operated with a unique voltage level and can be powered on and off without interfering with the functionality of other domains. This requires isolation between power ON domains and power OFF domains. When an OFF domain needs to wake up, it requires some basic information to come back ON correctly; designers use retention techniques to preserve this information while the domain is switched off. The more information you retain, the more real estate you need, but the domain will wake up faster, and vice versa. You have to be aware that the states in the power OFF domain without retention infrastructure will go to unknown values. You need to add level shifters to operate domains at different voltages. All this functionality requires thorough verification, and things become even more complex when power control logic resides in hardware and the actual controls come from software. This requires a platform that allows system-level validation where hardware and software can play together.
Yet, it does not stop there; there are several different ways to specify power intent. Designers can inline the power intent directly in the RTL code. Some EDA vendors still support an old way of specifying power intent: the Common Power Format (CPF). However the majority of EDA vendors now support the Unified Power Format (UPF) standard, which is formalized by IEEE 1801. If you would like to stay vendor neutral, then use UPF because it is the standard going forward.
Similarly, realistic average and peak power analysis can be done only by applying application-specific stimuli at the system level, and they require running very long tests to ensure that actual power peaks are captured.
Power analysis using Veloce.
The Veloce SoC verification engine enables low power management verification and power analysis at the system level, where both software and hardware operate together and you can apply real-world stimulus to the design under test. The speed of emulation allows you to run extremely long tests in a short amount of time. This allows designers and verification teams to boot the operating system and stress test the design through a very large number of power sequences extremely quickly. Veloce is fully aligned with the Questa® simulator, enabling you to use the same UPF files and UPF constructs for both simulation and emulation. Veloce delivers a complete solution covering both power management and power analysis capabilities, using a single engine at the system-level with flexible options for applying stimuli. It provides interfaces to standard power analysis tools and adheres to UPF standards, cutting the learning curve for new users and preserving your company’s investments.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply