The Automated Test Blog

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.