The Automated Test Blog

As I stated in my last blog post, I’m planning to discuss one of three industry trends per blog entry over the next few weeks. My 2nd trend is:

Trend#2: Increased Adoption of Parallel Processing Technologies

Multicore technology has become a standard feature in automated test systems and a necessity for today’s electronic devices that are processing unprecedented amounts of data. Software-defined instrumentation takes advantage of the latest multicore processors and high-speed bus technologies to generate, capture, analyze and process the gigabytes of data required to properly design and test electronic devices. Multicore architectures can present a challenge when used with traditional text-based programming environments that are not inherently parallel and require low-level programming techniques. However, test engineers quickly can realize the benefits of multicore technology through inherently higher level programming environments such as LabVIEW, which automatically distributes multithreaded applications across multiple computing cores for maximum performance and throughput.

Many test engineers I talk to are already experiencing the challenge of programming multicore in that, for the first time, they are not seeing an increase in test system performance when updating the PC in the system. In fact, due to the potentially slower clock rates of many multicore processors, their systems may actually run slower!

On the other hand, Alejandro Torres, senior manufacturing test engineer at Sanmina-SCI, provided an example of the potential business benefits attained by using programming tools tuned for multicore technology when he stated, “By leveraging the multicore technology in LabVIEW and the latest NI multicore PXI embedded controller, we were able to increase our test throughput by one additional workday per week. Best of all, we achieved this throughput increase by simply upgrading from a previous-generation PXI single-core embedded controller to the latest NI PXI multicore embedded controller with only minimal changes to our code.”

Another area of growth for software-defined instrumentation is the increase in system-level design tools for FPGAs. Many modular instruments now come equipped with FPGAs, including several released in the past year that offer the high-performance Xilinx Virtex-5 FPGA. These FPGA-based instruments provide test engineers with the ability to implement more complex digital signal processing at faster rates than ever before. Because software programs such as LabVIEW give test engineers the ability to program FPGAs without requiring knowledge of VHDL, the performance benefits of FPGAs are no longer limited to a subset of hardware engineers with extensive knowledge in digital design.

Next week, I’ll post on the third trend, the Expansion of Wireless and Protocol-Aware Test.

Yes, its 2009 and time again to make some predictions about the technologies and trends that I think will shape our industry this year.  Of course, making predictions for the rest of this year right now is a pretty risky proposition. But, one thing I know to be true is that in a tough economy, you have to be able to do more with fewer resources. Test and measurement often comes under particular scrutiny in an economic down cycle, and test engineers will need to be prepared to optimize our approach to verification and production test, or even look at alternatives to our existing test engineering strategies

These demands have led to three major trends that I believe will significantly influence the Test and Measurement industry over the next year. Instead of blogging them all here today, I will share one per entry over the next few weeks.

Trend#1: Growth of Software-Defined Instrumentation

The adoption of software-defined instrumentation is the most significant trend in test and measurement for 2009. Software-defined instruments, also known as virtual instruments, consist of modular hardware and user-defined software that give engineers the ability to combine standard and user-defined measurements with custom data processing using common hardware components. This flexibility has become critical as electronic devices such as next-generation navigation systems and smart phones integrate diverse capabilities and rapidly adopt new communication standards. Using software-defined instruments, engineers rapidly can reconfigure their test equipment by modifying software algorithms to meet changing test requirements.

In addition, engineers are using software-defined instrumentation to achieve new levels of measurement performance and lower test costs by applying the latest technological advancements such as multicore processors and field-programmable gate arrays (FPGAs) in their test systems to meet the demands of new application areas such as wireless and protocol-aware test.

Because of the flexibility and cost-effectiveness of this approach, thousands of companies are adopting software-defined instrumentation and industry standards that build on this approach continue to grow, even in the difficult world economy.  For example, according to the PXI Systems Alliance, more than 100,000 PXI systems will be deployed by the end of 2009, and the number of deployed PXI systems is expected to double in the next decade.

Jessy Cavazos, test and measurement industry manager at Frost & Sullivan, recently confirmed that PXI is influencing this trend when she stated, “The open, modular architecture of software-defined instruments such as those in PXI have proven beneficial to a wide range of industries, and, as a result, PXI revenue in measurement and automation is expected to grow at 17.6 percent CAGR through 2014. The performance delivered by the PXI platform has successfully addressed areas such as RF applications in radar testing, mobile phone testing and other wireless applications that were previously impossible to address with other instrumentation.”

Next week, I’ll post on the second trend, the increased adotoption of parallel technologies.

In February, I wrote about the new mobile internet and how our online behavior would radically change based on the ubiquity of mobile devices with internet connectivity.  I recently read a column on MarketWatch by John Dvorak that also spoke on this subject.  In his commentary, Dvorak asserts that there will be four critical trends in the computer industry in the coming decade:

• There will be a major platform shift away from the current Wintel machine
• Mobile devices will become more and more important
• Internet connectivity will be done mostly on mobile devices, primarily the cell phone
• Cloud computing will dominate the century

Those of you that have a mobile device with elegant internet connectivity (I’m an unabashed iPhone fan myself) have no doubt witnessed this change first hand.  My PC is no longer my primary portal to the internet – I read most of my news and do nearly all my google-ing, ebay-ing, Wikipedia-ing, and now, even FaceBook-ing, on my mobile device.  I’m actually more accustomed to interacting with the internet on my phone now than I am on my computer.  And we’re really only in the second generation of the mobile internet.  Add better user interface through brighter OLED displays, more sensors, haptics so you can ‘feel’ objects on the screen (Blackberry announced one attempt at this today with their new touchscreen ‘Storm’), and broadband connection speeds through WIMAX and LTE, and imagine the capability that will be delivered on a mobile device.

Of course, since I work in the test and measurement industry, I can’t help but think about what effect this change in the consumer industry will have on ours.  For one, there is a lot of sophisticated technology on these devices to test, and the pace of innovation is only increasing.  So, design and test engineers need rapid development platforms that can adapt to these changes faster than ever.  I believe that this trend will affect our industry in an even more profound way as well.  Today, the PC is the primary business machine – it is our data storage hub, our desktop publisher, our presentation aid, our engineering design workstation, and our business dashboard.  As mobile computing and internet devices become pervasive in everyday life, how is this likely to change?  What will cloud computing mean to the engineering community?  This is a subject I’ll be thinking a lot about and plan to share some thoughts on in a later blog. 

But for now, I need to get back to the internet to do some research on wireless standards.  And, since I’m writing this on my laptop, that means time to shut down my PC and pick up my iPhone!

Wireless mobile devices will fundamentally change the way we use and interact with the Internet. As I’ve posted before, I am a unabashed iPhone user. And I’ve started to notice some curious things about my use of the Internet now that its with me all the time and easily accessible. For one, my Internet usage has gone up by an order of magnitude. I don’t think I’m exaggerating - I literally mean 10x. And let’s be clear, I was already a heavy Internet user. Now I use it 10 times more. This also means I access the Internet on my phone at least 10 times more than I do on my PC. I’ve grown so accustomed to the device that I find myself surfing the web on it while sitting in front of my laptop. I have also noticed that my expectations for Internet content has changed. For example, my expectation for real time content has gone up dramitically. I check news sites like cnn.com several times each hour and expect news updates. No new headlines in the last 20 minutes? Maybe I should try another site. I also notice that I use the device to augment my own knowledge on the fly by searching acronyms, names, etc., while in conversation or in a meeting. I don’t think I’m at all alone in this trend: Google recently reported that 50 times more traffic from iPhone users than from other mobile devices. Think about that - 50 times! When you make a tool like Google more accessible, dramatic things can happen. I’ve also talked to several colleagues (NI has a density of iPhone users that I doubt is topped anywhere outside of Cupertino), and they report a similar phenomena.

So, the question is, what is driving this change? I think first and foremost, we’re starting to really see the impact of ubiquitous wireless connectivity. The iPhone happened to make the full Internet available in way that is as good or better than the experience on the PC. Once the Internet makes the jump to wireless devices, the dynamic of the Internet will really change. The PC will quickly become irrelevant as an Internet device - the number of mobile devices (>1 billion per year) dwarfs the number of PCs (about 250 million per year). As Bolaji Ojo of EEtimes recently stated in his article Wireless is everywhere, ignore it at your peril, “the search is over for the next killer app…it is wireless”.

As an extension of my own personal iPhone observations, I think the new wireless Internet will have some of the following attributes:

• Usage an order of magnitude greater than the current web;
• Significantly increased demand for real time information;
• A two way communication portal, not just an information source (Web 2.0);
• Optimized primarily for mobile devices, not PCs.

It will get even more interesting as the wireless data bandwidth explodes with standards such as WiMAX and LTE. 2008 should be a fascinating year for wireless, particularly, the wireless Internet.

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.

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.

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.

I just saw another example of what we call a VBA, a “van-based acquisition”. It turns out that in RF applications, virtual instrumentation is particularly common when customers need portability and real-time data streaming. There aren’t a lot of commercial products to solve this application, but a PXI-based system can handle most of these requirements at a very low cost. Here is the latest example I just received of a VBA:

“The customer was looking for a completely mobile RF spectral monitoring application. They want to have a DC-based system mounted in their vehicles and they want to drive through areas and monitor a band of secure radio channels and signal strengths for those channels. The main requirements of the system are portability, quick spectral acquisition and storage (stream-to-disk) and time/location stamping for each spectral sweep.

This is a unique application that requires a small form-factor, stream-to-disk capabilities and GPS stamping. It can solved today with commercial off the shelf PXI products”

Other PXI-based VBAs are deployed in military applications (either looking for “signals of interest” or jamming them), ground-based transceiver testers, commercial spectral monitoring systems, and cell-phone coverage mapping applications.