Headlines concentrate on the most exciting and impressive aspects of a story—for example, “AMD Beats Intel to 1-GHz Microprocessor Milestone.” The message is factual, even if the victory was only by a matter of hours. However, the impression may be that 1-GHz PCs now are readily available. You may not realize the distinction between microprocessor clock rate and PC performance. Also, you probably haven’t tried to buy a large quantity of these very limited-production devices from either company.
Although achieving a 1-GHz microprocessor clock rate is laudable, system architecture is at least as important in determining a PC’s ultimate speed. Modern PCs use two or more separate buses, as well as a memory bus, to ensure that the microprocessor itself isn’t slowed down unnecessarily by data transfers and interaction with peripheral devices.
Additional functionality is provided by expansion buses. A so-called local bus handles high-speed devices such as video or graphics boards and 100Base-T Ethernet network adapters. This usually is the peripheral component interface (PCI) bus. For less demanding legacy applications, some PCs also provide an industry standard architecture (ISA) compatibility bus.
Traditionally, PCs have used a parallel port or serial RS-232 bus to interface to external devices. Of course, the expansion bus that links a PC to external peripherals may not be used at all in a particular application, or it may be heavily used. As a result, a compromise must be made among speed, the number of devices that can be supported, cost, and complexity. Today, the universal serial bus (USB) has replaced many older, low-speed buses.
Similarly, high-speed external devices such as disk drives have required special treatment in the past. The small computer system interface (SCSI) bus was developed to address this kind of fast, streaming application. Today, Apple Computer’s FireWire bus (IEEE 1394) and the second-generation USB.2 bus provide data transfer capabilities similar to SCSI, but at lower power and cost.
So, even if all PC manufacturers agreed to use the same bus protocols and hardware, there still would be several different types of buses to choose from. Of course, rather than agreeing, manufacturers compete with upgrades to existing buses and development of new technology to address ever higher-speed peripherals. The result is bus proliferation and the attendant problems it poses for design and test engineers.
Bus Development
Historically, a PC’s expansion bus simply was an extension of the microprocessor’s bus with suitable buffering. As microprocessor clock rates increased, more sophisticated buses were required. The original PC-XT bus always required an address where the following data was to be stored. Consequently, each transfer of a byte took two clock cycles.
Modern buses use forms of bursting to transfer contiguous blocks of data following only one write address. For large blocks, the transfer speed approaches the maximum speed the bus can support.
Originally, the expansion bus was controlled entirely by the microprocessor. Today, bus arbitration and bus mastering are used to assign control to any capable peripheral device. In addition, expansion device installation has become automatic in so-called plug-and-play systems. By an interrogation and negotiation process, the microprocessor determines how best to arrange the attached peripheral devices within the available memory space.
And, as microprocessor clock rates have increased, bus signal integrity and power have become more important. Because bus wiring must be treated as transmission lines at high speed, SCSI bus lines, for example, must be resistively terminated. The PCI bus reduces power by adopting a deliberate reflection means of operation. Drive signals are half amplitude, but reflections from the unterminated ends of the lines increase the signals to full amplitude.
For future computer systems, RapidIO and InfiniBand have been proposed as generic replacements for PCI and SCSI, respectively. These new interconnect architectures are scalable, switched fabric systems with very high data rates. Access is through network adapters, which provide the required packetizing/depacketizing function.
Signal levels also have been reduced from the traditional +5-V level. Many devices now run on 3.3 V and some as little as 1.5 V. The low-voltage differential signaling (LVDS) standard achieves robust data transfer at low levels, typically 300 mV, and at speeds greater than 1 Gb/s. Differential operation avoids ground noise and common-mode interference, enabling low power and high speed to be available simultaneously.
Test Implications
The effects resulting from changes to bus protocol, signal level, and speed are many. One way to appreciate the magnitude of the changes that have occurred is to compare today’s InfiniBand specifications against those of an earlier technology, for example, the 1992 Intel front-side bus.
According to Gregg Buzard, the program manager for R&D solutions at Agilent Technologies, “We have seen a 20 times reduction in the data valid window (5 ns to 250 ps) and a 25 times reduction in the voltage swing (5 V to 200 mV). This is a delta of 500. Another way to express it is to say that today’s buses use 0.2% of the energy of the 1992 Pentium front-side bus.
“Buses and interconnects now must be validated and characterized with eye diagrams vs. individual setup-and-hold measurements,” he said. “Jitter measurements and characterization have become critical.”
On a similar theme, Dale Smith, president of Data Transit, listed five requirements for analyzing modern high-speed serial bus transfers:
- Tapping into the signal without affecting signal integrity—To avoid affecting the signal, an engineer must have significant skills in impedance matching, crosstalk minimization, elimination of stubs that would cause reflections, separation of digital and analog circuits, and jitter reduction and its effect on timing tolerances.
- Synchronizing to a data packet—Special sync characters in the serial stream must be recognized at the full bus speed, up to 1 Gb/s or more. Typically, a bus analyzer will use a special chip called a PHY, short for physical, which provides the synchronization.
- Converting the serial data to parallel—Protocol analyzers and logic analyzers store data in parallel bytes, so serial data first must be converted before it can be stored by these instruments.
- Providing a transfer count—Because different types of buses operate in bytes, words, or quadlets, an analyzer must keep track of which byte in the packet is being decoded. This is more important at the beginning of a packet where the command and control bytes are and less important at the end of a long packet, which simply contains data.
- Providing error recognition—Both triggering and bit-error-rate testing (BERT) require error recognition. The output from the PHY is processed and checked for low-level and high-level errors. Low-level errors include invalid characters, bad cyclic redundancy check (CRC), error correcting code (ECC), and disparity errors. Typical high-level errors are caused by protocol, retry, or busy problems.
Because buses have become so complex as well as fast, they no longer can be analyzed effectively with general-purpose test instruments. As an example, consider that the PCI bus multiplexes address and data into a common 32- or 64-bit bus. In a similar way, the bus COMMAND signals are multiplexed with the data byte enables.
Saving pins on chips and connectors in this way saves money, but makes it more difficult to analyze the bus using a conventional logic analyzer. All information about a particular bus transfer is not contained in a single sample. To overcome this problem, some bus analyzers demultiplex the bus into as many as 128 channels so the entire transfer can be treated as a single event.
To help you cope with complex bus operation, bus analyzers may offer several acquisition and display modes. For example, VMETRO’s PCI bus analyzers provide four distinct sampling modes to support analysis at different levels of abstraction:
- Clock—Stores one sample per each clock cycle. This captures all the details of how the PCI bus is exercised, clock cycle-by-clock cycle. This mode is suitable for hardware analysis such as verification of field programmable gate array (FPGA) designs and ASICs.
- Transfer—Stores one sample per valid data phase. Each sample includes the address and command, which are latched during the address phase. This is the optimum way to analyze bus transactions from a software point of view.
- Transaction—Stores one sample per valid data phase. This mode is similar to the transfer mode, but it displays the total burst length for each transaction. This produces a trace that is useful for system behavior analysis, validation, and performance tuning.
- High-speed timing—Sample at bus speeds up to 500 MHz, with a free-running clock that is asynchronous to the bus clock, for detailed hardware analysis of bus timing.1
Of course, all these considerations and modes of operation only deal with hardware requirements. According to Joe Mendolia, vice president of sales and marketing at Computer Access Technology Corporation (CATC), “Bus analysis solutions fall into two broad classes: either they are a dedicated solution for a specific type of bus or an add-on pod to interface with an existing set of logic analyzers. The dedicated solutions provide additional functionality that can be tailored to incorporate features specific to the bus under analysis, such as providing device class decoding for USB or a tree display of the FireWire network.
“The pod approach allows use of existing logic analyzers for new analysis areas,” he continued. “However, users are limited by the capabilities of the analyzer. The information tends to be geared more toward the hardware analysis side than being able to see the details of the packets within the protocol.”
At least one exception to this generalized hardware/protocol viewpoint is the Model FS2104 PCI-X Analyzer from FuturePlus Systems. Bill Furch, the company’s vice president of marketing, said, “We are introducing an analysis probe that monitors more than 50 different protocol errors on the PCI-X bus. This tool can help you follow a problem from one domain to another.
“For example, you may have an analog problem, but you can’t figure out how to trigger a scope on it. However, you can see a protocol violation that you suspect is the manifestation of the analog problem,” he explained. “You simply trigger your logic analyzer on the protocol violation, then have the logic analyzer trigger the scope. You now know your scope is triggered, so you probe around until you see the likely cause of the error.”
Whatever the cause of a problem, engineers want their test tools to find it quickly. And, they want their tools to be easy to use without having to learn all the arcane commands required by older, low-level analyzers.
Retaining the meaning of data within the context of the application is considered in a technical paper by Dr. Michael Vonbank, chief technologist at 3A International. Although his comments are specifically about 1394 systems, his conclusions apply to bus analyzers in general.
“More and more companies are using standardized protocols for the communications between 1394 devices. IEC 61883, an audio, video, and control protocol (AV/C); the serial bus protocol (SBP-2) that can encapsulate any command set; Internet protocol (IP); direct print protocol (DPP); and the instrumentation and industrial control protocol (IICP) are a few of the most commonly used ones. For example, the AV/C specification together with subunit standards is an excellent framework for seamless interoperabil-ity of consumer devices such as VCRs, DVD, and cameras.
“All these different protocols have one thing in common: protocol commands or data are encapsulated in an asynchronous or isochronous packet data payload. State-of-the-art 1394 data analyzers must have at least minimal decoding support for these protocols, that is, extracting and interpreting the 1394 transaction payload accordingly. And a tremendous timesaver for developers is the capability of such instruments to extend the protocol support to trigger and data generation functionality. For instance, it is much easier to set up a trigger condition for a VCR Play command rather than to define a two-quadlets-long data pattern representing the command on the 1394 level.”2
References
- Nygaard, T., PCI-X and PCI Analyzers Improve Productivity in System Development, VMETRO asa, May 2000.
- Vonbank, Dr. M., The Evolution of IEEE 1394 Test and Measurement Instruments, 3A International, 1999. Additional Reading Rosch, W., Hardware Bible, viking.delmar.edu/courses/Cis312J/EBOOK
/wrh07.htm.
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2000 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
September 2000