by Gayathri SN and Badrinath Ramachandra, L&T Technology Services Limited
Power management is a major concern throughout the chip design flow from architectural design to RTL implementation and physical design. Multi-power domain SoCs are complex and present new integration and verification challenges because many blocks have different operating modes at different voltages, different clock period and duty cycles of each block being awake, asleep or in shutdown mode. USB 3.0 or USB 2.0 Lower Layer resides in an always on power domain. This block has to be powered-on always for normal USB functionality and also to initiate suspend and wake-up sequences. If Link settles in USB 2.0 mode, USB 3.0 Lower Layer can be powered off. If Link settles in USB 3.0 mode, USB 2.0 Lower Layer can be powered off. USB 3.0 Lower Layer and USB 2.0 Lower Layer can operate at different power supplies.
Mobile Devices which use standards like USB3 have raised the need for higher battery life. This means that USB3 designs need to be implemented with PowerAware architecture using low power techniques. Power to the application Layer which includes the DMA controller block can be turned on or off depending on the data transfers and also on the USB Link Power states. This block will typically be powered off when the link is placed in Suspend State.
PowerAware verification for USB3 is a challenging task as there are numerous rules and conditions defined in the USB 3.0 Specification for lower, active and idle power management to ensure that USB3.0 designs are power efficient. Also it must ensure that the design specific power management circuitry functions as expected, and also that the overall chip functionality is not corrupted by the power intent described in the UPF descriptions.
This paper describes a specific Power Management scheme used in USB3.0 Device IP controller. It also describes how Questa ® PowerAware helped IP designers realize reliable, accurate and scalable low power architectures and comprehensive verification of these architectures. Additionally this also shares the experience in using the UPF to define various power domains, isolation strategies and methods to control power states from the testbench.
1. DESIGN UNDER VERIFICATION
The design under verification is an USB3 SoC IP Controller. The corresponding block diagram inclusive of the power architecture is shown on the following page in Figure 2, “Various Power management Schemes in IP Controller.” The USB3 SoC IP Controller consists of three major blocks.
- USB 3.0 Lower Layers, which includes the Link Layer/Protocol Layer
- USB 2.0 Lower Layer which includes the Protocol Layer
- An application Layer, which includes a DMA Controller
2. POWER MANAGEMENT SCHEMES IN USB3 IP CONTROLLER
SuperSpeed USB enables considerable power savings by enabling both upstream and downstream ports to initiate lower power states on the link. In addition multiple link power states are defined, enabling local power management control and therefore improved power usage efficiency. The increased speed and efficiency of USB 3.0 bus – combined with the ability to use data streaming for bulk transfers – further reduces the power profile of these devices.
The various Power Management techniques used in DUT are as follows.
1. Since the DUT is USB3 IP Controller, power management scheme as per USB3 spec is implemented. The power state table as per USB3 spec is shown below.
Four link power states are defined for power management:
- U0 – normal operational mode
- U1 – Link idle with fast exit (PLL remains on)
- U2 – Link idle with slow exit (PLL may be off)
- U3 – Suspend
U1, U2, U3 have increasingly longer wakeup times than U0, and thus allow transmitters to go into increasingly deeper sleep. The link state table for USB3 is shown below.
|Table 1: USB 3.0 Link Low Power characteristics
||Link Idle, Fast Exit
||RX & TX quiesced
||On or Off
||Link Idle, Slow Exit
||Clock gen circuit also quiesced
||On or Off
||μs – ms
||Portions of device power removed
|Table 2: USB 2.0 Link Low Power Characteristics
||Explicitly entered via LPM extended transaction
||Implicitly entered via 3ms of link inactivity
||Device or host-initiated via resume signaling; Remote-wake can be (optionally) enabled/ disabled via the LPM transaction. Device- or host-initiated via resume signaling;
||Device-initiated resumes can be (optionally) enabled/disabled by software
||Entry: ~10us Exit: ~70 us to 1ms (host-specific)
||Entry: ~3ms Exit: >0ms (OS-dependent)
|Device Power Consumption
||Device power consumption level is application and implementation specific
||Device power consumption is limited to: ≤500 uA or ≤2.5mA
2. The USB 2.0 power-management was enhanced with the introduction of Link Power Management (LPM) in the EHCI specification 1.1. The new LPM transaction is similar to the existing USB 2.0 suspend/resume capability, however—it defines a mechanism for faster transition of a root port from an enabled state (L0) to a new sleep state (L1). USB2 specification specifies 4 power management states as follows:
- L0 (On)
- L1 (Sleep): New & finer granularity
- L2 (Suspend)
- L3 (Off)
3. Apart from the USB3 Specification defined Power Management schemes, the IP controller also implements design specific Power Management scheme, basically power gating for the USB3/USB2 Lower layer and Application layer. The power state table for design specific Power Management scheme is shown below. This corresponds to UPF1 power architecture of Figure 1: Scalable Power Architectures with UPF Flow.
|Power State Table
||PD 1 – USB Lower Layer
|| PD 2 – DMA controller
4. Multi-Voltage Supply where in the USB2 and USB3 Lower Layers can reside in power domains operating at different supply voltage levels since USB2 data rates are almost 10 times lower than USB3 data rates. This scheme is applied in power architecture defined by UPF2 of Figure 1: Scalable Power Architectures with UPF Flow.
5. Dynamic Voltage and Frequency scaling of the application layer is possible and the processor can scale this based on the average system bandwidth requirement of the current function active on the USB link. This scheme is applied in power architecture defined by UPF2 of Figure 1: Scalable Power Architectures with UPF Flow.
6. Clock gating scheme was also used in USB3/USB2 layers where during U3/Suspend state the clocks gets turned off.
Figure 1. Scalable Power Architecture wit UPF Flow
Figure 2. Various Power Management Schemes in IP Controller
7. Memory splitting where in the data for different Endpoints reside in different memory regions.
8. Operand Isolation where in the data path blocks are controlled by an enable signal.
3. OBJECTIVES TO MOVE TOWARDS POWERAWARE VERIFICATION
PowerAware verification is a challenging task. It must ensure that design-specific power management circuitry function as expected, and that the overall chip functionality is not corrupted by the power intent described in the UPF.
A non-PowerAware simulation can ensure correct func- tionality when all power supplies are turned on. This is always run before the low-power modes are enabled. In low-power modes, the simulator needs to perform special tasks to support power shut off and low-power cell insertion. The following considerations become essential during PowerAware verification of the USB 3.0 IP.
- Ensuring that the IP architecture is using the USB3 link power modes correctly.
- Verifying the communication between different power domains namely the USB3 lower layer and DMA application layer.
- Verifying the transitions between different power modes and states in both domains.
- Ensuring that isolation, state retention, and power shutoff are handled properly, and that the IP controller can power on correctly within a given time period.
4. UPF FLOW FOR HIERARCHICAL SUPPORT FOR IP AND DESIGN REUSE
- The UPF design flow consisting of both power intent specification and functional specification helps define a hierarchical precedence mechanism.
- For bottom-up reuse, power design intent has been developed along with the functional implementation of an IP.
- Constructs such as power shutoff corruption, power switches, save/restore logic, and isolation should be described in the UPF file, not the RTL.
- For soft IP, it must be reusable for the integration of the IP without having to rewrite the intent specification at the SoC level.
- For top-down constraint of lower-level IP implementation, the chip-level power design intent is created. Lower- level blocks must have their power design constraints derived from this chip-level description. The chip-level context must also be visible during IP implementation, so that IP implementation is done with the knowledge of the power domains, including both external boundary level power domains and state conditions.
- All of this can be done with UPF while staying at the abstract level, without doing manual design or floor planning, and without specifying the IP instance by instance.
- RTL requires no changes for verifying various Power Architecture, only the UPF gets modified.
5. NEED FOR A POWERAWARE TOOL
The PowerAware tool should share a coherent view of the power architecture with respect to the UPF. The Tool should also have a native understanding of power intent. Also it needs to understand low-power states and requirements. If a test unexpectedly forces a power event, for instance, the tool must be able to recognize that. This is only practical if a tool provides high performance for low-power verification.
To leverage IP and design reuse in an advanced, power- managed design, both tools and the format must support hierarchical usage of power intent descriptions. The simulator needs to model the behaviors described in the UPF file during power-down and power-up sequences.
During power-down, the simulator needs to consider isolation and state retention. During power-off, the simulator models the corruption of data internal to the power domain by setting all the internal values to Xs. Also during power- up, the simulator models the restoration of power to the domain.
Apart from having the above features, given a description of power intent expressed in the industry-standard Unified Power Format (UPF), the Questa PowerAware Simulator
- Partitions the HDL design into power domains
- Adds isolation, level-shifting, and retention cells
- Integrates the power supply network into the design to power each domain
6. QUESTA POWERAWARE VERIFICATION PROCESS FLOW
- Create Design Specification and Power Intent Specification
- Create design files
- Create Power intent/source file (also called as UPF)
- Create PowerAware Test Environment Specification
- Create PowerAware Test environment which includes a power controller model
- Create Power state table sequencing
- Create Test scenarios which could do random power switching
7. UPF CONSISTS OF
- Power domain creation
- Two power domains were created— one for the USB3 Lower Layer and one for the Application Layer
- Supply port creation
- Primary Power and Ground Port defined for the IP Controller.
- Supply net creation
- Nets with respect to the Power Ports defined.
- Power switch creation
- Power switch created with respect to Application layer domain.
- Power state table definition
- Power state table for both power domains defined.
- Retention strategy definition
Retention strategies with respect to both power domains.
- Isolation strategy definition
- Isolation strategies with respect to ports defined for Application layer.
8. TEST SCENARIOS:
The following were a few scenarios that were covered to check the low power conditions of the Design.
- Basic power up on both power domains.
- Randomly Power up and down the Application layer.
- Check for isolation properties on the ports of the Application layer, when power switching is randomized.
- Check for retention properties when moving from U3 Low power state / USB2 Suspend to Active state.
The following issues can be uncovered during PowerAware verification which would otherwise be easily missed in normal verification.
- X propagation in the Application Layer Interface during power on and off of the Application layer
- Issues related to Retention states / logic in USB3 Lower layer during exit from U3 state.
- Issues related to Retention states / logic in USB2 Lower layer when exiting suspend state
- Issues related to switch-on time of the on-board power switch
- Issues related to reset release after power up sequence.
- Issues related to power state sequencing.
- Connectivity issues between multiple power well domains.
Low-power design requirements of current generation SoC utilizing USB 3.0 IP’s introduce significant verification complexity. USB 3.0 IP’s inherently are designed to address a wide range of low power application scenarios. Architecting the IP for each specific low power application scenario can become very tedious and error prone if the power architecture requirements are to be embedded directly into the RTL. Additionally, verifying the IP to meet the wide ranging power architecture becomes very challenging and can affect the schedule badly if issues are found late in the design cycle. Much has been done in the digital design space to address this verification complexity and minimize impact to overall design schedule. Some of the key components of this solution are based on UPF power intent file, low-power structural verification, and state corruption for low-power simulation. Mentor’s Questa PowerAware RTL verification methodology helps in defining multiple power architectures without changing the RTL by defining the power architecture in a power intent UPF file independent of the RTL and provides an easy mechanism to verify the functional behavior of the IP by including the UPF file in an RTL verification environment. As seen above, Questa PowerAware verification at early RTL stage can save sufficient debug time.
- A Practical Guide to Low-Power Design-User Experience with CPF
- Power Aware Verification Tech Talk
Back to Top