Electronic Design

Take Advantage Of All That USB On-The-Go Has To Offer

A USB OTG controller can be easily integrated onto an ASIC that’s based on different processors and operating systems.

DESIGN VIEW is the summary of the complete DESIGN SOLUTION contributed article, which begins on Page 2.

Until very recently, no common interface existed between handheld devices and PC peripherals. Then, this past January, Sony released the CLIE personal digital assistant with Universal Serial Bus On-The-Go (USB OTG) functionality. Developed by the USB Implementers Forum (USB-IF), the USB OTG specification provides a common, interoperable solution.

In addition to full USB device functionality, USB OTG confers limited USB host functionality on all handheld devices and PC peripherals. The result is, for example, a PDA or camera that can connect directly to any printer, or a PDA that can download files directly to a portable USB hard-disk drive or CD-RW drive—with no PC to act as an intermediary.

USB has emerged as a popular and necessary interface on nearly every PC and peripheral device that communicates with a PC. With a bandwidth of up to 12 Mbits/s for full-speed and 480 Mbits/s for high-speed mode, USB has more than sufficient bandwidth for consumer applications.

USB OTG provides a cost-effective solution for PDAs, mobile phones, and other handheld devices to communicate among themselves, as well as with any USB peripheral anywhere, anytime. USB OTG products can have both USB-host and peripheral-controller functions on one chip. Thus, the chip can act as a USB host supporting high-, full-, and low-speed devices, or as a USB peripheral itself. Host and peripheral roles can be interchanged through the Host Negotiation Protocol (HNP). Because HNP allows the host function to be transferred between two devices, there's no need to switch cables. With this feature, manufacturers of dual-role devices can specify which peripherals their device will support.

The article digs into the design of a USB dual-role controller, particularly its three main modules: the USB host controller, USB device controller, and OTG module. Also discussed is SRP (Session Request Protocol) and HNP implementation. It stresses that implementing HNP in software is best, due to the inherent flexibility. However, hardware is recommended to deal with the interrupt-latency problem.

HIGHLIGHTS:
Dual Functionality USB-host and peripheral-controller functions can both be included on one chip in USB-OTG products. However, dual-role controller design can pose some challenges. The design consists of three major modules:
1. Host Controller An embedded host controller (HC) IC should perform on par with a PC host and may support up to five levels of Hub. In a flexible design, it will interface to any microprocessor peripheral bus.
2. Device Controller The device controller (DC) must support a high-performance USB interface device with an integrated Serial Interface Engine (SIE), buffer memory, and transceiver.
3. OTG Module The OTG Module supplies analog parts, timers, and a set of status and control registers to support software implementation of the SRP and HNP. It also provides a power-management circuit for power-down and to waken for specific events.
Implementing SRP/HNP OTG allows for various implementations of SRP/HNP. Possibilities include session-based, insertion-based, or hybrid-based. The OTG module provides status and control registers for software to do the implementation.

Full article begins on Page 2

Until very recently, no common interface existed between handheld devices and PC peripherals. Manufacturers had to make proprietary modifications to the Universal Serial Bus (USB) standard and to USB connectors in order to directly connect a digital camera to a printer—the most common application. Then, this past January, Sony released the CLIE personal digital assistant (PDA) with USB On-The-Go (OTG) functionality.

Developed by the USB Implementers Forum (USB-IF), the USB OTG specification provides a common, interoperable solution. In addition to full USB device functionality, USB OTG confers limited USB host functionality on all handheld devices and PC peripherals. The result is, for example, a PDA or camera that can connect directly to any printer, or a PDA that can download files directly to a portable USB hard disk drive or CD-RW drive—with no PC to act as an intermediary.

UBIQUITOUS USB
USB has emerged as a popular and necessary interface on nearly every PC and peripheral device that communicates with the PC. Today, USB is an accepted and recognized standard, as well as a must-have interface for the consumer. With a bandwidth of up to 12 Mbits/s for full-speed and 480 Mbits/s for high-speed mode, USB has more than sufficient bandwidth for consumer applications.

Currently, almost all PC peripherals, cameras, PDAs, mobile phones, and set-top boxes come with USB ports. Leveraging existing USB ports in most peripherals, USB OTG easily catalyzes this interface into a truly portable "On-The-Go" interface standard for consumer peripherals.

DUAL FUNCTIONALITY
With the explosion of microprocessor-powered handheld devices such as PDAs, mobile phones, and digital cameras, there’s a rapidly growing desire to be mobile and not be tied to a desktop PC. USB OTG provides a cost-effective solution for PDAs, mobile phones, and other handheld devices to communicate among themselves, as well as with any USB peripheral anywhere, anytime.

USB OTG products can have both USB-host and peripheral-controller functions on one chip. Such devices are called "dual-role." Thanks to these capabilities, the chip can act as a USB host supporting high-, full-, and low-speed devices, or as a USB peripheral itself. Host and peripheral roles can be interchanged through the Host Negotiation Protocol (HNP). The HNP feature, which allows the host function to be transferred between two devices, eliminates the need to switch cables. By using this feature, manufacturers of dual-role devices can specify which peripherals their device will support. A USB OTG dual-role controller design poses some challenges, however. The design consists of three major modules:

  • USB host controller
  • USB device controller
  • OTG module, which incorporates the:
  • OTG HNP
  • Analog portions (charge pump, transceiver, and voltage-level detector)
  • Software drivers for the IC

HOST CONTROLLER
An embedded host controller (HC) IC should perform on par with a PC host, and may support up to five levels of Hub. In a PC, the HC uses a bus-mastering protocol through the PCI bus. For ease of design into a customer’s existing products, an HC should not be a bus master, but rather a slave-only HC. Control of the memory bus isn’t required. The microprocessor merely needs to send its Transfer Descriptor and its payload to the slave host, after which the slave host will process the Transfer Descriptor and deliver USB data downstream. In a flexible design, this controller will interface to any microprocessor peripheral bus. A USB OTG dual-role controller will minimize a customer’s design-in effort with the following features:

  • Slave-only bus protocol
  • Sufficient built-in RAM
  • Software (OHCI-like) driver to permit software reusability
  • CPU interface that supports indirect address or memory-mapped address
  • Low rate of CPU interrupts to the microprocessor, while still giving maximum USB performance
  • USB Transfer Descriptor protocol that maximizes the isochronous, interrupt, and bulk-transfer bandwidth of the USB bus

A slave-only bus protocol needs just the CPU to read and write to the HC via the parallel bus or slave DMA. The HC won’t master the data bus. This is important because USB is typically not a major function in a product. Instead, it’s a value-added, connectivity feature.

A low rate of interrupts is crucial because we have to consider the software drivers to be ported to various real-time operating systems. Interrupt service routines from these operating systems can vary from microseconds to milliseconds, depending on the needs of the entire system. A low rate of interrupts will yield maximum USB performance, while preserving the performance of the application’s major function. The protocol for the different USB transfer descriptor types has been designed to handle multiple USB data transactions, which stretch across the USB-defined millisecond periods (frames) of transfer.

DEVICE CONTROLLER
The device controller (DC) must support a high-performance USB interface device with an integrated Serial Interface Engine (SIE), buffer memory, and transceiver. It also must accommodate fully autonomous and multi-configuration DMA operation. The HC should handle up to 14 programmable USB endpoints with two fixed-control IN/OUT endpoints, 2462 bytes of integrated physical multi-configuration memory, and endpoints with double buffering to increase throughput and ease real-time data transfer.

The ping-pong buffer RAM for the DC is independent of the buffer RAM for the HC. When the buffer RAM is full, the DC transfers the data in the buffer RAM to the USB bus. When the buffer RAM is empty, an interrupt is generated to notify the microprocessor to feed in data. Data transfer between a microprocessor and the DC can be done in either the Programmed I/O (PIO) mode or the direct-memory-access (DMA) mode.

In addition, the DC has its own independent RAM, which is only necessary when the user requires the device and the host to function simultaneously. To switch from host to peripheral and peripheral to host, the OTG controller module must monitor some states in the device and the host for a safe switch, as well as meet the specification of the OTG HNP protocol.

OTG MODULE
The OTG module supplies analog parts, timers, and a set of status and control registers to support software implementation of Session Request Protocol (SRP) and the HNP. Also, the OTG module provides a power-management circuit that allows the chip to enter the power-down state and be woken up by specific events. The integrated analog parts include:

  • A USB analog transceiver (ATX)
  • Pull-up and pull-down resistors on the D+ and D- lines
  • A built-in 5-V charge pump
  • VBUS voltage comparators
  • Pull-up and pull-down resistors on the VBUS
  • An ID detector

For up to 12-Mbit/s operation, the USB ATX should be able to signal data transfers at full speed and low speed. The ATX must support high-speed for up to 480-Mbit/s transfers.

The VBUS voltage comparators include the VBUS voltage detectors for va_vbus_vld (>4.4 V), va_sess_vld (0.8 to 2.0 V), vb_sess_vld (2.0 to 4.0 V), and vb_sess_end (<0.8 V). The pull-up and pull-down resistors on the VBUS charge and discharge, respectively, the VBUS voltage to perform VBUS pulsing SRP.

The pull-up resistor on the D+ line is implemented with a variable pull-up resistor scheme due to the wider tolerance of on-chip resistance (up to ±27%). When the USB bus is idle, a 900- to 1575-Ω resistor is used to keep the idle voltage above 2.7 V. When the USB bus is transmitting data, a 1425- to 3090-Ω resistor is used to maintain the signal quality (Fig. 1).

The built-in 5-V charge pump provides the power source to the VBUS line in battery-powered handheld devices, which normally have a range of VBAT between 2.7 and 4.5 V. The charge pump is limited in the amount of current it can provide to the VBUS load. It’s recommended that the design should allow an external 5-V source to drive VBUS to support those applications that require more current (such as a set-top box, which may need to support up to 500 µA to VBUS).

The ID detector will ascertain whether a mini-A or mini-B plug is connected to the mini-AB receptacle or not. If a mini-A plug is detected, the device assumes the role of a host and is called an A device. A mini-B plug dictates peripheral behavior and is called the B device.

For a device that supports the mini-USB analog car kit application, the ID detector needs to identify if the ID pin is resistively connected to ground or is floating. If an internal pull-up resistor is used in the ID detector, it’s recommended that this resistor be switched off when ID is shorted to ground and the bus is idle. This keeps the idle current as low as possible, which is extremely important in a battery-powered device.

SRP/HNP IMPLEMENTATION
OTG allows various implementations of SRP/HNP. Possibilities include session-based, insertion-based, or hybrid-based. Software implementation of SRP/HNP allows maximum flexibility for different applications.

From our experience, implementing the HNP in hardware doesn’t provide any performance improvement to the OTG protocol. As long as certain critical timings are taken care of in hardware, software-implemented HNP has the advantage of being flexible. The software HNP can always be modified to inter-operate with the all-present OTG devices and future controllers that will be introduced to the OTG market. The OTG module will provide status and control registers for software to implement SRP/HNP. These registers include:

  • OTG status register
  • OTG control register
  • OTG interrupt register
  • OTG timers

In a software implementation, interrupt latency could cause a problem for HNP-state transitions that require under 5-ms response times. For this reason, it’s recommended that hardware be used to take care of these state transitions.

AUTO CONNECT
In the OTG HNP-state diagram, when the A-device is in A_SUSPEND state, it must enable its pull-up resistor on the D+ line within 3 ms upon detection of the B-device being disconnected. If the auto-connect feature is implemented in the hardware, and the feature is enabled when the A-device enters the A_SUSPEND state, then the A-device will automatically enable its pull-up on the D+ line upon detecting a disconnection.

AUTO RESET
In the OTG HNP-state diagram, when the B-device is in the B_WAIT_ACON state, it must send bus reset within 1 ms upon detection of the A-device being connected. If the auto-reset feature is implemented in the hardware, and the feature is enabled when the B-device enters the B_WAIT_ACON state, the B-device will automatically send bus reset upon detecting a connection.

BUS RESUME
In the USB 2.0 spec (section 7.1.7.7), the downstream or upstream device may interpret any non-idle signal as a resume signal from the upstream or downstream device. In the OTG spec, if the dual-role B-device is in B_WAIT_ACON state, or the A-device is in A_SUSPEND state (and the B-device is enabled for HNP), then only a J-to-K transition on the bus will be treated as a bus resume. Note that a J->SE0->K could also be treated as a bus resume, if the SE0 time is less than 2.5 µs.

POWER DOWN AND WAKE-UP
For a battery-powered OTG device, the OTG controller will be put in the power-down mode if the device is not in a session. This significantly reduces power consumption. (Typically, the current draw should be less than 50 µA.) In this mode, both the DC and the HC are suspended. The PLL, oscillator, and charge pump are turned off.

To support an OTG device when it must respond to an OTG event, a slow or Lazy is kept running while the chip is in power-down mode. The Lazy clock runs a very low clock frequency during suspend mode that, together with a very low "suspend" power consumption, allows for easy design of peripherals that comply with ACPI, OnNow, and USB power-management requirements. An OTG event will be detected and wake up the chip (that is, enable the PLL and oscillator). The interrupt can be generated after the clock is up, if the corresponding interrupt is enabled. The OTG controller should also support software wake-up. If no OTG event is detected, but the application running on the OTG device wants to use the USB bus, software can wake up the OTG controller and start a session.

HUB SUPPORT
Dual-role devices can handle hubs. However, standard USB hubs don’t support the signaling methods used for the SRP and HNP. Therefore, when an A-device is directly connected to a standard hub, the A-device is prohibited from issuing a command that would enable the downstream device to expect or initiate HNP. So, when a peripheral is connected downstream of a hub, it can’t become a Host anymore.

OTG TRANSCEIVER
An OTG transceiver is a physical-layer device that interfaces between an OTG controller core and the USB bus. Beyond the standard USB transceiver function, an OTG transceiver provides analog parts for use by SRP/HNP. These include the 5-V charge pump, voltage-level comparators, pull-up/pull-down resistors, and the ID detector. Two classes of OTG transceiver prevail in the market. One is a full-speed OTG transceiver that supports USB low and full speeds. The other transceiver adds Hi-Speed USB support. Two transceiver types exist in the market because Hi-Speed USB consumes more power and requires a larger chip package. Both transceivers have standard interfaces defined by industry consortiums of key USB providers. For applications that don’t require the 480-Mbit/s high-speed data rate, the full-speed OTG transceiver is a more economical choice.

The de facto industry-standard USB OTG transceiver is the ISP1301, the industry’s first USB OTG transceiver that has been designed into the reference platforms of major handset and baseband communications manufacturers. It supports the mini-USB analog car kit standard, as well as a transparent I2C/UART mode on the D+/D- (Fig. 2).

Given the ubiquity of USB in the world today, USB OTG will enjoy the same widespread acceptance and use. In this article, we discussed the requirements for an OTG system that easily integrates onto an ASIC based on different processors and operating systems. The OTG tutorial page can be found at: http://www.semiconductors.philips.com/buses/usb/products/otg/tutorial

Alan Chang is a chief design engineer with Philips Semiconductors. He holds an MS in electrical/electronic engineering from Iowa State University, Ames, Iowa. Chang can be reached at [email protected]

Zhong Wei Wang is a chief applications engineer with Philips Semiconductors. He holds an MSEE from the Shanghai Institute of Metallurgy at the Chinese Academy of Sciences, China. Wang can be reached at [email protected]

Shaun Reemeyer is a senior IC design engineer with Philips Semiconductors. He holds a bachelor of engineering with honors from the University of Tasmania, Australia. Reemeyer can be reached at [email protected]

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish