The Automated Test Blog

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 came across an interesting blog post by Richard A. Quinnell, Technical Editor — Test & Measurement World.  In his blog, he made the following statement, “With just about everything going wireless, I’ve started wondering when PXI will join the parade.”  I felt a response by our PXI Marketing Group Manager, Richard McDonell would be appropriate.  

Guest Blogger: Richard McDonell – PXI Group Manager

Every day I learn about another common device that has gone wireless…from cell phones to game controllers to PCs and laptops.  In each of these cases, the wireless interface is replacing a previously wired solution providing increased range, improved flexibility, and added user-convenience.  These are great benefits, so why hasn’t PXI gone wireless?  Well, in many ways it already has.  PXI is already being used to design and test thousands of wireless devices and you can use a wireless (802.11) LAN interface to transfer data to other systems or back to a network location.  Wireless LAN interfaces can also be used for controlling your PXI systems remotely.   

So why not decouple each PXI module from a wired PXI bus and connect them using a wireless protocol?  Technically, there is no reason why you couldn’t do this.  The real question is do you really want to?  Unfortunately, the convenience of a wireless interface doesn’t come without tradeoffs in performance, setup ease-of-use, and cost.  The core benefits of PXI come from the shared card cage architecture, the high bandwidth and low latency PCI and PCI Express bus, and integrated timing and synchronization (I suppose this could also count as “wireless” since PXI eliminates the need for most external trigger and synchronization cables).  Separating each PXI module into its own separate sub-system via WiFi would dilute the benefits of PXI and significantly decrease the performance (due to increased bus latency), cost (due to dedicated fans, power supplies, and boxes per device), and synchronized measurement accuracy (due to a lack of triggering) that PXI offers in its current state compared to traditional standalone instrumentation.  You would however retain the user-defined software aspects of PXI in such a configuration which is a key component of PXI’s measurement flexibility and reuse.   

Thus, I do not feel wireless PXI in the form of discrete PXI devices connected via wireless interface is worth the effort.  However, I would agree PXI is the ideal platform for designing and testing wireless devices and that it enables higher performance, lower cost, and improved flexibility in most test and control applications today.

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.

One the biggest signs of success factors of PXI has been the increased adoption by major test and measurement vendors. Even though at times they have been hesitant to wholeheartedly support the PXI standard, Agilent, has several product lines in PXI:

•  A line of PXI-based high performance signal generators (N6030A)
• PXI digitizer modules, from their acquisition of Acqiris
• PXI Optical test instruments, form their acquisition of PXIT

Last week, Agilent released new PXI modules in their optical test product line. Their press release notes that the modules offer their customers “a smaller, faster, more cost-effective solution” - precisely the primary benefits of the PXI platform.

I came across this blog today, from a Lockheed Martin engineer that attended NI Week last week. As usual, I can’t say it any better that our users! Enjoy.

Last week was National Instrument’s annual user conference, NI Week. It has become more of a whirlwind every year, and this year set a new bar: over 2500 customers, plus members of the trade press, investors, university professors, partners, and NI employees. I’m still digesting all the feedback and takeaways, but here was my overriding impression: over the past few years, the sophistication of applications that our users have accomplished with NI tools has grown remarkably. I recall judging our application paper contest just a few years ago in the communication category and all the applications submitted were fairly straightforward GPIB-controlled test applications. Today, NI hardware and software are being used in research labs to prototype the latest communication standards, in RF chip validation testers, and in high volume production test of wireless devices. During the NI Week keynotes, we showed leading edge applications of virtual instrumentation, including a ‘mind controlled wheelchair’, a Boeing 787 audio flyover test system, multichannel video streaming, and a cryogenic medical device - all applications of LabVIEW. It really is amazing what our users our accomplishing with our tools.

I am hearing increasingly from customers and other vendors in test and measurement about the need for “Open Analysis”. The need is driven by the increasingly diverse set of applications and thus measurement requirements driven by, among other things, macro trends outlined in the book The Long Tail. As communication standards continue to proliferate, and the pace of change increases, users need tools that can adapt just as rapidly to their changing measurement needs. Instrumentation vendors such as Tektronix, for example, are increasingly offering options for users to plug in third party analysis tools, or export their data to analysis environments for custom processing. Tek’s OpenChoice is “a collection of software libraries, utilities, samples, industry-standard protocols and interfaces”. An example of OpenChoice software is SignalExpress Tektronix Edition, which is used to automate Tektronix instruments and bring data into and open, PC-based environment for further analysis. Tektronix AEs, third parties, or customers themselves can add in their own custom analysis to meet their specific application needs.

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.