Since Intel introduced the Peripheral Component Interconnect (PCI) standard in 1992, developers have eagerly adopted and designed products based on this bus peripheral expansion architecture. For instance, products such as video adapters, network interface cards (NICs), and mass storage controllers, now are available for the PCI bus.
The speed of the PCI bus makes it a very attractive—and potentially lucrative—architecture. But with the new capabilities come some problems. Most specifically, how do we test the capabilities of PCI bus cards effectively and efficiently?
Current Test Methods
Today, most manufacturers inspect for process-related defects using manufacturing defects analyzers or in-circuit test equipment, proceed to final assembly, and then conduct a board-level functional test prior to shipping the product. Internally developed hot mock-up test stations, resembling the target host-system with a PCI connector exposed, often are used to perform functional test. These test beds usually are low cost (~$3,000), depending on any additional instrumentation that may be required.
The test software consists of the PCI card’s software driver and any additional diagnostic routines. Many times the software diagnostic routines, written in C, are ported from the design department.
The tester must run the power-on self-test (POST) and boot an operating system that initiates the diagnostic routines. The entire test may take two to three minutes excluding handling times, and may result in a go, no-go diagnostic message.
If an internal device defect, such as a permanently asserted interrupt, causes the tester to hang or lock up, the diagnostic resolution decreases. Also, throughput requirements force some manufacturers to place up to 20 of these hot mock-up stations at the end of a production line.
Consider the following alternative test strategies:
Reduce test times at functional test station.
Advantage: Preserve current investment.
Drawback: Faults detected later in the process.
Perform a portion of the functional tests at in-circuit test (ICT), such as a telecom product that requires extensive compliance testing involving custom instruments but whose basic functions can be tested at ICT.
Advantage: Faults routed to the rework station sooner.
Drawback: Costs to transition tests to ICT may not provide an acceptable return.
Perform full functional tests at ICT (eliminate hot mock-ups).
Advantages: One common test platform, lower support costs, earlier faults discovery, reduced handling time.
Drawback: Might impede line throughput depending on test specifications.
Two of these options recommend adding functional tests to the in-circuit test station. Performing limited-function tests or full functional testing at the in-circuit test station can induce root cause or fault mechanism discovery earlier in the process. This saves rework costs and provides information that can potentially improve the process.
System Requirements for Testing PCI Cards
For PCI cards, the test system must provide:
Access to the PCI-bus interface.
Power resources for the UUT.
Hardware interface logic to emulate the host system (CPU, memory, and PCI bus interface logic).
Software routines to emulate and negotiate responses to PCI bus transactions.
The test system must emulate instructions from the host system. It should include a processor, a local memory, and a PCI bus interface. Together, these blocks send instructions to the UUT and negotiate transactions. When combined with test-system software drivers, the POST and operating boot-up sequence can be removed from the test procedure.
Tests Common to All PCI Devices
Modular test development facilitates code re-use and allows the test engineer to divide the functional test into segments or blocks that, as a whole, test the UUT’s operative circuitry. Each PCI design includes a PCI bus interface and core logic in compliance with the published PCI specification.
The majority of the digital logic and core processing is contained on a single IC for many of today’s consumer products, such as video cards and NICs. Since each PCI device must adhere to this architectural specification, many functions can be tested independently of the product’s end use. Since all PCI devices share a common architecture or basic building-block foundation, let’s examine some of the host-to-device communications that usually are transparent to the user.
PCI cards are designed around a PCI chip set using either 3.3- or 5-V buffer/driver logic. Upon power-up, the PC’s BIOS communicates with the PCI card via low-level PCI transactions. The boot-up sequence generally conducts all device- initialization processes. Typically, the system BIOS invokes the POST global device manager.
The test-system software should provide a low-level layer that interfaces with the PCI device and offers an application programming interface for the test engineer. Consider several operations that the test system performs when directed by the application code.
The host system enumerates the PCI bus by addressing each logical bus address and determining if a PCI device exists. A functional PCI device will acknowledge the host system’s request. Once the presence of the UUT is verified, the test program accesses additional configuration registers and determines operational characteristics, such as memory, I/O, and interrupt requests, required by the device.
The PCI bridge, a functional block within the PCI interface logic, negotiates these requests, allocates the necessary resources, and dynamically maps the PCI device’s I/O and memory functions into the test-system’s memory and address space. The test program may continue by programming the UUT’s memory and I/O address decoders to respond to memory and I/O ranges. Once communications have been established, additional UUT register information can be examined.
Consider developing a routine that accesses registers that must be implemented in every PCI device, denoted with gray shading in Figure 1. Each PCI device contains a header space of 64 double words reserved for configuration information.
Some of these registers must contain information required by the PCI specification. As a result, the test program can inspect each register for device-dependent information. In addition to performing basic configuration cycles, the revision ID register confirms that the correct controller-chip revision level has been placed. Depending on the test system’s design, a variety of configuration cycle reads can be performed in a few hundred milliseconds.
Accessing a PCI device’s configuration port is a three-step process:
Write the bus number, physical device number, function number, and double word number to the configuration address port. The information is available from the device vendor.
Perform an I/O read-from or a write-to the configuration data port.
Validate the transaction and register information within a test subroutine.
There are three types of PCI bus transactions: configuration, memory, and I/O. While the host processor cannot perform configuration cycles directly, the CPU-PCI bridge recognizes certain I/O or memory accesses as configuration accesses (read and write transactions on the PCI bus).
Before a read or write transaction can be accomplished, the test program must provide the PCI bridge several parameters that identify the target’s registers. The PCI device’s register description and data sheets contain a plethora of valuable operational information.
While data sheets and register description documents explain various operative modes and procedures for implementation, it also is important to filter out the information relevant to the test program. This statement prompts a brief digression to the topic of UUT fault coverage.
One of the most important parameters of any test method is the fault coverage or test comprehensiveness. If you intend to develop a common test platform including in-circuit and functional test, outline or list the possible fault opportunities. Collect data about the common faults that have been observed during prototype runs and historical information for similar UUTs assembled using similar processes.
By identifying the logical functions and circuitry that affect the UUT’s operative modes, test modules and routines can be optimized to eliminate excessive subroutines or test overhead. Furthermore, an analysis of the UUT’s operation specifications not only can facilitate the development process, but also minimize the number of bus transactions without compromising fault coverage.
Tests for Specific Applications
Generic test routines initialize and configure PCI devices. In addition, application-specific test modules represent another piece of the program that can be added to meet fault-coverage requirements.
Test engineers can either migrate existing device diagnostic code or develop new routines using data sheets and register descriptions as references. For example, if the UUT is a NIC, add a suite of tests that validates the UUT’s capability to transmit and receive data packets. If the UUT is a video card, various test sequences should verify that the UUT’s DAC can successfully convert digital instructions into an RGB signal. The following example provides an overview of test modules that can be developed for testing NICs.
Testing PCI NICs
NICs negotiate data transfers between the local PC and one or more networked devices. The test-system configuration should include the functional blocks shown in Figure 2. The tests also verify the capability of the NIC to act as a PCI bus master and perform burst-mode transactions. The tests shown in Figure 3 validate the NICs operational capabilities.
Conclusion
As product life cycles continue to shrink for PCI and electronic devices in general, manufacturers must optimize each process step to meet or exceed time-to-market goals. Process and functional testing present two steps that can be improved.
The modular test method presented in this article can be applied to a variety of different test strategies. It can effectively reduce total test time and improve fault visibility within the process.
The suggested test techniques can help implement these strategies in a fast, efficient manner. In-circuit and functional test groups should work with process engineers to develop a test strategy that maximizes throughput and reduces costs based on process and product variables.
References
1. Davis, B., The Economics of Automated Testing, McGraw-Hill, 1982.
2. Shanley, T. and Anderson, D., PCI System Architecture, Third Edition, Addison-Wesley, 1995.
About the Authors
Kyle Klatka is a technical marketing engineer for the Electronic Manufacturing Systems division at GenRad. He has worked for the company for two years and received a B.S.E.E. degree from the Georgia Institute of Technology. (978) 589-7260.
Marc Smith is a staff scientist for GenRad and has 21 years of experience developing functional test equipment. He is one of the original system architects for GenRad’s GENEVA Test System and the author of the company’s concurrent telephony transmission test library. Mr. Smith has a B.S. degree in computer science and B.S. and master’s degrees in electrical engineering from Washington University. (978) 589-7297.
GenRad, EMS Product Development, 7 Technology Park Dr., Westford, MA 01886.
BOARD ATE
Reader Interest
Please indicate your interest in this article.
High Medium Low
Interest Interest Interest
220 221 222
Enumerate PCI bus.
Configure PCI interface.
Validate interrupt circuitry.
Validate control register operation.
Validate contents of Boot ROM.
Internal loopback test.
External loopback test (validates that the UUT can transfer and receive data packets to and from a remote NIC via the RJ-45 connector).
Test UUT’s response to erroneous data packets.
Measure signal parameters such as jitter and return loss.
Figure 3.
Copyright 1998 Nelson Publishing Inc
August 1998