Properly designed off-the-shelf production test software for WiMAX and WLAN applications must provide the measurement flexibility to handle a range of devices.
Manufacturing test requirements for Wi- MAX and wirelesslocal- area-net-work (WLAN) devices must be comprehensive yet flexible. Traditional test solutions consist of three independent elements: chipset control software from the integrated-circuit (IC) vendor, test equipment, and the test software (or test executive), which allows the execution of an automated test plan. To save test engineers time and effort, test equipment vendors have combined these three elements and are marketing complete, carefully architected software releases that are flexible for different devices and are referred to as off-the-shelf test solution packages. The availability of off-the-shelf solutions for performing production-line measurements on chipsets free test engineers from developing unique "systemized" test approaches, and enables RF test engineers to focus on the development of their software to integrate the application programmable interface (API.) But the architecture and design of the off-the-shelf software is critical to addressing manufacturing needs for WiMAX and WLAN device testing in a production context. Optimum software will provide the power and flexibility to address a variety of use models and device-under-test (DUT) configurations, helping manufacturers speed their products to market.
In a production line, only a fully automated use model will suffice and so the off-the-shelf test vendor software API must be configured within a test executive. There are three common examples of manufacturing systems that may require chipset-specific software and in which test vendor software provides an easily integrated solution. Figure 1 illustrates some of the architecture and theory of operation of such software, showing how it can work in different manufacturing implementations, such as for a localaccess, stand-alone single-function device (Example 1 in Fig. 1), for a remote-access, stand-alone singlefunction device (Example 2 in Fig. 1) and for a local-access embedded device (Example 3 in Fig. 1).
Example 1 represents a typical scenario for testing a local-access, standalone, single-function device, such as a WLAN PCMCIA card. In Fig. 2, the DUT is represented by a WLAN laptop card. In this case, a personal computer (PC) will be required to run the test vendor's off-the-shelf software (shown in blue.) The software subsequently uses the IC vendor's DUT control dynamic-link-library (DLL, shown in green) software module for control of the DUT.
This represents a common setup for packaged wireless devices, such as plug-in PC peripheral devices for laptop computers. These plug-in devices typically use a standardized form factor, such as a PCMCIA card, PCI Express card, or Universal Serial Bus (USB) dongle. This setup can also be applied to some (factory-fitted) laptop modules in either the mini-PCMCIA or mini-PCI-E form-factor, where the DUT is placed in a test bed that routes power and communication signals directly to the device.
The manufacturer's test executive runs on the PC and communicates to the chipset-specific test equipment vendor's software using the provided API shown in Fig. 2 as a COM DLL and numbered "1" in the diagram. This DLL subsequently communicates to the test instrument and the IC vendor's chipset control DLL (supplied by the IC vendor to the manufacturer and marked as "2" in Fig. 2.) The eventual control of the device is achieved by the DUT control DLL using installed low-level device drivers (this description assumes Windows terminology) and hardware access is through the PC's operating system.
When all of the components and instrumentation are in place, as documented by the test equipment vendor, the test engineer can focus on the chipset software (shown as "1" in Fig. 2 ) and the tests that need to be conducted. The engineer can then perform the required measurements, secure in the knowledge that the interactions with the DUT and instrumentation are optimized and qualified by the IC vendor, and operating in control at a higher level within a test executive.
A second example of a chipsetspecific manufacturing test system is for a device that is remote, but still a stand-alone, single-function device to be tested. This example is illustrated in Fig. 3, which shows a device with a media-independent interface (MII), represented as a printed-circuit-board (PCB) module.
In this example there is a need for two PCs: one to run the chipset software and accommodate the IC vendor's chipset control, and a second PC to operate remotely. This is a common set-up for modules used in access points and wireless routers. The module is usually a mezzanine card that sits on top of the router motherboard. This is a typical test configuration used by contract manufacturers, enabling them to have a choice of wireless modules using the same motherboard. Although the wireless module is designed to be embedded in another larger device, for test purposes it is a device plugged into a remote PC.
In this configuration, the silicon vendor's DUT control DLL must incorporate a proxy and a stub to allow communication over the LAN. A proxy allows the device control to communicate to other equipment remotely, passing communications appropriately to the stub. The stub should be thought of as the DUT control highlighted in Example 1, in that it does the same operations, but happens to be remote in this second example. In practical terms, the proxy and stub could be a separate DLL, depending on how the silicon vendor implements it.
In the third test example, the DUT is local and embedded within a multi-functioning electronics product. The DUT is represented in Fig. 4 as a chip inside a test jig. This setup is for wireless devices that are highly embedded in another multifunction device, such as a mobile telephone. In this case, the DUT may be a single chip, usually a system- in-package (SIP) device. that must be tested on the production line. The SIP may also contain other functionality, for example, combined technologies such as WLAN and Bluetooth, and it is likely to share its RF circuitry with other devices within the SIP. Direct access to the control interface of the wireless part is not available and must be obtained via the multiprocessor unit (MPU.)
This third example will generally require that the initial setup be configured on the multi-functional device to enable the wireless device (DUT) to be tested. An example would be enabling power, configuring the RF path, and disabling other components that may cause interference. This is demonstrated as "3" in Fig. 4. The physical interface from the PC to the multifunction device is likely to be a nonstandard interface. Again, Fig. 4 shows the use of a proxy and stub. However, the proxy is now supplied by a module vendor, not a silicon vendor, as this is a multifunction device where the test is specific to a particular subsystem. The stub is provided by the IC vendor, since the chief concern is in testing a single chip in Fig. 4, rather than the complete system on the chip.
In the case of a multifunction device with multiple wireless technologies, the additional environment setup (labeled "3" in Fig. 4) may also be used to enable further testing. For example, an off-the-shelf measurement software solution for vendor chipsets can provide test coverage of multiple formats for the complete test of the multifunction device such as a WLAN and Bluetooth combination chipset or a WiMAX and WLAN combination chipset.
From these three examples, it is apparent that no matter what the physical interface, specific device implementation, or IC vendor architecture, testing can be completed using a single test vendor's API. Packaged, off-the-shelf, chipset- specific test vendor measurement software solutions can reduce time to market for test engineers needing to automate and test specific silicon vendor chipsets. Such software supports different device implementations and allows for the software API to be integrated into any test executive. Such solutions provide added value to end users and offer significant benefits compared to some existing test vendor chipset solutions. Contract manufacturers can focus on integration into their test executive, and reusing test steps and plans qualified by IC and test equipment suppliers.
FOR FURTHER READING Agilent N7300 Series Chipset Software, Technical Overview, literature number 5989- 7920EN, (http://cp.literature.agilent.com/litweb/pdf/5989-7920EN.pdf).