The Automated Test Blog

OK, time for the last of my 5 trends in test for 2008:

Emulation-Based ATE That Improves System-on-a-Chip and System-in-a-Package Testing

As semiconductor devices become more complex, the process of testing each part completely with a traditional vector-based methodology is increasingly difficult. Complex systems-on-a-chip(SoCs) and systems-in-a-package (SiPs) require a system-level functional test more closely related to testing components placed on a printed circuit board than a typical chip test, but they still require the high speeds demanded in production test for the semiconductor industry. The strategy of testing a device by emulating actual real-world signals provides a better method of functional test for these types of high-speed systems. This emulation-based ATE, or also termed “Protocol-Aware ATE” during last year’s International Test Conference, combines FPGA-based hardware to emulate the rest of the system in real-time with the pin electronics found in traditional ATE. This lowers the total cost of test through better use-case coverage and improves the user’s ability to debug failures. I explained this idea in more detail in a recent blog post. In 2008, I expect more vendors to incorporate elements of emulation-based tests into traditional tester architectures and for more users to incoproate platforms currently used in functional test, such as PXI, into chip validation and test applications.

As I stated in an earlier blog post, I’m planning to discuss one of five industry trends per blog entry over the next few weeks. My 4th trend is:

The Explosion of Wireless Standards
Test engineers are facing new challenges as the use of wireless technolgies is rapidly expanding. This was a hot topic during the recent CES 2008 conference. One article covering CES, stated “Today’s young people might be called the wired generation, but judging from this year’s Consumer Electronics Show they might not have to deal with actual wires for much longer.” Below are few examples of products that have traditionally been “wired”, but are now becoming “wireless” devices:

• • Apple Time Capsule, which is a 1 terabyte wireless hard-drive using 802.11n.
  • GM Vehicle-to-Vehicle technology, cars are becoming wireless network that can broadcast position, speed, heading to surrounding cars.
  • Samsung flat-panel wireless TV, that receives its data from an 802.11n transmitte

As Wireless transitions from a vertical industry into a horizontal application, more and more test engineers will be faced with the challenge of testing RF wireless capability. Soon, RF instrumentation could become as ubiquitous as general-purpose instruments such as digital multimeters. This growth in adoption requires test engineers to learn wireless protocols and keep pace with the rapid introduction of new standards. This trend was reflected in the 2007 Test & Measurement World Salary Survey (which I blogged about late last year), in which subscribers across engineering disciplines were asked to identify the top technologies they are being required to learn. Among the top responses were WLAN and WiMax.

As I stated in an earlier blog post, I’m planning to discuss one of five industry trends per blog entry over the next few weeks. My 3^rd trend is:

Growing Popularity of FPGA-Enabled Instrumentation
Another area experiencing rapid expansion in the test industry is the increase in system-level tools for field-programmable gate arrays (FPGAs). FPGAs are powerful because they are inherently parallel, deterministic, and reliable and can be defined and reconfigured in software. While FPGAs are used inside many embedded designs, and even standalone instruments, users are not typically given access to reprogram them. More manufacturers are beginning to include open FPGAs on modular instruments and are giving test engineers the means in software to reprogram them according to their requirements. With this capability, test engineers can embed a custom algorithm into the device to perform in-line processing inside the FPGA or emulate part of the system that requires a real-time response. Historically, most test engineers do not have expertise to program FPGAs because they familiarity with hardware description languages like Verilog or VHDL which use low-level syntax to describe hardware behavior. New system-level tools are emerging that provide test engineers with the ability to rapidly configure FPGAs without writing low-level HDL code. LabVIEW, for example, can target onboard FPGAs and synthesize the necessary hardware directly from a graphical LabVIEW program, dramatically reducing the complexity of the code development. I’ve been amazed at the things our customers, who are often domain exprerts, but not experts in hardware design, have been able to accomplish with LabVIEW FPGA.  Examples include testing RFID devices performing bit-error-rate testing (BERT) of military communication protocols.

As I stated in my last blog, I’m planning to discuss one trend per blog entry over the next few weeks. The second trend in Test and Measurement is:

Growth of Software-Defined Instrumentation

One issue facing test engineers is that test instrumentation is not updated as rapidly as the devices being tested. The functionality of these complex devices is being defined by the software embedded in them, such as the Apple iPhone, which gives design engineers the ability to add features faster than ever before. This is increasingly challenging for many test engineers because most stand-alone instruments often lack the measurement capabilities of the most recent standards due to the fixed user interface and firmware that must be developed and embedded in them.
Thus, test engineers are turning to a software-defined approach to instrumentation which gives them the ability to quickly customize their measurement algorithms and user interfaces to meet specific application needs and integrate testing directly into the design process, further reducing development time. PXI is the example of a widely used software-defined instrumentation standard for building modular, reconfigurable high-performance automated test systems.

Kiran Unni, Frost & Sullivan Measurement & Instrumentation research manager, recently confirmed that PXI is influencing this trend when she stated, “The adoption of tools such as PXI is an indicator that companies recognize the benefits of moving toward software-defined instruments. The savings being realized in capital equipment, system development and improvements in system efficiency all contribute to reducing the per-unit cost of test, directly influencing the bottom line.”

This is the time of the year where you see a lot of people making their predictions on the hot trends in 2008 and beyond. Of course, as the old joke goes, predictions are hard, especially the ones about the future. But, anyway, here goes.

Since my company serves a very broad and diverse set of customers, I get the opportunity to talk to electronics designers and test engineers in applications ranging from medical devices manufacturing to high energy physics experimentation. The common thread that continues to resurface is that they are each facing the challenge of testing increasingly complicated designs with shrinking timelines and budgets. These demands have led to five major trends that I believe will significantly influence the Test and Measurement industry over the next three years. Instead of blogging them all here today, I will share one per entry over the next few weeks. The first trend is:

Increased Use of Multicore/Parallel Test Systems
Processor manufactures, such as Intel and AMD, have started developing processors with multiple cores on a single chip to continue realizing performance gains without increasing clock rates (otherwise, PCs would soon be doubling as ovens). With multicore processors, test engineers can develop automated test applications capable of achieving the highest possible throughput through parallel processing. However, this is not as easy as it sounds. Check out a few articles describing the challenge of multicore programming:
• The Free Lunch Is Over : A Fundamental Turn Toward Concurrency in Software
• Dearth of tools could stall multicore onslaught

The summary is that programming multicore puts fundamentally different requirements on software, and most of today’s software tools don’t have very good native and scalable ways to deal with it. Sure, you can create a multithreaded program in C and synchronize it using textual constructs, but try scaling that to 80 cores (the number Intel plans to demonstrate by 2011). Graphical languages, however, such as NI LabVIEW, are able to elegantly represent parallel concepts; in fact, LabVIEW already automatically scales programs to multiple cores and has demonstrated significant performance improvements over single core processors.

Multicore technology is not only an opportunity to increase performance, but as Herb Sutter describes in the ‘Free Lunch’ article above, the performance improvement we have taken for granted with each generation of processor may no longer hold if our programming environment does not take advantage of the parallelism.

My friend and colleague Ian Bell, Marketing Manager of our UK office, has started a blog as part of the publication Electronics Weekly. I, of course, welcome him to the blogging community. In merely his third blog, however, Ian has picked a fight with me. Not intentionally, of course. He could have blogged about something slightly less polarizing, like politics or religion, but, no, he had to go after something really controversial - the iPhone. You see there are two types of people in world, those that enjoy the pleasures of ownership of one of the greatest electronic devices of the decade, and the jealous majority that haven’t seen the light and thus fill their days talking about how over-hyped and unoriginal the iPhone is. If you haven’t figured it out yet, I am of the former camp, while Mr. Bell is of the later.

I’ve resisted blogging about the iPhone…its already over-hyped, nearly cliche. What else can I add? But I feel compelled to respond. Mr. Bell notes that “Apple invented nothing in the iPhone”. He couldn’t be more wrong. By this definition, anything built on top of pre-existing technology components is not invention. He also notes, like so many other iPhone haters before him, all the technical features it lacks. I think this is, in fact, Apple’s greatest contribution of all. As engineers, we are constantly tempted to add features into our designs. The products we use every day don’t have too few features, but rather too many. What we have too often lost is the elegance and simplicity that comes from making hard choices in our designs. The iPhone developers, for example, didn’t include 3G capability. A ridiculous oversight in 2007, you say? I say my phone is slimer with better battery life than any 3G phone I’ve seen - and WiFi hotspots are becoming more and more ubiquitous. They also ‘left off’ GPS. Yet, I have an software application on my iPhone that uses WiFi and cell phone towers to triangulate my position. Not perfect in wide open spaces, but on a recent trip to New York City, it gave me sub-block accuracy. It also can give me the position of my friends and family, by the way. As they have demonstrated many times before, Apple’s greatest contribution is their focus and restraint - the ability to understand what matters and sets them apart (Great software, a beautiful screen, the touch interface, sensors that works like magic, a slim design, and simple synchronization) and make the tough calls to not bloat the feature set with everything else.

I could go on all day…but I want to draw at least one parallel with the test industry. Apple made the decision to put a disproportionate amount of their resources in the software running on the phone - betting that through software they could deliver usability, integration, and features at a level never before available in a handheld device. My guess is that they have at least twice the number of software developers as their competitors. At NI, we have taken a similar approach to measurement and automation. We have placed our bet on the power of PC technology and software-defined measurement devices. We invest disproportionally in our drivers and application software and have been able to deliver a platform that continues to get more powerful and flexible through software.

Welcome to the blogosphere, Ian.

I recently presented at a group called the Semiconductor Test Consortium, or STC. There were two subjects of the talk – learnings from PXI and other industry standards and emerging trends in SOC (System On a Chip) and SIP (System In a Package) functional testing. The latter has been the subject of some interesting discussion of late in the semiconductor test industry.

The challenge that many chip designers face is that the devices are increasing in complexity at a rate that exceeds the advances in testing technology. The result is that the cost to manufacturer complex semiconductor devices is decreasing faster than the cost to test them. In validation, the issue is not only test cost, but overall test time, which can impact the time to validate new silicon and, ultimately, time to market.

As devices begin to resemble complete systems, a higher level test methodology is called for to both reduce the tester’s complexity, as well as provide a tighter link back to the system level design tools. An engineer at Broadcom recently coined the term “Protocol Aware ATE” to describe this need and at the International Test Conference (ITC) this year, there was a panel discussion on this trend. The idea is to create a test system that can perform functional testing of a device by emulating the device in situ, or in its intended surroundings. This requires the capability to model the other components of the system and to interact with the device in real time.

This is similar in many was to functional testing that is already routinely done at the board and system levels. For some devices, this is just stimulus-response type testing performed at the end of the manufacturing process. When real-time response is needed, this is very similar to a technique called Hardware in the Loop, or HIL, used extensively in automotive and aerospace validation testing. For chip testing, the real time requirements are often more stringent. A technology that has promise to meet many of these requirements is the Field Programmable Gate Array (FGPA), also noted as an ideal architecture in the Broadcom paper. A programmable FPGA placed in the tester close to the device under test, can be used to emulate the system and test the device in situ. The FPGA also holds promise as a target that can run system models directly from system level design tools to bring design and test closer together.

I just read the latest 2007 Test and Measurement Salary Survey. One of the questions that really peaked my interest was on the topic of what technologies are engineers being required to learn. The number one test platform listed was PXI (20% of readers listed it), with PXI Express, an extension to PXI, a close second. This is just another example of the increasing industry adoption of PXI. Most of the other technologies engineers are being asked to learn are communication protocols - Firewire, WLAN, and WiMAX were all high in the ranking.

I’d like to clarify the difference between these two terms as I have found that there is very often confusion between them. The distinction is entirely in the software model and the programmability of software-based analysis by the instrument user. A Virtual Instrument’s primary programming model is to present raw data to the user for customized measurements. A Traditional Instrument’s primary programming model is to present vendor-defined measurements to the user.

What about Standalone Instruments versus Modular Instruments? This is a question of form-factor, not software, and is therefore entirely orthogonal to whether the instrument is virtual or traditional. A standalone instrument can indeed be used as a virtual instrument. An example is a standalone oscilloscope that is automated to create custom measurements in software. Similarly, it is possible for a modular instrument to present only a traditional use model to the user; VXI instruments, for example, were most often vendor-defined instrument repackaged in a modular form factor.

While the definition of virtual instruments and modular instruments is orthogonal, it is true that many modular instrument standards lend themselves to building virtual instrumentation systems. In order to effectively perform user-defined analysis on a signal, the user must have access to the raw data from the instrument’s acquisition. For high-speed measurements, this requires transferring many megabytes of data from the instrument to a processor to be analyzed in software. High-speed interface buses such as PCI Express, which can transfer data at up to 4 Gigabytes/s, are well-suited to this application. Instrumentation standards such as PXI combine high-speed buses and upgradeable PC-based processors, making it an ideal platform for virtual instrumentation systems.

PXI is celebrating its 10 year anniversary in 2007. Richard Quinnell at Test and Measurement World recently wrote about PXI’s anniversary, highlighting the compatibility it has achieved during this time. For me, its been remarkable to see the growth and changes in this marketplace over the past 10 years, especially all the times that PXI vendors achieved “the impossible”. Here are a few of my favorites:

• 1999 - 50 members and over 200 products. The first few years of the standard saw a rapid adoption by vendors and the release of a lot of products. Grow exceeded expectations in every dimension.
• 2002-PXI’s entry ito RF. Prior to the release of products by National Instruments and Aeroflex, certain vendors had been outspoken that “you could never do RF in PXI”. Last year, Phase Matrix announced that they are taking PXI all the way up to 26.5 GHz!
• 2003 - PXI systems shipments exceed VXI. By 2006, PXI vendors shipped over 10,000 systems per year - 3 times larger than VXI at its peak. Naysayers claimed modular systems would never be mainstream.
• 2004- A 512 Cross-Point Switch. With the release of the PXI-2532, National Instuments put to rest those that claimed the Achilles heal of PXI was switch density.
• 2005-PXI Express. The PXI Systems Alliance did a remarkable job incorporating new technology to achieve a 45-fold increase in bandwidth while preserving backward compatibility. Those that claimed PCI Express would break compatibility become suddenly quiet.
• 2007 - Agilent joins the PXISA. Agilent Technolgies joined other big name vendors such as Advantest, Aeroflex, Keithley, National Instruments, Rohde & Schwarz, and Teradyne. So much for not having any big name companies in PXI!