Onboard processors crunch analog signals

You can choose PC-based analog data-acquisition boards that incorporate DSPs or Intel-based processors, but you can also rely on the host PC for computational tasks.

Rick Nelson, Senior Technical Editor -- Test & Measurement World, 6/1/2001

Undoubtedly, today’s near-gigahertz-rate Pentium-class chips have the power to take on the processing chores required for most PC-based analog data-acquisition tasks. But considerations beyond raw power may dictate whether you can afford to allocate host processing power to the computations your data-acquisition applications require. You’ll want to consider host-processor overhead, of course, but you’ll also want to consider the amount of bus traffic your application will develop as well as your ability to precisely time analog data I/O operations.

There are three reasons you might choose a data-acquisition board with an onboard processor, says Ed Kruft, product manager at National Instruments:

• Data reduction. Constant flow of low-level data-acquisition transactions can clog even high-speed PCI and CompactPCI buses, and the problems could become more severe if you design a data-acquisition system that employs a serial bus like the USB.

•  Determinism. A multitasking host operating system can’t reliably provide guaranteed real-time response in critical closed-loop control applications; a real-time operating system running on a processor dedicated to acquisition can.

•  Reliability. A self-contained application running on a processor-based board can remain immune from hardware and software errors elsewhere in a system.

Figure 1. A 60-MHz floating-point DSP handles processing chores on Innovative Integration’s ADC64 data-acquisition board, which includes eight multiplexed 16-bit, 200-kHz analog input channels. Courtesy of Innovative Integration.

To achieve any of these goals, you can choose from among a variety of processor-based analog data-acquisition boards. Datel’s PCI-431 includes a Texas Instruments 50-MHz TMS320C44 floating-point DSP to process data from its four 12-bit, 10-MHz ADC channels. Innovative Integration’s ADC64 Series boards (Figure 1), with versions available for the PCI and CompactPCI buses, each employ a 60-MHz TI floating-point TMS320C32 DSP to handle processing chores associated with each board’s eight multiplexed 16-bit, 200-kHz analog input channels.

Microstar Laboratories employs a 96-MHz Intel 80486 processor to manage its iDSC 1816 board’s 16-bit, 8-channel, 153.6-ksample/s acquisition operations. The company uses an AMD 400-MHz K6-III+ processor for its DAP 5200a, which acquires 14-bit analog data at 1.66 Msamples/s.

If you need to augment your host PC’s processor with a processor dedicated to analog I/O, you have an alternative to onboard processors—you can add a separate processor card to your analog data-acquisition system’s PC bus. Or, if you don’t want to tie up the bus with data-acquisition transactions, you can choose a board such as Signatec’s PDA500 500-MHz digitizer, which can communicate with DSP-based boards via a proprietary bus.

Gespac offers CompactPCI DSP boards employing dual 200-MHz Texas Instruments TMS320C6201 fixed-point processors running WindRiver Systems software; you can add PC-MIP analog-I/O mezzanine cards to turn the boards into intelligent data-acquisition subsystems. (For the telephone numbers and Web addresses of the companies mentioned in this article, see below.)

Figure 2. Able to acquire five 8-bit Gsamples/s, Gage Applied’s CompuScope 85G offers a 500-MHz analog-input bandwidth. The board’s fast-in slow-out (FISO) sampling technology relies on onboard DSP circuitry to provide error correction. Courtesy of Gage Applied.

The most straightforward approach, though, is to choose an analog data-acquisition board that already includes the necessary processing power. Processor-based boards run the gamut of speeds—from the 25-sample/s PCI-DAS-TC 16-channel thermocouple board from Measurement Computing to the 5-Gsample/s CompuScope 85G waveform digitizer from Gage Applied (Figure 2).

These two boards don’t expose onboard processor details to users. The Measurement Computing board uses its processing smarts to convert thermocouple outputs to °C or °F values that it presents to the host processor. Gage Applied’s CompuScope 85G uses a custom DSP-based ASIC to apply error correction based on calibration data stored on board.

Many companies, however, do provide various levels of access to onboard processing power. Onboard processing options include DSPs from Analog Devices, Motorola, and Texas Instruments as well as standard AMD and Intel processors. The level of processor access that board manufacturers offer to these processors ranges from vendor-packaged libraries of predefined functions to complete development packages supporting low-level-language development.

The specific type of processor included in a board will be of secondary significance, unless you have expertise developing code for a particular processor family. What’s important is how the board manufacturer uses the device. Various factors can enter into a manufacturer’s decision to choose a particular part. Of course, the processor’s clock rate must be sufficient to handle calculations at the board’s rated throughput. Similarly, its bus width must be sufficient for performing calculations on the acquired data. A fixed-point DSP serving a 16-bit application would, as a rule of thumb, need to be 24 bits wide to accommodate intermediate results.

Other considerations can be more prosaic—price and availability at the time of selection, for example, or a designer’s preference for a particular package style. Alex Ivchenko, engineering manager at United Electronic Industries (UEI), says one reason he chose a Motorola DSP was because the part comes integrated with a PCI interface and therefore would save real estate on his firm’s PCI boards.

Registers or commands

Ivchenko explains that host PCs can interact with analog-I/O boards in one of two ways: If the board does not have an onboard processor, the host treats the board as a register. In this scenario, read/write operations can eat up as many as 10 clock cycles on the PCI bus as host driver software executes loops waiting for hardware to catch up.

But if an analog-I/O board has an onboard processor, the host can use high-level commands to communicate with it. Thus, a host can transmit a single high-level command over the PCI bus, to which the I/O board can respond with a series of complex computations without further host intervention.

UEI’s PowerDAQ boards, for example, can implement complete closed-loop PID (proportional integral and differential) control systems without host intervention. They incorporate 66-MHz Motorola 56301 DSPs to handle I/O-related computations and housekeeping chores associated with PowerDAQ boards’ acquisition of 64 single-ended analog inputs and generation of dual analog outputs, while also controlling up to 32 digital I/O lines plus three counter/timers.

Of course, adding DSPs to your data-acquisition system complicates software development. Code that runs on a host’s processor won’t run on DSPs. UEI offers a software suite that interfaces PC-based programming tools such as Agilent VEE or National Instruments’ LabView to the PowerDAQ board.

The PowerDAQ software suite makes it unnecessary for you to master the details of DSP programming. If you want more control over the DSP than the software suite affords, you can purchase a development kit from Motorola; you can upload the code you develop into a PowerDAQ board’s 4-kword memory.

A decade ago, National Instruments began offering data-acquisition boards with onboard DSPs from AT&T (now Agere Systems, Allentown, PA). Unlike UEI, which suggests its customers go directly to the DSP manufacturer for development support, National Instruments resold AT&T’s software-development kit to its DSP-based board customers. With that approach, though, NI’s engineers found themselves too involved in supporting customers struggling with DSP development details, according to National Instruments’ Kruft. In its latest offerings—Models 4551 and 4552 data-acquisition boards for sound and vibration applications—the company has done the development work for you, offering a library of functions that run on the onboard Analog Devices’ Sharc DSPs.

Figure 3. You get a choice of onboard or off-board processors with National Instruments’ data-acquisition boards. Shown here are digital I/O boards coupled with processor boards in real-time configurations. The company also offers analog I/O versions.

If you want to implement functions that aren’t included in the 4551/4552 libraries, you can buy versions without the onboard Sharc processors and team them up with Pentium-based processor boards running the Phar Lap (now part of VenturCom) real-time operating system plus a real-time version of LabView (Figure 3).

Real-time performance

A key area in which onboard processors can aid data-acquisition chores is in real-time performance. Pentium processors are certainly capable of keeping up with onboard DSPs for most processing chores.

A 933-MHz Pentium can probably out-race a 66-MHz DSP on any number-crunching task. What a host Pentium running under Windows can’t do, however, is guarantee real-time response. If you need microsecond or even millisecond resolution to control timing of your I/O operations, you’ll need to add real-time operation to your system.

Real-time operation doesn’t demand that an I/O board include an onboard processor. You can add a real-time operating system to your host PC, such as a real-time version of Linux or commercial operating systems from Phar Lap, QNX, or WindRiver Systems. Unless you can dedicate the host to your data-acquisition application, however, you can experience performance hits as non-real-time Windows tasks remain prepared to be preempted by real-time operations.

Software choices

Most data-acquisition boards come with drivers that let you develop your applications from within graphical environments like LabView and VEE. As mentioned earlier, some board vendors provide programming access to onboard DSPs. To program Motorola DSPs, you can use Motorola’s Suite 56 software, which includes an assembler, linker, and debugger; WindRiver Systems’ Tornado adds a C compiler and profiler for Motorola devices.

For TI DSPs, the eXpressDSP Real-Time contains several components: standard DSP algorithms that ensure application interoperability among TI’s TMS320 family of DSPs, the Code Composer Studio IDE development environment, and the DSP/BIOS real-time scalable kernel. Also included are simulation and emulation tools that let you use a PC to create, optimize, and debug software for your target device.

Figure 4. The graphical programming approach of Hyperception’s Hypersignal RIDE development platform can ease software design for DSP-based data-acquisition boards. Courtesy of Hyperception.

You can also choose a third-party development environment. Hyperception’s Hypersignal RIDE (Real-time Integrated Development Environment), for example, brings drag-and-drop DSP programming (Figure 4) to boards such as Datel’s PCI-431. Hypersignal RIDE can implement a variety of signal-processing functions, including octave analysis, FFTs, and various filters.

As host processor speeds and memory capacities continue to increase, you might find that it’s increasingly attractive to rely on host native-mode processing capability rather than on dedicated data-acquisition processors. Nonetheless, intelligent analog data-acquisition boards will continue to remain available to offer reliable performance for time-critical analog-I/O tasks that you don’t want to trust to a Windows environment. T&MW

Rick Nelson received a BSEE degree from Penn State University. He has six years experience designing electronic industrial-control systems. A member of the IEEE, he has served as the managing editor of EDN, and he became a senior technical editor at T&MW in 1998. E-mail: rnelson@tmworld.com.

Talkback

We would love your feedback!

Post a comment

» VIEW ALL TALKBACK THREADS

Related Content

• Topics
• Author

Related Content

 

By This Author

• Quality and responsibility
• Affordable ATE: from lab to fab
• Tools manage PCB design and test
• Competing and consorting
• PCB test: nails or TAP?
• » MORE

Sponsored Links