Two common queries that customers pose to a design house is whether an existing or new IP can be made "low power" or if "power aware" verification can be carried out on an IP. The IEEE standard – P1801 captures what one may call the syntax and semantics to express the intent of the power architecture of a design. Merely adopting the standard (commonly known as the Unified Power Format) doesn't help. What it really takes to successfully achieve a low power design is design team know-how and a simulation tool that is geared towards low power implementation. This article captures how we use Mentor's Questa® Simulator to lower the power usage of our legacy USB IP. We also share how to start a low power implementation and provide some examples from our current effort.
LOW POWER METHODOLOGY IN A NUTSHELL
When we decided to do a low power design implementation for our existing IP, we were not sure how to get started. We had the basic understanding that power is saved in a digital circuit when:
- The switching activity of the circuit is reduced (reducing dynamic power consumption).
- Low static current consumption cells are used for parts of the design that don't switch often (reducing static power consumption).
But the trick for creating a low power architecture lies in reading through the specification document using a "power aware lens"! This means having low power techniques in mind at the beginning of your design work. Don't wait until later in the flow.
CREATING THE LOW POWER DESIGN ARCHITECTURE
Our team initiated the process of converting a legacy USB 2.0 (supporting full speed, high speed, and low speed) function controller to low power by using several low power techniques. These include clock gating, power gating, multi threshold design, multi rail design (also known as multiple power domain design), logic-level power optimization, and dynamic voltage frequency scaling. For the purpose of this article, we will focus on clock and power gating.
Using these techniques, we created our first power architecture for our USB 2.0 function controller. The legacy IP had the following internal blocks.
- Host Interface: Essentially a FSM that interfaces with a standard microcontroller bus. This block reacts to the read and write cycles from the microcontroller and generates interrupts when configured to do so.
- The Configuration and Status Registers: A set of registers that capture the operating parameters and status of the IP.
- FIFO and FIFO Controller: A FIFO to store the end-point data.
- Tx-Rx Controller: The controller that interprets the serial data and lends the notion of "end points" to the device.
- Phy (Bus) Controller: This block interacts with the transceiver and interprets the bus state and generates the serial data for the use of the Tx-Rx controller.
When we started the low power implementation, a Power Manager block was added. This block captures the logic required to monitor and control the various power management aspects of the design.
USE OF POWER GATING
We had the first hint of implementing power savings using power gating from the specification document itself and we are quoting verbatim for reference.
Section 4.3.2 Power Management: A USB host may have a power management system that is independent of the USB. The USB System Software interacts with the host's power management system to handle system power events such as suspend or resume. Additionally, USB devices typically implement additional power management features that allow them to be power managed by system software.
The power distribution and power management features of the USB allow it to be designed into power sensitive systems such as battery-based notebook computers.
The changes to the original architecture that we reviewed were as follows:
 |
Table 1.
Another reason to implement a separate power domain for the USB "core" is to run the core at 3.3V while the logic associated with the "bus" can run at 5V, which is the standard voltage supply on a USB bus. (The above discussion is not the complete perspective on the suspend state. The specification mentions dependencies on/from the suspend state which need to be handled carefully. See section "7.1.7.6 Suspending".)
USUE OF CLOCK SCALING
The USB standard defines an IDLE state as: a state that is entered at the end of a packet transmission and the bus is floated because no more transactions are expected for a given duration. Since no transactions are expected, we saw an opportunity to save power. One cannot consider power gating, because in Section "7.1.7.6 Suspending", the USB specification states:
All devices must support the Suspend state. Devices can go into the Suspend state from any powered state. They begin the transition to the Suspend state after they see a constant Idle state on their upstream facing bus lines for more than 3.0 ms. The device must actually be suspended, drawing only suspend current from the bus after no more than 10 ms of bus inactivity on all its ports.
Note: The Full Speed, High Speed and Low Speed specifications define the Idle state. However, the line conditions for the Idle state are different across the three speeds. A USB 2.0 implementation must take special care while interpreting the Idle state.
The specification implicitly states that the bus may exit from the idle state within 3 ms, and the suspend state will follow (a state where we have decided to implement power gating). Recovering from power gating is a lengthy process (due to the steps involved to restore from retention), and the blocks should be able to react if any transaction is detected. Thus, clock gating is preferred as compared to power gating. The following blocks were implemented using clock gating: FIFO and FIFO controller; and the Tx-Rx controller. The other blocks need to remain active so as to capture and react to the transactions on the bus. The "always-on" bus controller could further save power by using a lower clock frequency and return to its normal clock when a bus transaction is detected.
The changes to the original architecture that we reviewed were as follows:
 |
Table 2.
• Note: The USB 2.0 specification states more implementation details of the Suspend and Resume state in other sections (notable sections 7.1.7.6 Suspending through 7.1.7.7 Resume). These parts have not been considered here because this article is limited to our IP which is a function controller. A host or hub controller would have to consider those sections in their power architecture.
POWER AWARE VERIFICATION
When a design team starts implementing a low power design, the design managers have a choice:
- Should the low power behavior be included as part of the RTL?
- Should the RTL be instrumented with a layer of the power intent captured in a UPF file?
The major disadvantage of using the first approach is that true low power verification can happen only after the gate-level netlist is available. This causes the low power verification to start late in the design cycle. Even after the gate-level netlist is available, simulation times, debug time, and error correction time is extremely high. The UPF provides the advantages of a modular approach coupled with early detection of low power implementation errors. We chose to use Questa's support for UPF and benefited from it.
We wrote targeted testcases to ensure:
- All power states were covered using assertions.
- Every power state was entered and exited correctly.
- The isolation and retention cells did not allow corruption of state information on critical signals.
The current set of testcases target the various coverage points captured in the verification plan. The next challenge is to create a verification infrastructure that can automatically generate low power scenarios without violating the power sequencing rules.
During verification, the most critical changes were in the Power Manager's FSM. It took us a while to get the power sequencing correct. The available literature suggests that there is scope for more power savings, especially in the "core" blocks where there is scope for clock scaling in low speed and full speed modes.
CONCLUSION
The techniques put forth here led to a successful implementation of a low power USB 2.0 IP.
 |
Figure 1. Clock Scaling
 |
Figure 2. Power Gating
The waveforms above show the two cases discussed earlier as they appeared in our design. The timeline has been artificially manipulated to fit the waveforms in the available space. The original simulation runs are much longer.
REFERENCES
- Low Power Design and Verification Techniques - Stephen Bailey, Gabriel Chidolue, Allan Crone; Mentor, a Siemens Business
- USB 2.0 Specification
Back to Top
