Taming Power Aware Bugs with Questa
by Gaurav Jalan & Senthil Duraisamy, SmartPlay Technologies
The internet revolution has changed the way we share content and the mobile revolution has boosted this phenomenon in terms of content creation & consumption. Moving forward, the Internet of Things would further drive this explosion of data. As a result, the area and performance battle has taken a back seat and optimizing power consumption is at the forefront. Longer battery life for handhelds and devices running on coin cell batteries are the primary drivers for this change. Initiatives to reduce global energy consumption also play a vital role in promoting this further. Power consumption on silicon is a result of switching activity (dynamic power) and leakage (static power) with the later claiming prominence on lower process nodes. Functional profile of the devices targeting the Internet of Things e.g. sensors, suggest that there would be minimal switching activity throughout the day and leakage would be the main contributor towards power consumption if the circuit is ON all the time. Such products demand implementation of features like power shut off, multi voltage and voltage frequency scaling. Traditional HDLs (Hardware Design Languages) and simulators are alien to power on/off & voltage variations. There is a need for an additional scheme to describe the power intent of the design and a simulator to validate it. The IEEE 1801 UPF (Unified Power Format) standard defines the semantics to represent the low power features intended for a design. Questa is a simulator solution that enables verification of power aware designs. This article discusses how power aware simulations using Questa helped us identify power related bugs early in the design cycle.
Leakage power dissipation refers to the unintended gradual loss of power from a transistor when the device is powered up. Power gating, also known as ‘power shut off,’ is one of the key techniques to reduce this loss. By turning off power to the blocks that are not in use at a given time, power dissipation due to leakage can be optimized. For a given SoC, there could be different combinations of blocks that can be switched ON or OFF based on the functionality.
Each independent set of blocks that can be turned off form a power domain and the different combinations define the power modes of the chip. The primary goal is to switch the power domains seamlessly to optimize power dissipation while not compromising on the performance. A set of special cells are required to implement this scheme. These include:
- Power switches that help in switching the power on and off when desired.
- Isolation cells that minimize crowbar current in the always on block for inputs driven from powered down block and clamp these inputs to a defined value.
- Retention cells that act as shadow registers for a set of flops to retain their value when power is turned off. These cells are optimized for leakage current and function depending upon the save and restore input signals.
To ensure proper functionality, the circuit needs to follow a predefined power sequencing as shown in figure 1. The set of block(s) expected to shutdown shouldn’t be processing any data when the clock is turned off. Next, the isolation is enabled so that the output ports are driven to a known logical value based on the isolation gates placed. If there is a need for state retention, the corresponding SAVE signal is asserted. After securing the state of the block(s), reset is asserted for them to ensure that on power up they start from initial state. Finally after reset, the blocks can be powered down. The logic remains shut down till a WAKEUP from any of the sources is received. On receiving a wakeup request, the power is gradually applied through a series of switches to avoid in rush current. Once powered up, reset to the block(s) is de-asserted. After the design is in initial state, the RESTORE signal is applied to bring the block(s) to a desired state by copying the values of the shadow registers to the functional ones. At this point the block is ready to start functionality from a desired state that may not be the initial state. The isolation is disabled next followed by enabling the clocks to the block finally. This brings back life to the whole circuit.
While the above sequence of events seems to be simple, most of the bugs in low power designs are found in and around this scheme. Along with RTL, UPF is required by the implementation tools to insert correct cells in the design. Both RTL & UPF needs to be verified for power aware scenarios to ensure there are no bugs in either of them. The focus of power aware verification is not only to verify the above sequence alone but revolves around the implications these transactions have on the DUT. Thus, power aware verification requires additional functionality that the simulator needs to support, e.g.,
- The simulator should be capable of emulating the power architecture in RTL design based on UPF specification and insert required power aware special cells during simulations.
- On power gating, the output of the powered down blocks should be driven to X. The simulator needs to emulate the behaviour of isolation cells in the RTL as specified in the corresponding UPF. Any errors resulting from missing isolation cells, incorrect isolation cell selection, incorrect placement and issues with isolation control would be discovered in this process.
- When state retention is enabled, the simulator needs to emulate the behaviour of a shadow register and corrupt the value of functional register/memory to ensure that when restore happens, the DUT is retained to a desired state. Any errors resulting from missing state retention cells, incorrect control logic connections and incorrect placements are discovered in this process.
Following are some of the bugs that we encountered while verifying power aware design with Questa & UPF.
Figure 2 is a representative version of the design with low power features implemented. The green box implements the power state machines to control the complete power sequencing similar to what is described in Figure 1. This block is in ‘always ON’ domain i.e. there is no case when the chip will be powered but this logic will be shut down. The blue block is the baseband while the red block is RF. There are 2 power domains defined wherein the baseband can be shutdown independently of RF (Sleep mode) or both baseband and RF can be shut down together (Deep Sleep mode). In absence of qualified signals from RF for a defined period, the power manager initiates Sleep mode. During Sleep mode, if there is a wake up interrupt (from different sources with one represented here), the power manager initiates the wake up cycle. To avoid re-initialization of the baseband, it is expected that the last functional state of the baseband be retained. State retention cells help in saving the state of the block and restoring it when required.
Case 1: Incorrect Specification of Save Signal UPF
The waveforms below show the Sleep power cycle for the baseband IP using UPF with Questa. When the baseband is powered up again, the state is not restored and instead the signals show X, a clear indication that save and restore didn’t happen. On debugging, a bug was found in UPF wherein the SAVE signal to the retention cells was defined to be active LOW. Due to this the pulse generated for SAVE by power manager didn’t have the desired effect.
In the waveforms below, the SAVE pulse was sent to preserve the current state of DUT in retention cells. Since the UPF suggested that the retention cells would save when control signal is LOW, the value saved was incorrect. The bug was root caused to the understanding of the UPF developer who defined LOW assuming that the SAVE should happen when there is a transition from HIGH to LOW while the correct interpretation should have been that when there is an active HIGH pulse on SAVE the values should be preserved. By replacing LOW by HIGH in UPF the problem was resolved.
Case 2: Missing Retention Cell Between Power Domains
Referring to figure 2 again, the RF_enable input is driven from the baseband. During Normal mode of operation, the baseband would drive this signal based on the value programmed in the register. During Sleep mode, the baseband can be off while the RF continues to be on. To ensure there is no crowbar current, an isolation cell is declared at the output of baseband that clamps the value of RF_enable to HIGH. The UPF developer however forgot to retain the value of the register driving this RF_enable during powered on state. This resulted in a bug captured in the waveform below.
During NORMAL operation, the value of RF_enable is HIGH. Once isolated, the value continues to be HIGH while the baseband is powered off. When the baseband is powered on, the isolation is removed and after the clock is enabled, the default value of the register is driven. Since the default value is ZERO, the RF block actually gets functionally disabled when the baseband is fully functional. After adding a state retention cell to the UPF for this register, desired functionality is achieved. The rectified waveform with save and restore is shown below.
Case 3: Incorrect Connection of Power Supply to Power Domains
Referring back to figure 2, there are 2 voltage supplies each connected to the baseband (digital) and RF (analog) blocks. These supplies aren’t present in RTL and specified in the UPF. Corresponding to these supplies there are power switches with the enable to the switches coming from power manager based on the Sleep or Deep sleep mode. In this case, the UPF definition had an incorrect connection to the power switch for RF. As a result, during power aware simulations, in Sleep mode, instead of turning off the baseband alone, the RF was also turned off i.e. instead of Sleep mode, the chip actually went into Deep sleep mode. The effect of this is shown in the waveform above.
The power_on_domain1 signal drives Sleep mode. Instead of shutting off the baseband alone, the RF was also shut off (see the bug above).
On correcting the power switch enable connection to power_on_domain2, the expected functionality is simulated.
There has been a multi-fold increase in verification complexity as the industry moves toward handhelds and Internet of Things. Traditional simulators fall short of enabling the engineers with power aware verification as the concept of voltage is missing in our HDLs and therefore with these simulators. Power formats such as UPF have enabled the designers to express this functionality. However simulating power shut down, voltage variations and voltage ramp up scenarios demand additional capability from simulators. Apart from having a notion of voltage the simulator also needs to emulate insertion of isolation, state retention, level shifters and power switches as defined in the UPF. Formal tools help in validating the UPF to a large extent but cannot cover the complete scope of power aware verification. Power aware simulations at system level assist in discovering bugs as per power definition and its result on the overall functionality of the design. As Albert Einstein quoted – “No amount of experimentation can ever prove me right; a single experiment can prove me wrong”. With the right apparatus and methodical approach the probability of hitting that single experiment definitely improves.