|
Design Features |
The USB for PCs can automatically configure and power peripherals. But, as I learned in this hands-on project, early USB adopters may face a substantial system-level design effort. They also need to carefully examine USB data-bandwidth characteristics.
When EDN's call for hands-on project ideas came in
late 1995, I chose the Universal Serial Bus (USB). At the time, the
specification was still in draft stage as Revision 0.9, and components were only
a promise. Like most of you, I wanted to apply an emerging technology that
looked like the next winner. By catching the bus too soon, however, I was in for
a rough ride.
I chose the USB for its potential. The bus can connect a standard, closed-cover PC to industrial peripherals that now require an add-in card or embedded PC. Connecting the peripheral device automatically configures both the peripheral and the PC and prepares the system to use its newly acquired capability. Further, that connection can supply power to run the peripheral device (see box, "USB fundamentals").
You can use such a self-configuring, self-powered system for numerous applications. For example, you can add a diagnostic monitoring port. You can build a USB data-acquisition peripheral into a system without using system resources. The system under test need not have its own control CPU or power source. Connecting a PC to the USB device powers the device and allows the user to monitor system operation, regardless of the system's status. The ability to perform remote diagnostics over a telephone line, for example, requires only the connection of a modem-enabled PC to the diagnostic port. The need for system-hosted communications capability vanishes.
My hands-on project had two objectives. The first was to build a USB peripheral device. The second was to use the device to "kick the tires" on the bus. In particular, I wanted to evaluate the bus's timing and data-bandwidth characteristics under severe load to learn how adaptable the USB would be to embedded needs.
To
meet these objectives, I planned to create a data-acquisition peripheral. Data
acquisition is a typical embedded application—one that could easily adapt
to the USB. In addition, such a device would give me control over the device's
data rate. That control would allow me to test the bus under various loads
pushing the bus to its upper limit.
Once I had my peripheral, I would be able to measure the system's attained bandwidth and compare it to the theoretical bandwidth. The USB Specification Revision 1.0 (Reference 1) calls for the host to allocate bandwidth for a bulk-transfer device based on the formula:
Bus time (nsec)=9107+83.54
(Floor(3.167+ BitStuffTime(Data_bc)))
+Host_Delay,
where BitStuffTime is the increase in raw bit count due to coding, Data_bc is the number of bits in the data packet, and Host_delay is the time the host needs between successive bus transactions. For a 64-byte data packet, worst-case bit stuffing, and minimum host delay, the formula yields a bus time of 59.4 msec. That time translates to 1.024 Mbytes/sec because the number of bus transactions each millisecond must be an integer.
This formula takes into account worst-case conditions for clock rate, signal delays, and data pattern (see box, "USB bandwidth analysis"). It also includes several host-system-dependent unknowns. I intended to use my peripheral to estimate these unknown values for my system and accurately estimate achievable bandwidth.
The first task, therefore, was to build a USB peripheral. Because the project began only a few months after the specification's final approval, I had few choices for hardware- and software-development tools. Following the project's genesis, more tools and improved versions became available (Table 1), so the choices I made represent availability, not a comment on relative merit.
I began my project by acquiring Intel's evaluation board for its 82930 USB microcontroller. The 82930 microcontroller blends an 80251 core with USB-specific hardware, including FIFO buffers, clock generation, and bit-stuffing and protocol hardware. The evaluation board includes the 82930, clock circuits, USB line drivers, external memory, and a ROM-based reduced-instruction-set monitor (RISM). The board also has parallel and serial ports that I planned to use to connect the board to an ADC module. One serial port links the board to the development system.
The evaluation board is part of a peripheral developer's kit available from Intel. The original kit comprised the evaluation board, a host system, driver software, and sample application software. Unfortunately, no host systems were available for me to borrow, so I had to locate my own USB-ready PC. The sample software was specific to the Intel host system, so I couldn't adapt it to my project.
The first USB host systems to enter production were the IBM PC 300 series PCs. I borrowed a PC 350 from IBM. It has two USB ports on the back panel and BIOS extensions that support the USB. To be completely ready as a USB host, however, the system needed an updated version of Windows 95. The commercially available version would not recognize the USB port or run USB device drivers. I obtained from Microsoft a beta version of the latest Windows 95 OEM release for my system, along with some USB loop-back test drivers.
To turn the evaluation board into a peripheral device, I
would have to program the 82930. For that task, I needed software-development
tools. The evaluation board came with demonstration tools from Keil Software,
Production Languages Corp (PLC), and Tasking. I chose the Tasking software for
its debugger and because its crippled-for-demo state was sufficient to meet my
anticipated development needs.
I also needed tools for developing device drivers and application software under Windows 95. This requirement, in turn, re-quired that I obtain a copy of the Windows NT Driver Developer's Kit from Microsoft. I was able to obtain several sample drivers but could not get what I needed to run Windows NT and develop the custom drivers that my project would require.
At this point, I had to re-evaluate my approach to the project. Given my limited resources and a six-week deadline, I faced an impossible development effort. The pieces of this puzzle were all too new and had raw edges. These pieces weren't going to go together very well, and I had few tools at my disposal that would let me trim the pieces to fit. And, I was missing a few pieces.
Figure 1
helps illustrate the effort I faced. Of the six major blocks
in a USB implementation, I had only two: the USB interface and the host
controller. I also had only part of the software I needed to turn the evaluation
board into a USB logical device. I had expected to program the evaluation board
to provide the function but thought the logical device, system software, and
client software would be available in a form I could use or adapt. They weren't.
I also couldn't create my own system software or client software without
Windows NT. I would have to adapt my evaluation peripheral to match the drivers
already in hand.
Early adopters of USB can expect to face similar problems, especially the need to create client software and device drivers for Windows 95. Few examples are currently available, although the situation continues to improve. One looming improvement is the pending release of device-class specifications.
Device classes allow standard software to handle common peripherals. The standard-class device drivers work for all devices within the class. Device classes for human-input devices, such as a keyboard, a mouse, or a joystick; monitors; and audio devices are under development. These classes and the associated software were still under definition during my project, however, and were unavailable to me. Once device-class specifications exist, off-the-shelf drivers and client software should quickly become available. Still, designs that fall outside device classes are on their own for software.
I decided to work with the software I had, rather than try to develop everything I needed from scratch. I would have to design the peripheral to work with the loop-back-test software Microsoft had given me. That problem settled, I was finally able to get to work, with four weeks left in the project schedule. The first step was to set up the host system. This step was also the first stumbling block.
I unpacked my borrowed computer and turned it on but was faced with a dead monitor. The monitor's power-saving circuitry was holding the device in a standby state. By swapping monitors and PCs, I was able to determine that the monitor was OK, but there seemed to be no video coming from the USB host PC. Reinserting and wiggling cables had no effect. A call to IBM's technical-marketing-support group revealed that the system I had received had an SVGA card installed, which disabled the motherboard's built-in graphics port. I had connected the cable to the motherboard port in accordance with the instructions, but it was the wrong port.
Now that the monitor was active, I had another problem. The system wouldn't boot. Apparently, Windows 95 automatically executes a disk scan on boot-up if the previous session didn't exit properly. While trying to find the monitor problem, I had turned power to the computer on and off several times. One of those times must have been during a disk access, and I corrupted the boot record. Now, I had to reconstruct my system files.
Reconstruction proved a significant challenge. My software came preloaded, and I had no start-up disk. Windows 95 includes DOS as a subprogram, rather than as its foundation. I replaced the DOS boot record with a copy from my other computer, but Windows 95 doesn't run when called by an earlier DOS version. The CD-ROM version of Windows 95 I had was useless to me because the IBM PC 350 had no DOS drivers for the CD; it ran under Windows 95. I finally found—after a painstaking file-by-file examination of the hard drive under my earlier version of DOS—some compressed installation-disk copies of Windows. Executing those files restored my system.
With my host system back in operation and the evaluation board hooked in, I was ready to try out the development tools. A simple routine would do, so I wrote an assembly-language loop that activated LEDs connected to the 82930's output port 1. After several attempts to load the program into the evaluation board, however, I realized that the demo software was invoking not the debugger, but a simulator. Calls to the Tasking help line finally revealed that the demo version I had would not work with the RISM version on my evaluation board.
My contacts at Intel, who were providing guidance and answers on my project, were accustomed to the Compass/251 software from PLC and couldn't answer questions about the Tasking tools. To be consistent with my mentors, I secured a loaner copy of the full development tool from PLC, making sure that the version (Revision 3.03) the company sent me would work with the Revision 0.2 RISM I had on the evaluation board. This tool allowed me to load a program of my own creation into the board, and I used that program for the remainder of the project.
Finally, something was happening with my project hardware. My program illuminated the LEDs on the board in sequence. Of course, at 12 MHz, the result was a blur. The Compass/251 debugger allows a self-timed single-step mode, however, so I could slow the blinking LEDs and verify the pattern. Two weeks' design effort just to get blinking lights. Thrilling.
The next step was to assemble the enumeration code that Intel provided. This code allows the evaluation board to respond to the USB host's setup commands and receive an address assignment. It was the only piece of logical-device software I had in hand. Again, I ran into version problems.
There are two versions of the evaluation board: one that uses an 82930A and one that uses an AX. There are, therefore, two versions of the enumeration code. I originally received code for the AX because it was the device currently in production and the A device was being discontinued. As Murphy's law would have it, my board had the 82930A.
With the correct version of code in hand, I made my first pass at assembling the program. The 87 errors that the assembler reported seemed a bit excessive for code already tested, so I began to look for some other problem. It turned out that the tool used a syntax for the INCLUDE command different from the one the program used, so the tool never used the file containing the register definitions. Correcting the syntax mismatch reduced the error count to two, both due to case mismatches between the definition of a label and its subsequent use. By turning off the assembler's case checker, I could generate code without errors.
One of the factors that caused me delay and frustration in resolving these problems was a lack of documentation. The demo versions of the tools and the loaned version of Compass/251 came without printed documentation. The tools had online help files, but they didn't provide all the information I needed, such as the proper syntax for commands. Further, the on-screen help windows covered too much of the work screen, forcing me to page between windows so I could do what the help file recommended. I'd rather have had a book.
Once I was able to load the enumeration code onto the
development board, I was ready to plug my USB peripheral into the host.
Connecting the two caused a reaction in the host. The hourglass came up briefly,
indicating that the host recognized insertion of a USB device. A subsequent
check of the device manager revealed no new devices, however, suggesting that
the host failed to recognize my evaluation board. A careful check of device-ID
codes in both the board and host files showed no mismatch. It should have
worked.
It was time to bring out the debugging tools. I installed
the USB Detective, a bus-monitoring tool from Computer Access Technology Corp
(CATC), into the development system and began to trace the bus transactions.
Figure 2 shows the trace information I acquired. The host system began the
initialization sequence but stopped before it completed. A call to Microsoft
revealed that I had a host-driver version that strictly enforced the USB
response-timing specification. My evaluation board was too slow in responding
to the host's initialization sequence, so the host registered a "no-show"
and did not complete the sequence.
Microsoft admitted that this strict enforcement had created problems for developers just starting to debug their designs. Like me, the developers got stopped in their tracks by the timing error and couldn't get anywhere in the debugging process. Microsoft put a work-around into the next beta version, allowing the developer to turn off the timing check. The company promised to send me a copy of the revised software so that I could proceed but didn't send it soon enough.
My deadline for completing the project had already arrived. So far, I had been able to make only a few useful measurements. I was able to determine that transactions initiated by the host system began five to seven bit-periods following the start-of-frame (SOF) token. Data transactions from the host began three bit-periods following an OUT token. Acknowledgments from the host occurred eight bit-periods following the data from the target. Data from the target began four bit-periods after an IN token. Acknowledgments from the target began three to four bit-periods from the data packet. (See box, "USB bandwidth analysis," for a "typical" delay using these measurements.)
I was unable to make any measurements for the variable Host_delay. This variable accounts for the time it takes the host to initiate a new transaction after finishing one. Because my system never finished its enumeration sequence, I could not generate back-to-back data transactions. That measurement will have to wait for updated software.
As limited as the experiment was, there are several important
conclusions to reach from this project. The first is a critical need for
designers to obtain substantial software support for their design efforts. If
acquiring a USB microcontroller, make sure that you have representative
software for basic USB functions, such as bus enumeration. Make sure that you
have sample device drivers that you can modify to customize for your
application. And, make sure that your host system comes with USB-ready host
software. If the vendors don't supply you with sample software, you face a major
effort creating support software before you can even start your device design.
You should not face quite the same difficulty in obtaining software that I did, however. My project suffered from a case of monumental mistiming. I obtained my evaluation board after Intel had run out of host controllers and before the company had software available for off-the-shelf hosts, such as my PC 350. The board I received used parts that were subsequently discontinued. And, I obtained my software just before the revision that would have solved my problem. Welcome to the leading edge of technology.
Although many of the problems I faced will have been solved by the time this reaches print, you still need to carefully track software and hardware changes. More than 300 companies are actively working with the USB, continually refining both their products and the core software. The technology, therefore, will remain in a state of flux, probably for another year. You need to keep your eye on your supplier's Web sites for updated information and constantly check that you have the most recent versions of everything. Membership in the USB Implementer's Forum can help keep you abreast of new developments.
A final note: EDN's production cycle dictates that I write this article seven weeks before publication. The "Leading Edge" section, however, is written only three weeks before publication. I will continue to work on this project and report late results. Look at the "Leading Edge" section of this issue, (pg 14) for my further adventures with the USB and an update on products and standards.
USB fundamentals |
| The developers of the Universal Serial Bus (USB)
specification had two objectives. One was to collect all of a PC's I/O ports
into one interface, providing live-insertion and automatic configuration. The
other was to provide sufficient bandwidth to handle telephony applications
along with typical peripherals. The design they settled on is a four-wire,
half-duplex serial bus running at either 1.5 Mbps (low speed) or 12 Mbps (full
speed).
From the outside, the USB appears simple. Plugging a peripheral device into the bus causes the PC to automatically respond. The operating system recognizes the device, loads the appropriate drivers, and configures the device for operation. The PC can distinguish between identical devices on the bus because the bus's physical configuration ensures a unique, identifiable connection path between device and host. The USB's physical configuration has a
tiered-star topology (Figure A A connection between a device and hub uses a four-wire, jacketed cable. Two wires form a twisted pair for data communications, the other two supply power and ground for hubs and devices without their own power source. Data flow in the cables may be downstream (hub to device) or upstream (device to hub). Power can flow only downstream and is limited to 500 mA at 5V. Cables intended for full-speed data include a shield; low-speed cables need not be shielded. USB cable connectors come in two types (Figure B Simple operation, complex behaviorAlthough the USB appears simple overall, its internal workings are complex. You need to carefully examine those workings if you intend to use the bus as a pathway into your PC. In particular, you need to understand how the USB operates logically and the nature of its data transfers so you can evaluate its adaptability to your intended use. Even though the USB's physical architecture has a tiered-star topology, its logical connection is point-to-point. The host system establishes independent communications channels, or pipes, between application software and individual control or data ports on peripheral devices. Channels can carry data (stream) or control/status (message) information. Pipes have several attributes, including bandwidth allocation, packet size, information type (stream or message), and direction of stream data flow. The host establishes these pipes by assigning a unique 7-bit address to each device on the bus, a process called "enumeration." Enumeration occurs on power-up and whenever a device attaches to the bus. During enumeration, the device reports its configuration to the host, identifying the device's accessible data and control pathways. Each pathway has its own 4-bit subaddress, called an "endpoint." The address and endpoint definitions allow the host to determine the correspondence between application-software functions and device pathways and create the necessary pipes. An application program, thus, has a direct logical connection to a device's data channels or control registers. Having multiple pipes on a single half-duplex bus requires some form of multiplexing. The USB uses time-domain multiplexing under control of the host system, working with 1-msec frames as the basic time segment. The host initiates all bus transfers, giving it control over the allocation of time within frames to each pipe. The allocation is not static, however, but varies from frame to frame. Specific allocation depends on the type of information transfer the pipe must provide and whether the application software has requested a transfer. The USB specification recognizes four transfer types: isochronous-data, bulk-data, control, and interrupt. Isochronous-data transfers typically carry time-critical information, such as audio, so the host must allocate time in each frame for an isochronous stream pipe. Interrupt transfers receive time slots every nth frame. All other transfers receive time on an as-available basis. To ensure that all transfer types have access to the bus, the USB specification limits the time that the host can allocate to transfers. Isochronous-data and interrupt transfers together can occupy no more than 90% of available bus time. Control transfers have the next priority, with bulk-data transfers receiving any remaining time. The host is responsible for resolving contention among control-transfer requests and among bulk-data-transfer requests for the time available. The host reserves bus bandwidth for isochronous and interrupt transfers during device enumeration. If a transfer needs more bandwidth than is available, however, the host does not finish that device's enumeration. This inaction effectively denies the device access to the bus. Reservation of bandwidth does not allocate bus time but merely tracks anticipated demand. The host system allocates time within a frame only if the application software has requested time. An audio CD device, for example, may have 50 kbytes/sec reserved on the USB, but the host doesn't allocate time if the CD is not playing. Any reserved, but unused, bus time becomes available for bulk-data transfers. The mix of transfer types offers design trade-offs among data rate, latency, and data integrity. Isochronous data transfers have a guaranteed data rate and bounded latency. They receive time every frame, although a given transfer's position within the frame may vary. The drawback to isochronous transfer is that the data is not guaranteed. If data loss or error occurs, the USB does not resend isochronous data. Isochronous transfers can have data packets as long as 1023 bytes and must always run at full speed. Interrupt transfers also have a guaranteed data rate and bounded latency but may run at full or low speed. Every n frames, the host queries a device through its interrupt-stream pipe. If the device has interrupt information, it returns a single data packet as long as 64 bytes. If an error occurs in transmission, the device resends the information at the next query. Bulk data and control transfers have no guarantees on their data rate, although control transfers have the first claim to 10% of the bus bandwidth. Errors in bulk data and control transfers prompt a retry. If several transfer requests are pending for the same pipe, the retry occurs before the pending transfers. Bulk- and control-data packets can be as long as 64 bytes and may run at full or low speed. Understanding these trade-offs and the underlying logic of the USB's operation should allow you to estimate how well the bus can meet its intended application's interface needs. For more detailed design work, you need a copy of the specification. It is available for $35 from the USB Implementer's Forum, JF2-51, 2111 NE 25th Ave, Hillsboro, OR, 97124. You can also download it free from the USB home page, http://www.teleport.com/~usb. |
Table 1—USB | |||
| Product type | Company | Product | Comments |
| BIOS | AMI Award Software Phoenix Technologies |
AMIBIOS 95+ PhoenixBios 4 |
|
| Connectors | Amp Methode Electronics Newnex Technology Northstar Systems Siemens |
Molded cable assemblies | |
| Devices | Advanced Gravis Alps Electric Cherry Key Tronic Logitech Mitel Philips Consumer Electronics USAR Systems |
Gamepad Keyboard, gamepad Keyboard Keyboard Joystick Telephone Monitor Speakers USBAdapt |
Hub/monitor Digital audio speakers PS2/USB keyboard adapter |
| Host PCs | Compaq IBM Sony Ziatech |
PC300 series PCV70, PCV90 ZT5510 |
Compact PCI CPU board |
| ICs | Atmel CAE Technology CMD Intel Mitsubishi NEC Philips Semiconductor Texas Instruments Virtual Chips |
AT43311 AT43351 ASIC 430HX/VX 82930AX 37960 PCIUSB11 TUSB2070 TUSB2040 USB functions |
Five-port USB hub controller Low-speed USB device microcontroller USB synthesizable core USB-PCI host ASIC PCI/USB host controller USB microcontoller MPU core, evaluation board USB host core USB line drivers Seven-port USB hub device Four-port USB hub device Synthesizable cores, test simulator |
| Tools | CATC Digital System Associates FuturePlus Hewlett-Packard Intel PLC Tasking |
USB Detective USB Traffic Generator DSA-2001 USB Preprocessor 16500B Apbuilder Keil Software Compass/251 MCS 251 Toolset |
Bus analyzer Traffic simulator Bus analyzer Bus analyzer, works with HP logic analyzers Logic analyzer Device-configuration tool Software development Software development Software development |
| Training | Annabooks SystemSoft |
Books, seminars Software consulting/training | |
USB bandwidth analysis |
| The Universal Serial Bus (USB)
offers a raw data rate of 12 Mbps, suitable for low- to medium-speed data
transfers. At first glance, that data rate suggests a data bandwidth
approaching 1.5 Mbytes/sec. However, protocol overhead and system delays steal a
significant fraction of that rate. To find the achievable data bandwidth, you
need to consider many factors.
The analysis of USB bandwidth must begin with the frame rate. The USB specification calls for the host to segment data transfers into 1-msec frames, nominally containing 1500 bytes (12 kbits). However, the specification allows the host controller to adjust the frame's bit count to synchronize the frame rate to an external clock. Adjustments as great as ±16 bits (2 bytes) are permissible. Each USB frame begins with a start-of-frame (SOF) marker. That marker, together with system delays that give bus devices time to react, occupies approximately 6 bytes of the frame. USB frames also have an end-of-frame (EOF) period during which no bus transactions may occur. The EOF period allows the system to detect and shut down failed peripheral devices that are babbling, or transmitting without permission. The EOF period occupies approximately six byte-times. Together, the SOF, EOF, and frame adjustments take up 14 bytes. The remaining 1486 bytes in the frame are available for bus transactions. Figure
A The host's request for data comes as an IN token. The token consists of an 8-bit synchronization field (sync), an 8-bit packet identification (PID) field, an 11-bit address field, and a 5-bit CRC character. In addition, the token has an end-of-packet (EOP) signal two bit-periods in length. The IN token's total duration is at least 34 bit-periods. Bit-stuffing can increase that duration. Bit-stuffing adds overheadBit-stuffing occurs as a result of data encoding. The USB signal uses an NRZ invert (NRZI) coding scheme, which allows the signal to carry both data and clock information. NRZI coding calls for the output signal to change state each bit-period if the data bit is zero. If the data is a one, the signal remains steady. The state-change transitions at each zero bit allow a PLL to recover the bit clock. A long sequence of ones, however, generates no transitions, and the clock-recovery scheme fails. To ensure an adequate number of transitions, the USB protocol calls for the data transmitter to insert a zero bit after six consecutive ones. This inserted, or stuffed, bit serves only to provide a state transition. The receiver automatically removes stuffed bits from the data stream. The sync's bit pattern and the PID fields have
enough zeros that, by themselves, they never need bit-stuffing. The last 3 bits
of the PID can be ones, however, and may combine with subsequent fields to
require a stuffed bit. Address, data, and CRC fields all have the potential for
containing a long sequence of ones, so are subject to bit-stuffing overhead.
Figure B Following the IN token, the bus goes idle for a time. Two factors set this first idle period: the time it takes the peripheral device to turn from receiver to transmitter and the round-trip propagation delay for the host's EOP signal to reach the device and the response to return. The USB specification calls for the minimum device turn- around time to be two bit-periods, allowing the bus to settle following the token. The maximum allowable round-trip propagation delay, including turnaround time, is 16 bit-periods. Thus, the first idle period is two to 16 bit-periods long. Upon receipt of the IN token, the peripheral device sends its data packet. The packet consists of sync and PID fields followed by a number of data bytes, a 16-bit CRC field, and the EOP signal. The USB specification allows nonisochronous data packets to be 8, 16, 32, or 64 bytes long, as set during device enumeration. Three bits of the PID, the CRC character, and the data bytes are all subject to bit-stuffing. The USB again goes idle as the host turns its interface around from receiver to transmitter. The turnaround period is at least two bit-periods long and must be no longer than 71/2 bit-periods. The host then transmits an acknowledgment token that consists of a sync field, a PID field, and an EOP signal. Transmission of the acknowledgment token concludes the transaction, but the host system must delay at least two bit-periods before initiating another transaction. In practice, this delay can be longer. The host controller may need to access system memory, for example, to retrieve data for the next transaction. This host delay following a transaction is implementation-dependent. Achieved bandwidth a random variableAdding all the bit-periods and delays gives the time required for one transaction. Unfortunately, that time is variable. Some variations, such as propagation delay and bus turnaround time, are a function of the specific implementation and remain constant for a given system. The time lost to bit-stuffing, however, depends on data patterns and varies frame to frame. A statistical estimate of random data suggests that bit-stuffing typically occurs with 0.8% of the data. A worst-case data pattern, however, results in bit-stuffing one-sixth (16.67%) of the time. An estimate of achievable data bandwidth, therefore, must necessarily be a range. Table A shows the achievable data bandwidth for a sequence of bulk transactions using various packet lengths and a worst-case clock frequency. The entries account for typical and maximum bit-stuffing, minimum host delay, and the combined idle periods. The three idle-period values represent minimum and maximum turnaround and propagation delays and the typical delay values I measured in my hands-on system. Although Table A provides a reasonable range estimate, it fails to account for the host-system delay. I was unable to measure this delay for my system, so I examined the bus bandwidth's sensitivity to delay. Figure B shows achievable bandwidth for bulk data transfers as a function of total system delay or both idle periods and host-system delay combined. The pattern is a staircase because the data-packet size quantizes the bandwidth. Frames cannot have fractional packets. As expected, the use of smaller packets aggravates the effect of delay. The smaller packets allow more transactions in each frame, each having its associated delay. Thus, more total frame time is spent in system delays than with large packets. This analysis covers only one transaction type, the full-speed, nonisochronous, peripheral-to-host bulk transfer. USB also allows bulk transfers from host to peripheral, isochronous transfers in each direction, interrupt transfers, and control transfers. In addition, there are control, interrupt, and bulk transfers at a low data rate of 1.5 Mbps. Each transfer type has its own protocol overhead and timing characteristics, but the method of analysis remains essentially the same. |
Table A—Achievable USB bandwidth (kbytes/sec) | ||||||
| Minimum delay | Typical delay | Maximum delay | ||||
Packet size |
Typical bit- stuff |
Maximum bit- stuff |
Typical bit- stuff |
Maximum bit- stuff |
Typical bit- stuff |
Maximum bit- stuff |
| 8 | 608 | 544 | 584 | 528 | 536 | 488 |
| 16 | 848 | 768 | 832 | 736 | 784 | 704 |
| 32 | 1056 | 928 | 1056 | 928 | 1024 | 896 |
| 64 | 1216 | 1088 | 1216 | 1024 | 1152 | 1024 |
Manufacturers of USB products | |||
| For free information on USB tools and products such as those described in this article, circle the appropriate numbers on the postage-paid Information Retrieval Service card or use EDN's Express Request service. When you contact any of the following manufacturers directly, please let them know you read about their products in EDN. Note: All Web addresses start with http:// unless otherwise noted. | |||
| Advanced Gravis Computer
Technology Ltd Burnaby, BC, Canada (604) 431-5020 |
Computer Access Technology Corp (CATC) Santa Clara, CA (408) 727-6600 www.catc.com |
Mitel Corp Kanata, ON, Canada (613) 592-2122 www.mitel.com |
Sand Microelectronics Santa Clara, CA (408) 235-8600 www.sandmicro.com |
| Alps Electric San Jose, CA (408) 432-6000 www.alps.com |
Digital Systems Associates Santa Ana, CA (714) 838-2495 |
Mitsubishi Electronics America Electronic Device Group Sunnyvale, CA (408) 730-5900 |
Sony Corp Park Ridge, NJ (201) 930-1000 |
| American Megatrends Inc (AMI) Norcross, GA (770) 263-8181 |
FuturePlus Systems Corp Colorado Springs, CO (719) 380-7321 www.futureplus.com |
NEC Electronics Mountain View, CA (800) 366-9782 |
SystemSoft Natick, MA (508) 651-0088 www.systemsoft.com |
| Amp Inc Harrisburg, PA (800) 522-6752 |
Hewlett-Packard Colorado Springs, CO (719) 590-1900 |
Newnex Technology Corp Sunnyvale, CA (408) 749-1480 |
Tasking Dedham, MA (617) 320-9400 |
| Annabooks San Diego, CA (619) 673-0870 |
IBM Corp Somers, NY (800) 426-3333 |
Northstar Systems Inc Rancho Cucamonga, CA (909) 483-9900 |
Texas Instruments Denver, CO (800) 477-8924, ext 5504 |
| Atmel Corp San Jose, CA (408) 487-2605 |
Intel Corp Chandler, AZ (602) 554-8080 www.intel.com |
Philips Consumer Electronics Co Knoxville, TN (432) 521-3260 |
USAR Systems New York, NY (212) 226-2042 www.usar.com |
| Award Software International Mountain View, CA (415) 968-4433 |
Keil Software Inc Dallas, TX (214) 735-8052 |
Philips Electronics North America
Co Palo Alto, CA (415) 846-4300 |
USB Implementer's Forum Hillsboro, OR (503) 264-0590 www.teleport.com/~usb |
| CAE Technology San Jose, CA (408) 526-9207 |
Key Tronic Corp Spokane, WA (509) 928-8000 |
Phillips Semiconductors Sunnyvale, CA (408) 991-2000 |
Virtual Chips Inc San Jose, CA (408) 452-1600 www.vchips.com |
| Cherry Electrical Products Waukegan, IL (708) 662-9200 |
Logitech Inc Fremont, CA (510) 795-8500 |
Phoenix Technologies Ltd Santa Clara, CA (408) 654-9000 www.ptltd.com |
Ziatech Corp San Luis Obispo, CA (805) 541-0488 www.ziatech.com |
| CMD Technology Inc Irvine, CA (714) 454-0800 |
Methode Electronics Inc Rolling Meadows, IL (847) 392-3500 |
Production Languages Corp (PLC) Weatherford, TX (817) 599-8363 www.plcorp.com |
|
| Compaq Computer Corp Houston, TX (713) 514-0484 www.compaq.com |
Microsoft Corp Redmond, WA (206) 882-8080 |
Siemens Corp Iselin, NJ (908) 321-3100 |
|
A project of this type can never be the work of one individual. I received frequent help from Mike Glass and Brad Carpenter of Microsoft and Troy Hathaway of Intel. The equipment and software I used came from CATC, IBM, Intel, ioTech (Cleveland), Microsoft, PLC, and Tasking. Special thanks go to the USB Implementer's Forum and to Susan Shaw of Compass Communications (San Jose, CA). Without all this help, the project would not have happened.
 |
Technical Editor Richard A. Quinnell can be reached at (719) 530-0560; fax (719) 530-0560. |
| EDN Access | feedback | subscribe to EDN! | Table of Contents |
