Wireless Manufacturing Test too High?
1 Whitepaper Lowering the Cost of Wireless Manufacturing Test esting FTTx Networks Featuring PONs Systems sdfsdf By Kurt Williams Table of Contents Overview .................................................................................................................................... 2 The Basics of Non-Signaling Test ............................................................................................... 2 Common Integration Models ....................................................................................................... 3 Cost Reduction Through Multi-DUT Test .................................................................................... 5 PC Implications of Multi-DUT ..................................................................................................... 8 Looking Forward ....................................................................................................................... 10 2 Overview This year, it is estimated that the number of mobile-connected devices will exceed the world’s population. By 2018, there will be over 10 billion mobile-connected devices, including machine-to-machine (M2M) modules—also exceeding the world’s population at that time (7.6 billion) [1]. This exponential growth continues to push wireless device manufacturers to maximize production efficiency and minimize the cost of test for each device. This paper explores the basics of non-signaling test, the various models of implementing a non-signaling test setup and approaches to lower the overall cost of test in manufacturing. The Basics of Non-Signaling Test Traditionally, cell phones, Wi-Fi routers, and wireless devices have been tested in manufacturing with equipment that enables a functional test by emulating a live network connection. For example, when testing a cell phone, a “call box” acts as a base station and a phone call is established between the Device Under Test (DUT) and the test equipment. The required RF parametric measurements are performed during this active phone call. This approach is known as “signaling” or “call processing.” In the case of a Wi-Fi device, a “throughput test” might be performed by simply establishing a network connection with an access point and sending as much TCP or UDP traffic as possible in a fixed amount of time. This approach benefits from the fact that the DUT is exercised in its true form, meaning the test equipment is connecting to and communicating with the DUT over the same network link that will be used in the real world. However, this signaling approach requires additional complexity in the test equipment (higher cost) and introduces overhead in the form of test time to establish a network connection (increased cost of test). As more cellular bands are supported and additional wireless connectivity technologies are added to mobile devices, this test time overhead becomes cost prohibitive. To combat this, chipset vendors have introduced test modes and software whereby the chipset can be controlled via a PC and instructed to transmit or receive specific waveforms. This non-signaling methodology (also known as test mode, direct mode, or physical layer test) removes the signaling test time overhead and also relaxes requirements on test equipment, enabling lower cost solutions in manufacturing. A non-signaling test setup has a several key components. Refer to Figure 1.  PC – A PC is used to control the test equipment, the DUT, and the overall flow of the test plan.  Device Under Test (DUT) – The chip or device that is being tested. The chip itself could be a standalone station card (mPCIe or SDIO interface), cell phone or reference design, WLAN/BT combo module, or WLAN router board. The RF ports from the DUT are connected to test equipment and the non-signaling control interface is connected to the PC.  Chipset driver and control library – For chipsets that support non-signaling, the chipset company will provide software required to control the chipset. This may include a PC driver (i.e. Windows or Linux) and an Application Programming Interface (API) to control the chipset.  Test Equipment – Typically controlled over Ethernet or GPIB via SCPI, the test equipment provides the Vector Signal Analyzer (VSA) / Vector Signal Generator (VSG), measurement algorithms, and waveforms for the calibration, transmit, and receive testing of the DUT.  Test Executive – software responsible for coordinating control of the DUT and Test Equipment in order to iterate over a defined test plan and generate the test results. The test plan includes the list of channels, data rates, and standards to be verified. 3 Figure 1. Basic Non-Signaling Test Setup Common Integration Models In practice, each component in the non-signaling test setup is provided by either the wireless chipset company, the test equipment company, or developed by the end user directly. There are three primary models of tackling non-signaling test used by device manufacturers, each with its own benefits and tradeoffs. Roll Your Own For device manufacturers with sufficient Test Engineering resources, such as Tier 1 handset manufacturers, it is common to have an in-house, custom Test Executive that interfaces directly to the chipset control API and to the test equipment. In this model, the end user has full control over the test setup and the freedom to innovate and optimize for their use case. However, this freedom comes at the cost of significant effort to develop and maintain a custom test framework and requires close collaboration with both the test equipment and chipset companies to understand and optimize control of each. As new chipsets are released and the interface is updated, the burden is on the device manufacturer to keep up with the changes. In this model, the end user will typically be expecting the test equipment to have a light weight, remote interface (i.e. SCPI) with a rich library of measurement algorithms for the various standards being tested. Figure 2. Roll Your Own – Test Executive and DUT Control Implemented by End User 4 Chipset Company Test Executive Due to the high level of effort required to “roll your own”, chipset companies typically develop and distribute their own software solutions to get customers up and running quickly. For example, a chipset company may provide a test executive with recommended test plans for each chipset. This test executive will have support for test equipment used internally at the chipset company and by their key customers. While this model may be the most convenient for end users, it is typically not the most optimized for test time, since the test executive must provide enough abstraction to support all required instrumentation without taking full advantage of instrument-specific optimizations. This makes the chipset company software ideal for getting up and running quickly in R&D, but not necessarily the best choice for high-volume manufacturing test. Figure 3. Chipset company test executive supporting key test equipment Test Vendor Turnkey Solutions A third approach also minimizes the level of effort required by end users, abstracts them from the details of chipset control, and provides a solution optimized for high-volume manufacturing test. In this model, the test equipment company provides a complete, turnkey solution for the calibration and verification of a specific chipset. The test equipment company is responsible for interfacing directly to the chipset companies, optimizing the DUT control interface, and leveraging these optimizations across their customer base. The test equipment company is also in the best position to optimize test times based on deep knowledge of the instrument in use. This model is arguably the most common for Wireless Connectivity testing (WLAN and Bluetooth), since these technologies are used broadly by companies with few test engineering resources. Several variations of this model also exist. For example, an end user may develop a top level application that controls test fixtures, power supplies, and other instruments, while executing the turnkey chipset-specific test solution from the command line. The key to differentiating this model from the “roll your own” approach is that the test equipment company is performing the low level DUT control operations, controlling the RF test equipment, and iterating over the desired test plan. 5 Figure 4. Test vendor turnkey solution, optimized for specific instrumentation Cost Reduction through Multi-DUT Test There are many variables that go into calculating a device manufacturer’s overall cost of test – price of test equipment, tact time, floor space, number of operators required, power consumption, periodic calibration of test equipment, repair costs, etc. At a high level, a capital investment is made in order to produce a certain manufacturing test throughput or Units per Hour (UPH). Therefore, the more devices a manufacturing line can produce in a given amount of time, the lower the cost of test per device. While this is quite obvious, identifying the correct strategy to maximize manufacturing throughput is not. However, one approach is common to all types of test stations – minimizing instrument and operator idle time. In many cases, even with a fully optimized test plan, there is room for further idle time reduction through multi- DUT test. The most basic idea of this concept is shown here. During the “Setup” time, when an operator is placing a device into a fixture, the test equipment is sitting idle. Then, while the test is running, the operator is idle waiting for the test to complete. Figure 5. Instrumentation is idle during setup time “Ping Pong” Test The most basic form of multi-DUT test is often referred to as “ping pong” testing, because the test equipment alternates testing two different DUT sockets or fixtures. While the first DUT is being tested, the second DUT is setup. Testing of the second DUT begins as soon as the instrument completes testing of the first DUT. This approach parallelizes out the setup time, which can include operator handling time, DUT power on and initialization. To implement the ping pong method, test equipment must provide multiple RF ports with internal switching and offer basic synchronization between PCs (more on the PC requirements in the next section). Alternatively, an external switch and custom software could be used. The efficiency of this test methodology depends on the ratio of setup time to test time. For example, if a DUT must power on or boot up after being inserted into the station, then parallelizing out this time will provide a significant increase in throughput. 6 Figure 6. “Ping pong” testing removes the setup time from each DUT’s cycle time From some DUTs, a dedicated PC may be required, making it necessary to provide communication between the PCs or otherwise embed intelligence in the instrument to provide a mechanism for handing off instrument control. Parallel Transmit and Receive Testing For Time Division Duplex (TDD) wireless standards, such as Wireless LAN and Bluetooth, a device can only transmit or receive at any given time. This is especially true when a chip is in test mode and may not even be listening to the outside world while the transmitter is active. This means that only the VSA or the VSG in the test equipment is active and the other is effectively sitting idle. One possible approach for addressing this inefficiency is to perform testing on two different DUTs in parallel, testing the transmitter of the first DUT and the receiver of the second DUT. For the cases where the Tx and Rx portion of the test plan are equal in time, this approach should cut the test time in half. While this approach looks good on paper, it requires a very significant amount of RF isolation between ports on the test equipment to allow for high power transmitter tests and low power sensitivity tests running concurrently. The alternative is to treat frequencies as a shared resource from the test executive, effectively locking out a band of interest, when it is in use. Figure 7. Transmit and Receive Pipelining 7 Exploiting DUT Configuration Time To understand the next concept, a closer look at a transmitter test plan is required. Using a traditional non-signaling approach, the DUT must be configured for each individual test case, before it begins to transmit the required signal. For example, a WLAN device will likely be tested in the 2.4GHz (802.11b/g/n) and 5GHz bands (802.11a/n/ac) and include testing of several different data rates, power levels, and bandwidths. Each unique combination is a test case or signal description that the DUT must be configured to transmit, before the VSA can capture and analyze the signal. The time required to configure the DUT for each test case via the non-signaling API can be much larger than the time required by the VSA to capture the signal. As a result, the VSA is sitting idle for the majority of a transmitter test plan. Figure 8. The VSA is idle, while configuring the DUT to transmit each test case This reality gives way to various approaches for increasing throughput through multi-DUT test techniques. At the most basic level, the VSA is free to measure other DUTs during this configuration time. This method is dependent on a multi- port instrument with embedded, high speed switching. As non-signaling DUT control libraries are further optimized by chipset vendors and new concepts, such as list mode, are introduced, this approach may become less effective. List mode, sequence mode, or multi-segment testing refer to an approach that allows a “list” or “sequence” of test cases to be pushed to the chipset, so that the DUT can iterate through the entire test plan without repeated interaction from a control PC. Parallel Receiver Test When testing a transmitter, the VSA can only capture from a single device at one instance in time. However, this limitation does not apply to receiver testing. With the proper hardware, the same downlink waveform can be sent to multiple DUTs at once, allowing for parallel receiver testing. This approach is especially beneficial for test plans dominated by receiver test time. Because receiver tests are typically performed at specific sensitivity levels, the power at each DUT must be the same. This places a strict requirement on an instrument to provide equal path loss across the active ports during a parallel receiver test. Multi-RF Another approach to multi-DUT testing is using a multi-RF or “multi-TRx” instrument, saving space, energy, and cost by sharing a common chassis, power supply, communication bus, and set of software licenses. Prior to this type of architecture, a test rack designed for parallel test of four DUTs would contain four independent, single-RF instruments. 8 Figure 9. Multiple, independent VSA/VSG modules in a shared mainframe save space and cost In some cases, the multi-TRx approach has significant advantages over previously discussed approaches that share a single VSA/VSG. For example:  The manufacturing test throughput of a dedicated VSA/VSG increases as DUT configuration time decreases and optimizations, such as list mode, are introduced. In the shared VSA/VSG case, multi-DUT efficiency will likely decrease as the DUT configuration time is optimized.  Multi-TRx test systems allow for parallel testing of different wireless technologies, such as interference test or testing cellular on one DUT while testing WLAN on a second DUT.  Instrument maintenance and failures only take down one fixture, not an entire multi-DUT station. The choice between an instrument sharing architecture and a multi-TRx solution comes down to the details of the specific test setup, test plan, performance of the chipset non-signaling API, and future plans for the instrument that may significantly change any of these contributing factors. PC Implications of Multi-DUT Initially, it seems logical that a single PC would be used, irrespective of the selected multi-DUT approach, as shown below. Figure 10. Single PC multi-DUT architecture 9 However, using a single PC is not always practical or even possible, depending on the physical non-signaling interface to the DUT, the chipset driver, and the chipset control API. For example, when testing a standalone WLAN/BT module with an SDIO or mPCIe interface, it is much simpler to dedicate a PC to each DUT, than to create a robust setup with multiple SDIO or mPCIe interfaces on a single PC. Beyond the physical interface, the non-signaling API provided by the chipset company must have been written in a way that multiple instances can operate concurrently on the same operating system. Figure 11. Some DUTs require a dedicated control PC In the architecture above, each DUT has its own, dedicated control PC. With a multi-TRx instrument, this is the most straight forward way to upgrade a multi-DUT station that was previously using multiple single-RF instruments. In this upgrade scenario, dedicated PCs also simplify the requirements on the test executive and DUT control software, since the same single-DUT test station software can be directly reused. A third architecture is needed when the DUT cannot be controlled from the same PC as the test executive. A standalone PCIe or SDIO module with a Linux driver is the most common reason for this. In this case, a dedicated Linux PC is used to host the chipset and provide a remote control interface to the test executive, as shown below. In an alternative approach, chipset vendors will provide a Linux-based router platform that can host the chipset, so that a PC is not required. 10 Figure 12. Multi-DUT setup with dedicated DUT PCs Looking Forward As more wireless technologies continue to make their way into mobile devices, it is becoming increasingly important for device manufacturers to select test platforms that will withstand the test of time and leverage multi-DUT optimizations across technologies. The Anritsu MT8870A Universal Wireless Test Platform is a future-proof, modular solution supporting wireless connectivity, cellular, and broadcast technologies in one box. Customers are using the MT8870A to solve today’s wireless test challenges, such as 802.11ac, Bluetooth low energy, and LTE. This same solution will allow them to solve tomorrow’s challenges due to the instrument’s continuous frequency coverage from 10 MHz to 6 GHz and 160 MHz of bandwidth, capable of supporting standards such as LTE Advanced and 802.11ah. On the software side, Anritsu provides a full remote programming interface for the MT8870A via SCPI or .NET, allowing customers to script simple tests in Python or integrate the MT8870A into their own custom test executive environments. The MT8870A offers a huge amount of flexibility for customers writing their own software since it can be populated with up to four TRx modules (VSA/VSG), each with four ports. Anritsu also provides CombiTest, a complete turnkey test solution so users can get up and running quickly with the latest connectivity and cellular chipsets. CombiTest includes all the software required for users to define and execute test plans without any programming. Sources: 1. Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018 11 © Anritsu White Paper Number: AnritsuWirelessTest an_0314_v1 Printed March 2014