DesignCon Accelerating Automated Test and Protocol Aware ATE Through Open FPGA-Based Solutions

Transcription

1 DesignCon 2013 Accelerating Automated Test and Protocol Aware ATE Through Open FPGA-Based Solutions Ryan Mosley, National Instruments Page 1 of 21

2 Abstract Using commercially available off-the-shelf technology, open FPGA architectures provide a simple-to-use platform that may be easily used to speed up development and deployment of production test solutions for mixed-signal and system-on-a-chip (SOC) devices. FPGAs may be used to accelerate data processing, perform complex parametric analysis and binning, and even implement protocol aware test methods effectively removing the overhead of host system interaction gaining substantial improvements in efficiency and test time. Standard interfaces, such as PCI Express and JESD204B combined with IP from FPGA vendors make FPGA acceleration of complex processing tasks easier than ever. Coupled with programming environments or abstraction layers such as the NI LabVIEW FPGA Module, the complexity of coding applications in VHDL or other HDL languages is abstracted away such that deep domain knowledge is no longer required to successfully design and develop using FPGAs. This paper demonstrates examples that contrast the test performance of traditional automated test equipment (ATE) with a modular instrumentation platform when an open FPGA is introduced into the test flow. This paper shows how these same open FPGA platforms are available on platforms that are easily scaled to benchtop verification and validation of devices allowing for better, faster correlation between validation and production test. Page 2 of 21

3 Author Biographies Ryan Mosley earned a bachelor s degree in electrical engineering from Vanderbilt University in Nashville, Tennessee, in He then completed his M.A.Sc. degree in electrical engineering with a concentration in circuit design from the University of Texas at Austin in He joined National Instruments as a member of technical development staff for modular instrumentation in 2000 where he spent eight years in product development for ATE and general-purpose test solutions. He is currently a senior R&D group manager in modular instruments where his primary responsibilities are defining future development and roadmap strategies for the modular instrumentation platform. Page 3 of 21

4 1 Introduction For decades, traditional test methods have been dominated by stored response models where data is generated from simulations and passed to test teams for conversion to either standard file formats such as WGL or STIL or to platform specific files. These vector files and wave tables contain no practical information about what the DUT is or how it should behave in the field. For example, if a functional simulation is executed with a 1 ps timestep, the resulting VCD file will maintain that level of timing resolution. Without context for what those signals are, a test engineer is forced to design a test system that can support that level of performance. Had the test engineer known that that signal was a functional SCAN chain with significantly reduced performance requirements, they may have been able to simplify their test procedure and driven down the overall cost of the tester. Andrew Evans discusses the problem of scalability of a store response model in the face of increasingly complex SOC designs. In his 2007 discussion at the International Test Conference (ITC), The New ATE: Protocol Aware [1], he describes the problem that the gap in test methodology between Bench Validation/Design Verification, and especially the native mission mode customer application for IC s versus the ATE production test suite has been increasing with IC integration. That is, as devices scale in complexity and integration, the traditional methods for generating stored response style vectors is no longer practical for test development efficiency. He summed up the problem succinctly by posing the question: Isn t it really crazy that a multi-million dollar tester can t natively speak JTAG, yet a few thousand dollar device connected to a PC can? [1] He proposes that a tester should, instead of toggling bits in a manner that looks like a protocol, natively speak I2C, MDIO, JTAG to get functional test coverage that is consistent with how the device was developed and verified on the benchtop. A truly amazing side effect of PA ATE is that once operating at a higher level of abstraction, Test IP based on language instead of fixed captured simulations in the form of test patterns, can easily be shared. [1] Since Andrew Evans challenge to adopt Protocol Aware test methods in the validation design flows, many ATE vendors have adopted strategies that include PA test. For example, Teradyne, Inc. and Verigy/Advantest now have the ability to execute Protocol Aware test. Mark Jagiela, president of semiconductor test at Teradyne, Inc. began mentioning the adoption of PA methods in his June 2007 discussion at the Korea Test Conference citing it as a means to address the dilemma of IP sharing between design and test organizations [2]. PA test attempts to solve the problem of design reuse and test abstraction and has been successfully gaining traction. However, though Evans proposes a solution that takes advantage of available FPGA technology [1], a broader opportunity enabled by that technology has widely been overlooked. FPGAs, inherently an open digital platform, may be leveraged to not only abstract the test routines, but to implement them explicitly. Page 4 of 21

5 Although current implementations of PA test allow test engineers to build standard or custom protocols using spreadsheets and other proprietary tools. These solutions sit on top of the stored response model to appear to be protocol aware, but are not truly protocol implementations. If test engineers had direct access to the digital resources in an open FPGA platform, a JTAG functional block may be directly instantiated in the tester allowing for actual mission mode test of the design. Furthermore, because FPGAs execute compiled HDL, many of these test functions may be directly leveraged from design simulation, tech benches, and unit testing, closing the gap between test and design. Though FPGAs enable PA test, it is just a fraction of what FPGAs are capable. Once the FPGA is fully opened up to the test engineer, there are now opportunities to push more of the historically software stack and parametric analysis into a deterministic hardware platform driving down the overall test time. This paper introduces and examines benefits and shortcomings of adopting a Software-Designed ATE platform to solve PA ATE and to expand the leverage between design and test. Additionally, various possible Software-Designed ATE solutions are introduced and compared. Examples are given to show a new design flow and the test time benefits that may be achieved on such a platform. 2 Traditional Test Process/Flow A traditional test flow takes advantage of onboard memory and patter formatters and sequencers by storing a set of correlated stimulus and expected response data. These patterns are created from simulation through many levels of conversion and formatting. The end result is that test engineers have access only to a table of bits and timing with little to no context for the meaning and purpose behind that data. During tester and production debugging, correlating test results to functional blocks is nearly impossible and will certainly require interfacing back to the design engineer to interpret results. Figure 1: Traditional Test Iteration ( [1] ) Page 5 of 21

6 This stored response model is used to perform structural and functional test but can only emulate protocols commonly found on most ICs. Implementing a slave I2C interface, for example, in this model of test is nearly impossible. Additionally, as SOC designs increase speed and performance, the determinism required by the stored response method starts to break down. System considerations such as clock domain crossings and variable FIFOs make sample accurate response comparison difficult to manage. Jochen Rivoir, system architect at Verigy/Advantest says that IC vendors are increasingly experiencing test escapes from pure structural test. Escapes are believed to stem mostly from unrealistic clocking and unnatural device activity during structural test. [3] This is often accounted for by using built-in self test (BIST) techniques to run these interfaces at maximum speed. Interfacing to these BIST blocks should be a simple task with high degrees of leverage between designs and test platforms. In the absence of abstraction, the portability is low and the time to bring up is high. 3 Protocol Aware Test Methodologies Protocol Aware Test addresses the inefficiencies in the process by providing for abstraction layers between the pattern memory and the functional test blocks. Figure 2: Protocol Aware Flow (Evans, 2007) [1] The notion of PA testing is that the tester actually speak the language of the DUT. If the DUT has a native MDIO, I2C, SCAN, PCI Express interface to the functional or BIST blocks, then the test engineer may more efficiently interface and exercise those blocks using reusable IP that actually speaks I2C. For example, if the intent of test is to verify that one can write to a register, enable a function, and verify the function of that register, then the test engineer is more effective at writing and debugging the test if they issue a WRITE function, instead of creating a pattern of bits with arbitrary timing that results in a register latching its values. Page 6 of 21

7 Fundamentally, if design engineers benefit from levels of abstraction and reuse, then so too will test engineers. Benefits of leveraging IP between design and test will additionally speed up the development and deployment of test solutions and will more effectively achieve correlation between benchtop and ATE testing during bring up and debugging. Protocol Aware ATE methods have been adopted by most leading ATE vendors such as Teradyne, Inc. and Advantest. Both have established design flows for creating protocol test patterns and each platform allows for test engineers to design protocol templates that are used for generating patterns that emulate the protocols. Figure 3: Verigy/Advantest Protocol Editor [5] These tools implement PA ATE concepts on the traditional stored response backend. They provide an API or a level of abstraction that absolutely increases the efficiency of test development and station debugging at the expense of up front template design. However, there still exists a gap in reuse of IP between designers and test engineers. Though they share concepts ( speaking the same language ), they do not share IP, requiring test to redesign what the developers have already produced. However, these tools do allow for better reuse between DUTs where protocols remain unchanged, for example, between generations of DUTs. Though these tools address the immediate need for better abstraction, they do not give test engineers the ability to creatively use the resources that may be available in the platform to speed up the execution of tests. Algorithmic pattern generators (ALPG) have been a capability of ATE for several years but are similarly implemented using pattern/address look up and sequencing [6]. Used to generate memory test patterns for Page 7 of 21

8 years, this type of testing should be considered as Protocol Aware but miss an opportunity to take advantage of readily available technology, FPGAs. To truly be Protocol Aware and generate model-based patterns on the fly or to actually implement a protocol tester, the hardware needs to be completely open and reconfigurable by the test engineer. That is, to achieve the Native Emulation proposed by Evans [1], a test engineer needs to be able to implement a custom state machine behind each tester pin. Without exposing an open architecture to test engineers, PA ATE systems will not completely achieve a mission mode style of testing. Furthermore, without a PA platform that spans both digital and mixed-signal test pins, these methods only partially solve the problems test engineers are exposed to. PA ATE implementations largely ignore the mixed-signal nature of many components such as power amplifiers, where interfacing to a digital port and to internal BIST registers is only a fraction of the overall test burden. Though test engineers may leverage the protocols to interface to mixedsignal devices, they should additionally be able to leverage the analog models from the design team to aid with test development. Each of these problems can be addressed by a platform that takes advantage of and exposes the full features of existing FPGA technology to test engineers in a fashion that is intuitive and correlated to the design of the DUT to more seamlessly flow from design to test. 4 Software-Designed ATE Test Methodologies 4.1 Software-Designed ATE Test Defined The concept of a Software-Designed ATE platform is based on giving access to the full resources of FPGAs to the design and test engineers. Designers, working in HDL languages such as Verilog and VHDL should, as domain experts, be comfortable designing for FPGAs. However, test engineers, focusing on test, should not be forced to learn HDL concepts to successfully implement testing algorithms. Critical to the success of a Software-Designed ATE platform will be a software stack that provides sufficient abstraction or APIs to be intuitive to test engineers but powerful enough to allow for leveraging IP directly from the design engineers. During the design and validation process, developers perform suites of unit testing, which may include simulation and benchtop test. To accurately simulate an I2C port, for example, the developer must create an I2C peripheral model and stack of register accesses to provide the stimulus for the simulation. If the designer develops that model such that it is synthesizable, then that IP can be directly used by test engineers in a Software-Designed ATE platform achieving higher degrees of efficiency and correlation. Protocol Aware, as a subset of Software-Designed ATE, may be implemented by providing API and standard IP libraries. For example, an API like SPI_WRITE can be provided to maintain the current PA ATE design flow. However, should a DUT require the tester behave as a slave SPI device, the API can instead sit on top of a SPI state Page 8 of 21

9 machine that truly behaves as a slave device instead of having to trick the tester into behaving appropriately. Such capabilities are necessary to achieve a mission mode test solution. However, looking beyond the PA ATE applications of a Software-Designed ATE solution, once the FPGA is opened up to engineers through an intuitive interface, additional tester burden can be pushed down into hardware. A complete suite of continuity and functional tests, for example can be integrated into the FPGA through simple state machine design. By removing the software stack from the tester overhead, both test time and jitter decrease. PPMU DRV CVL CVH Figure 4: Software-Designed ATE Architecture 4.2 Applications of Software-Designed Test The initial value for Software-Designed ATE would be in realizing the Hybrid / Native solution [1] for Protocol Aware test space to provide native support for interfacing standards instead of emulated protocols. In this model of test, the FPGA is used to instantiate the designer s stimulus models or IP from a library of commonly used interfaces. These would likely be in the form of some HDL libraries or from previous DUT test programs. The implementation of this platform is consistent with Andrew Evan s Hybrid approach [1] and includes all the necessary hardware resources driven by an open FPGA. However, this approach should be expanded to include mixed-signal resources such as digitizers and RF instrumentation. Figure 5: Custom Protocol Implementation Hardware-in-the-loop (HIL) testing has been popular in embedded test and prototyping applications for years but have not yet found traction in ATE. The notion of Page 9 of 21

10 closed-loop testing does not map well to a vector-based test platform found in most ATE systems. With a Software-Designed ATE platform, closed-loop testing can more easily be applied in test environments. Closed-loop testing implies that the stimulus may be adaptive to the response of a DUT. That is, the test program may change as a program is executing. This is more intuitively applied to mixed-signal test applications such as power amplifier testing where power level servoing settle time may be significantly improved by closed-loop testing. If the hardware can make changes to a stimulus without having to traverse the software stack, test overhead may be significantly reduced. PPMU DRV CVL CVH Figure 6: Hardware in the Loop Algorithmic pattern generation has been a capability available in tester platforms for years but are implemented with closed logic machines wrapped around the stored response model. With a Software-Designed ATE platform, logic may be generated using any means of synthesizable logic. A simple PRBS pattern or memory testing algorithms could actually be implemented using a basic linear feedback shift register or other logic machine instead of generated offline and stored in memory. Simple DUTs such as logic gates are an ideal component to be verified using a Software-Designed ATE platform. Stimulus and response data is easily and rapidly generated in the logic of an FPGA and may be algorithmically generated on the fly rather than building test programs unique to each logic gate. HOST Interface FPGA Algorithmic Pattern Gen Pin Electronics Memory Memory Figure 7: Algorithmic Pattern Generation Page 10 of 21

11 Additionally, with an architecture that has open logic resources and an intuitive programming paradigm, much more of the testing burden may be driven into the FPGA. Once the test has been abstracted to register-level programming, those registers can be scripted and stored into hardware. The FPGA can sequence through them deterministically or algorithmically, removing the software overhead. Precision floating point arithmetic in FPGAs have evolved to the point where precision and performance necessary to test most digital and mixed-signal components. Figure 8: Hardware Test Sequencer 4.3 Software Design ATE Design Process Flow In order to take advantage of a Software-Designed ATE platform, a new design and test flow needs to be adopted. To gain the maximum benefits for development and execution, there has to be a large degree of reuse between the development and test teams. These can largely be achieved by test reusing IP and block from developer simulations which requires that developers design their test benches such that they can be synthesizable. These synthesized blocks should then be captured in a database of common interfaces. For example, future developers and test engineers should all be using the same I2C models, all of which should be easily and readily available. Test engineers can integrate those models into their Software-Designed ATE platform using the tools provided to them from the vendor. The critical divergence is that test engineers, instead of building protocol aware patterns or raw vectors to emulate the protocol busses, will read and write directly to memory mapped registers. These test programs should be highly leveraged from the validation lab unit testing. Page 11 of 21

12 5 Open FPGA Platforms and Solutions FPGAs are configured using HDL languages such as Verilog or VHDL, neither of which are traditionally core competencies of test engineering. To gain traction, a Software-Designed ATE platform must be programmable in tools that are consistent with existing tools or intuitive enough to be used with minimal overhead. The focus of test development should be on the test sequence, not the language or tools in which the sequence is generated. Additionally, it is critical that the tools span both design and test. This should likely require that sufficient levels of abstraction be provided in addition to readily available libraries of IP. The tools should also be compatible with traditional digital design methods allowing for leverage of models used in the design and unit testing of the DUT and integration with higher level abstractions. Above all, though, a Software-Designed ATE test platform needs to be able to take the measurements necessary for validation. 5.1 Software Development Platforms The content of this paper does not cover various tools used for textual HDL development. Those tools exist and are well documented and prevalently used in industry. This paper focuses on those FPGA tools that enable the abstraction and integration previously discussed as requirements for a Software-Designed ATE platform. The MathWorks HDL Compiler TM tool allows for a graphical design of logic blocks including generation, verification, and optimization. Using a familiar environment such as Simulink, MathWorks tools ease the development of digital filters and state models by providing a common set of tools and IP. HDL Coder TM takes as inputs common.m files and Simulink models and converts them to synthesizable HDL code [7]. Additionally, IP is provided for many standard signal processing algorithms such as Viterbi decoders and filters. The resulting HDL code may then be ported to third-party hardware targets. Figure 9: HDL Coder TM by MathWorks [7] A graphical environment such as Simulink provides an intuitive interface for developing complex systems. Though the HDL Coder TM makes developing the Page 12 of 21

13 algorithms easier and more consistent with the development process, it does not provide a complete stack for Software-Designed ATE test. It solves the problem of building closedloop tests or complex DSP, but does not implement features such as DMA, memory controllers, bus interfaces, and so on that a complete platform provides. HDL Coder TM, could be considered part of a solution for Software-Designed ATE but not a complete solution. The Agilent SystemVUE application [8] provides a model-based design workflow for mixed-signal and RF systems. Commonly used for RF algorithm design and deployment, SystemVUE, like HDL Coder TM creates HDL modules that may be deployed onto a Software-Designed ATE target but is not a full solution allowing for HOST API to tester pin stack development. It provides design flow from concept, graphical implementation, simulation, and verification, all in a single environment providing a common environment their other hardware instrumentation platforms. Figure 10: SystemVue(tm) by Agilent [8] The National Instruments approach with the NI LabVIEW FPGA Module was to extend LabVIEW s general-purpose graphical programming environment across the full deployment curve. That is, LabVIEW code can be written to run on x86 processors, RTOSs, and directly on FPGAs. The LabVIEW FPGA Module is a proprietary solution that runs only on National Instruments hardware platforms. However, this marriage with hardware gives the tool the ability to abstract the complete software stack allowing for top to bottom graphical system design using high-level synthesis. This includes providing more intuitive access to memory controllers, DMA between HOST and hardware, a complete library of IP, and tools for test development. For example, including a DMA controller in an FPGA may take 4,000 lines of VHDL, but the abstraction provided in the LabVIEW FPGA Module simplifies that operation to a single box on the block diagram. Page 13 of 21

14 Figure 11: National Instruments LabVIEW FPGA Module [9] Additionally, the LabVIEW FPGA Module enables users to directly use thirdparty HDL (Verilog or VHDL). These may be generated by any other vendor or toolchain or be provided to the test engineers from the development team s unit testing. This combination of abstraction and HDL support allows for many unique permutations for test engineers to maximize leverage and efficiency. 5.2 Hardware Deployment Platforms Software can solve the Protocol Aware abstraction problem but it needs to be targeted to a hardware platform that is enabled with the correct I/O capabilities. For most testing, this would be a pin electronics device (DCL with PPMU). However, many mixed-signal devices would require more advanced measurement capabilities. Power amplifiers, for example, would require a system enabled with pin electronics and power meter or spectrum analyzer. ATE platforms are enabled with many hundreds of digital and mixed-signal pins but none natively support an open FPGA for development. PA test is implemented in Teradyne s IG-XL, for example, but those tools do not allow access directly to the configurable hardware. However, many tester platforms have options that allow the integration of third-party hardware such as PXI instruments, many of which do support user-level access to the FPGAs. National Instruments provides many hardware platforms enabled by FPGA technology and are compatible with the NI LabVIEW FPGA Module. Solutions such as the NI CompactRIO or NI Single-Board RIO are combinations of FPGA and analog I/O focusing on embedded applications. However, NI R Series and NI FlexRIO are PXIbased solutions targeting automated test applications such as ATE. The NI FlexRIO platform takes advantage of Xilinx Virtex class devices allowing for a wide range of Page 14 of 21

15 functions and features with large performance benefits. NI FlexRIO offers flexible I/O options through a modular plugin architecture. National Instruments, third parties, and even end users can develop front end adapter modules compatible with the NI FlexRIO platform. Figure 12: NI FlexRIO by National Instruments [10] In addition to these solutions, National Instruments has recently introduced a new Software-Designed Instrument class of products where the instrument is open source from the driver all the way down to the firmware, all implemented graphically in LabVIEW [11]. This class of instrument provides the mixed-signal measurements necessary for validating production DUTs with an open FPGA enabling customization of the algorithms used by the instrument. Alazar Technologies, Inc. provides high-speed digitizer solutions, such as the ATS9625, that are enabled with FPGA coprocessor elements [12]. These PCI Express devices allow users to insert custom FPGA logic into a shell project but do require users to build their own registers, memory mapping, and HOST-level access through standard digital design practices. Although most of the examples and materials focus on signal processing, other logic components may be developed and deployed to the target. Vendors such as Guzik, Agilent, and Geotest, have a similar approach as Alazar Technologies. They provide a hardware platform with an FPGA, HDL files to enable device functionality, and examples for how to add custom logic to the design with constraints for not breaking the driver. Through consulting services or other support channels, more complex features may be added to the project. Some solution providers are taking advantage of an open VITA 57 standard which defines an interface between FPGA hardware platforms and an FPGA Mezzanine Card (FMC). Most FPGA vendors are adopting this standard and providing the interconnect on their FPGA evaluation platforms. Third-party vendors such as DSP4 have PXI, PCI, and other bus standard implementations of an FPGA with FMC interfaces to which any FMC compatible analog or digital daughter card can be mated. These solutions, like the NI FlexRIO solution, allow customers or third-party vendors to develop custom or standard I/O solutions with an FPGA backend. Page 15 of 21

16 Though widely adopted in mixed-signal implementations, but may be easily leveraged to create test applications, all of these solutions lack high-density, pin electronic such a solution. 6 Examples of Software-Designed ATE workfloww 6.1 Power Amplifier Servo RF power amplifier testing requires that metrics are captured and evaluated at specific output power levels. To meet those requirements, it is necessary to put the control into a closed loop. Traditional ATE would have to communicate to the vector signal generator (VSG) in the test station, wait for the power level to settle out, read the power with a power meter, and make an adjustment. Because this process has to traversee a software stack several times, there are significant delays in the measurement. Using a Software-Des signed ATE solution such as the NI PXIe-5644R Vector Signal Transceiver (VSA and VSG with an open FPGA) module from National Instruments, this loop can be executed all in the FPGA resulting in significant performance improvements. Figure 13: Power Amplifier Servo with Software-Designed Instrument [11] Implementing the leveling of the power amplifier using a Software-Designed Instrument solution, we can see a 100X improvement in settling time. Figure 14: Traditional Leveling Versus Software-Designed ATE [13] Page 16 of 21

17 Additionally, once the power level is settled, the Software-Designed Instrument can continue to monitor levels, in parallel with the test procedure, to compensate for other effects such as thermal drift. Something a closed instrumentation platform cannot do. Figure 15: Thermal Droop of Traditional Versus Software-Designed ATE 6.2 Logic Device Test Sequence A simple example of the power of a Software-Designed ATE solution is illustrated in testing a commodity logic gate component: AND, OR, Multiplexer, and so on. The test program for these devices may look like the following: Test Sequence Permutations / Iterations Notes Continuity 1 Shorts 1x number of input and output pins Functional >5 ICC 4x number of power Executing same functional patterns Leakage 2x number of input IOFF 4x number of input and output pins VOH >5 per output pin Functional tests at different loads VOL >5 per output pin Functional tests at different loads Continuity 1 Verify no damage Shorts 1x number of input and output pins Verify no damage Functional 1 Verify no damage, reusing pattern For a simple 2-input logic gate this may be well over 50 test steps. With a traditional ATE solution, the testing took ~100ms of time to execute. When the sequence was ported to a modular, application-specific tester, the test time drops to 75ms. Each of these approaches includes several re-configurations of the pins for mode (digital stimulus/response or PPMU) and level in order to execute functional and parametric testing each of which requires several software calls through the driver stack which gets converted to a series of register-level transactions through some bus interface. Assuming a PCI Express based implementation, each register write may take up to 1 to 2us to execute. However, by precompiling the list of configurations or register transactions and storing them into onboard memory for sequential or scripted playback, software Page 17 of 21

18 interaction can be dropped to nearly 0 at which point the test time is dominated by how long it takes to issue configuration commands to the hardware components and by analog settling times. The application software, instead, just issues a start command and lets the hardware sequence through all of the actual configurations and measurements. No optimizations were made for algorithmic pattern generation or closed loop testing in these results. Figure 16: Single Site Cumulative Test Time for Software-Designed ATE Solution 7 Gaps With Software-Designed ATE Major gaps with a Software-Designed ATE platform are largely due to the lack of solutions targeting the ATE market. Available IP is critical to the success of both Protocol Aware ATE methods and a Software-Designed ATE approach. Both solutions thrive on an active and extensive ecosystem of IP that may be used to accelerate test deployment. However, the current obstacle to adoption and IP proliferation is the lack of all of the necessary IO points to solve mixed-signal applications. There exists many analog and RF solutions for Software-Designed ATE but few released or publicized offthe-shelf solutions for the digital and PPMU components and high-speed serial. Additionally, Software-Designed ATE may not wholly address concerns addressed by at-speed built-in self testing (BIST) of SOC designs. However, it can drastically improve and abstract the interface to the BIST components used for at-speed testing of critical components. 8 Conclusions It was shown that a Software-Designed ATE solution using off-the-shelf tools may be used to drastically improve both the development and execution of test sequences where a power amplifier test for EVM measurements decreased by 100X and a logic gate test sequence executed time decreased from 100ms to 40ms. The development of these Page 18 of 21

19 tests leverages concepts borrowed from the Protocol Aware ATE test philosophy by making the reuse between design and test engineers stronger. However, the gaps in current implementations of PA testing leave room for many evolutions of the concept to include more mission mode and hardware accelerated testing. A Software-Designed ATE solves these gaps by giving lower level access to the tester hardware through intuitive easy-to-use and highly reusable blocks. Many platforms implement software-abstracted HDL design flows as well as offthe-shelf hardware targets for those applications. Although analog and RF test applications are well served by both software and hardware tools, availability of highdensity digital tester pins enabled by these concepts are lacking in the market today. Page 19 of 21

20 Works Cited [1] A. Evans, "The New ATE: Protocol Aware," in International Test Conference, [2] M. Jagiela, "The Dynamic World of Semiconductors and Implications for Test," in Korea Test Conference, [3] J. Rivoir, "Protocol-Aware ATE Enables Cooperative Test between DUT and ATE for improved TTM and Test Quality," in International Test Conference, [4] S. Sunter, "Protocol-Aware ATE: Complement or Competitor for Structural Testing?," in International Test Conference, Panel 5.2, [5] M. Kozma, Protocol Aware Introduction, [6] H. Yoon, M.-H. Yang, Y. Kim, Y. Park, J. Park and S. Kang, "An effective parallel ALPG using instruction unrolling for high speed memory testing," SoC Design Conference, ISOCC '08. International, vol. 01, pp. I , [7] MathWorks, "HDL Coder Description," [Online]. Available: [8] Agilent Technologies, "SystemVue Electronic System-Level (ESL) Design Software Agilent," [Online]. Available: [Accessed ]. [9] National Instruments, "FPGA Fundamentals," 3 May [Online]. [Accessed 15 Nov 2012]. [10] National Instruments, "National Instruments FlexRIO - Custom I/O for LabVIEW FPGA," [Online]. Available: [Accessed ]. [11] National Instruments, "Vector Signal Tranceiver," [Online]. Available: [Accessed ]. [12] Alazar Technologies Inc., "AlazarTech User-Programmable FPGA Development Kit Designer s Guide," [Online]. Available: Designer's%20Guide.pdf. [Accessed ]. [13] National Instruments, "FPGA Servoing for Power Amplifier Test on the NI PXIe-5644R," [Online]. Available: [Accessed ]. [14] R. Burke, "Using Protocol Aware Tools to Simplify Program Development for RF SOC Test," High Frequency Electronics, vol. 10, no. 12, pp , [15] S. Fields, S. Therrien and S. Lyons, "Overcome ATE challenges for mission-mode testing of wireless tranceivers," EDN Network, [16] Xilinx, "7 Series FPGAs Overview," [Online]. Available: [Accessed ]. Page 20 of 21

21 [17] National Instruments, "What is a Vector Signal Tranceiver," [Online]. Available: [Accessed ]. LabVIEW is a registered trademark of National Instruments Corporation. Simulink is a registered trademark of MathWorks, Inc. HDL Coder TM is a registered trademark of MathWorks, Inc. SystemVue is a registered trademark of Agilent Technologies, Inc. IG-XL is a registered trademark of Teradyne, Inc. Page 21 of 21