Test engineers often are challenged with the task of simulating the environment in which the unit under test (UUT) will operate. To implement such a test, engineers use hot mock-up, embedded software, or bus emulation.
Hot mock-up is the easiest and most frequently used test approach. In a PC, for example, an untested card or assembly may be plugged in to replace a working unit of the same type. Although the hot mock-up is a relatively low-cost solution, it is time-consuming to maintain and requires a high level of troubleshooting skills.
The embedded software approach builds on the hot mock-up test. If properly designed with built-in self-test (BIST), embedded software can provide a viable solution for functionally testing products in a hot mock-up environment.
Bus emulation is based on the premise that the UUT doesn’t need to be in its real-life environment to test its functionality. The bus emulation test can easily be designed to aid in the fault-isolation process and characterize the UUT during the design phase. Paired with the right digital I/O hardware and software, bus emulation can provide powerful, cost-effective tools that can easily meet just about any test requirement.
The UUT
As an example of how bus emulation and digital I/O hardware and software provide results, consider a test engineer that must migrate hot mock-up testing of a VME bus product to an off-the-shelf test system. In this example, the product is an analog I/O card with an onboard microprocessor.
The product consists of 16 analog output channels that can be programmed between -10 VDC and +10 VDC. There are 32 analog input channels that can be programmed for bipolar or unipolar operation. Communications between the product and the VME bus are accomplished through a dual-ported RAM.
The UUT onboard processor completes its BIST on power-up and monitors the VME bus for receipt of a valid command. The command set consists of setting the channel mode and actual voltage for one of the 16 analog output channels. The UUT also supports reading back a channel conversion for one of 32 analog input channels.
A status command provides information about a specific channel or results from the previous command. The VME-based UUT in this example does not support interrupt bus cycles, which limits emulation to 16-b data read and write bus cycles.
Defining the Test System
The scope of this project is to perform calibration of the analog section and verify analog accuracy as a final test prior to shipment. As with many projects, budgetary constraints are a concern.
The first challenges to overcome are testing at VME bus speeds and communicating with the onboard microprocessor. The UUT requires constant communications with the onboard microprocessor to service or “pet” a watchdog timer circuit; the analog I/O channels reset to zero if the watchdog times out.
To meet these requirements, a digital I/O card system such as Geotest’s GT50 that runs independently from the test system’s host processor is needed. A switching matrix, precision DC source, and a 6.5-digit DMM complete the test system (Figure 1).
Bus emulators and digital I/O test instruments require timing sets and pattern tables. Many digital I/O products support the creation of timing sets and pattern tables using graphical development tools.
Digital simulators can provide pattern tables along with other simulation information. In this example, however, project funding limits full simulation test-vector development.
As for the graphical development tools, many of the available graphical state-table editors are adequate for entering small data patterns or debugging files after import. Entering large patterns is time-consuming and prone to errors because the user must draw the digital stimulus provided by the digital I/O instruments for each bus cycle that makes up the test.
The GT50 digital I/O card comes with a software support package, DIOEasy, which provides a graphical state-table editor for development of pattern tables. Through the use of the instrument software front panel or virtual panel, the test engineer can develop pattern tables in an iterative fashion, loading and saving the patterns into the graphical editor.
This instrument also leverages the power of the Windows Component Object Model (COM), allowing the engineer to create vector files for bus emulation by using COM object scripts in the form of VBScript files. This eliminates graphical-based tools.
These scripting files allow complex measurements to be programmed and debugged quickly. For example, channel setting, status checking, and read-back command cycles can be quite detailed, especially when more than 512 measurements must be made.
The COM integration supports re-use of individual patterns of tables that represent each bus cycle within the test. Each test pattern can be written once, then looped across any number of channels. A change in the test pattern is immediately available to all other tests that reference the test pattern.
Bus Emulation-Based Test
The code excerpts in Figure 2 are examples of what can be developed to abstract low-level commands with the COM language. Using the COM language, a compiler for this digital I/O card was designed to interpret commands that get turned into the actual timing sets required for the digital I/O card.
First, it was necessary to define and map the pins of the digital I/O card to the actual signal names connected to the UUT. These names then can be referenced in the code that will generate the instrument’s timing sets.
The VME Write Bus Cycle routine in Figure 3 corresponds to the timing diagram in Figure 2, where each command line basically represents a single vector state. For each clock period, the states of the data and address buses, the write (WR) and data acknowledgement (DTACK) lines, and the DS0 and DS1 data-strobe lines comprise a test vector.
The vectors are issued at the rate specified by the clock statement. In this case, the VME Write Bus Cycle specifications are generated by setting the appropriate I/O pins to the desired states as illustrated in Figure 2. If the graphical editor method were used, it would be necessary to draw the bus cycles for as many times as required to complete the test routine.
Now that a VME Write Bus Cycle routine has been created, the main routine (CHANNEL Ramp) can call it each time a write cycle must be performed. This example initiates a typical analog output test consisting of setting the channel’s parameters, waiting for the scanner and DMM to be connected to the channel, and reading the channel’s output.
The calling test program then can evaluate the test results. This routine is repeated for each channel as the outputs are ramped to test the linearity of the selected range. Based on this coding method, a robust and complex test program can be generated and implemented in a short period of time.
Conclusion
Leveraging COM support with the selected dynamic digital I/O card reduces the development effort required when compared with the graphical programming method. The use of commercial off-the-shelf test instruments allows the migration from a decaying hot mock-up test bed to a test system that is easily scalable to address future test needs.
About the Author
Juan Rivera is the customer technical services supervisor for Geotest-Marvin Test Systems. He has more than 20 years in the electronics industry, working with companies such as Intel, Fluke, and GenRad as a senior test/applications engineer. Mr. Rivera is a Devry graduate. Geotest-Marvin Test Systems, 17570 Cartwright Rd., Irvine, CA 92614, 949-263-2222, e-mail: [email protected]
FOR MORE INFORMATION
on emulation techniques enter this rsleads URL
www.rsleads.com/304ee-202
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2003 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
April 2003