ROM Emulation Provides Functional Testing

You can substitute an emulator pod for a microprocessor-based PCB's boot ROM to avoid the drawbacks of hot-mock-up tests and the time and expense of implementing built-in-test techniques.

Jim McBride, LXE, Norcross, GA -- Test & Measurement World, 6/1/2000

Traditional methods for testing microprocessor boards include hot-mock-up (HMU) and built-in-test (BIT). HMU testing is the easiest to implement—you place the microprocessor board into the end system and verify that it works. HMU test, however, provides little in the way of diagnostic capability. BIT, which uses hardware and software designed into the board itself, is a powerful technique for functional test.

In a typical implementation, designers place BIT software in nonvolatile memory on the microprocessor board; then, during test, a technician places a jumper on the board to initiate the test sequence. You gain access to test results and diagnostic information through a serial port. The drawback of BIT is that it requires a significant investment in hardware and software engineering during a PCB’s design.

What Is ROM Emulation?
As an alternative, you might consider ROM emulation, an easy-to-implement method for testing microprocessor boards. During test, an emulator pod containing memory replaces the UUT’s boot ROM. You load a monitor program for the target processor into the emulator memory, and the monitor program runs when you boot the UUT.

The monitor program acts as an interface between the test program, written in a high-level language, and the emulator, which passes commands to the UUT microprocessor. The result is that the test engineer can control the microprocessor on the UUT through a test program written in a high-level language.

ROM emulation offers several advantages over other test methods:

• Emulation is conceptually simple. The emulator is basically a passive device that simply waits for the UUT’s microprocessor to fetch
commands.

• Emulation tests a UUT at full speed.

• UUT synchronization is automatic because the UUT microprocessor fetches commands from the emulator under the microprocessor’s own timing control.

Note that ROM emulators designed for testing differ from the traditional ROM emulators used for software development. Traditional ROM emulators run assembly code written by software developers for embedded applications; developers don’t need to burn new ROMs every time they change a line of code. Traditional emulators also provide breakpoints and other tools to assist engineers in debugging code. In contrast, the test ROM emulator is specifically designed to enable test engineers to test microprocessor boards.

The main difference is that the test ROM emulator uses a simple high-level command set rather than assembly-language commands. Emulator manufacturers (see “Representative Vendors of Test Equipment Having ROM Emulation Capabilities ”) write software drivers for each microprocessor type they support to translate between some high-level command set and the target microprocessor’s assembly language. Therefore, you can write test programs for many types of microprocessors using a supported high-level command set, thus eliminating the need to become proficient in the assembly language of each type of microprocessor you might encounter.

Command Sets for ROM Emulators
Typical high-level command sets for ROM emulators contain the commands necessary to access memory and I/O ports on the UUT:

• write I/O,
• read I/O,
• write memory, and
• read memory.

In addition, the sets usually contain more complex commands designed to make the test engineer’s job easier:

• RAM test. This command performs a full-cell memory test of the UUT RAM.
• ROM checksum. This command is used to evaluate a checksum for any ROMs on the UUT.

Other diagnostic commands assist in troubleshooting kernel faults. These commands are particularly useful for isolating failures in boards that won’t boot:

• Bus test. This command forces data onto the UUT data bus to ensure that none of the bus lines are shorted or stuck. It runs before the UUT boots.
• Address trace. This command sets up the emulator to record each address from which the microprocessor fetches data or instructions during the boot sequence and helps to find address-bus faults.
• Chip-select detect . This command determines if the ROM received a chip-select signal during boot.

Most test ROM emulators can also run assembly-language code, a capability that’s necessary if a UUT must perform a real-time function that will not tolerate the delays inherent in high-level-language programs. Also, you can use assembly-language routines to perform complex UUT setups that would be time-consuming with high-level routines. To do this, you can often simply copy and reuse the setup code from the UUT’s boot ROM.

For the UUT to run the assembly code, the code must be placed in the UUT’s memory map. You can copy the code to the UUT’s RAM or to a user area in the emulator memory that resides in the UUT’s ROM’s address space.

a)

b)

Figure 1. (a) A test ROM emulator (left) connects to a UUT (bottom) via the UUTs boot-ROM socket and reset and ground test points. (b) The emulator can become part of a complete board-test ATE system.

Figure 2. If your UUT’s ROM is soldered to the UUT, you must ensure that the PCB designers provide a means of temporarily routing the onboard ROM’s chip-select signal to the test emulator.

Figure 3. The board represented by this block diagram lends itself to a step-by-step test procedure in which a test emulator applies test signals in accordance with the board’s I/O- and memory-map values.

Alternatively, you can place a jump command as the last line in the assembly code, so processing will begin at the entry point of the ROM emulator’s monitor program. In this way, the emulator regains control of the UUT without the need to reboot the system.

Connecting the ROM Emulator to a UUT
An additional advantage of ROM-emulation-based testing is that it requires few modifications to the UUT. You’ll need to connect the ROM emulator to the UUT ROM and the UUT reset and ground lines. Typically, the ROM emulator pod plugs into the UUT ROM socket, and test points or a test connector can provide external access to the UUT reset and ground lines (Fig. 1).

Things get slightly more complicated when the UUT ROM (often a flash device) is soldered on the board. In this case, board designers must add a test connector (or test points) to the UUT to provide access to the ROM signals. They also must add a gate and control line to disconnect the chip-enable (CE) line from the onboard ROM and route it to the test connector. A typical solution is to bring all the ROM signals out to test pads and access them through a Pogo-pin interface (Fig. 2).

ROM Emulation for Functional Test
When developing a functional test using ROM emulation, a test engineer must look at the UUT from the viewpoint of a software developer. The UUT is divided into functional blocks that are accessed through the memory and I/O maps. The ROM emulator reads from and writes to each device through each device’s memory or I/O interface.

Figure 3 is a block diagram for a microprocessor board that is to be tested using ROM emulation; the figure also shows the UUT’s I/O and memory map. “A Sample Test Plan,” p. 68, shows a basic functional test plan for this board. This test plan provides a comprehensive test of the UUT and is straightforward and easy for you to develop using ROM emulation.

Integrating ROM Emulation with ATE
When selecting a ROM emulator, consider how you will integrate it into your testing environment. Emulators are available in three basic varieties:

• Stand-alone ROM emulators are available as a complete system for microprocessor board testing. These turnkey units are easy to use, but they do not integrate easily into ATE systems.

• ROM emulators are available as options with some commercial in-circuit/ functional testers. These units are well integrated as a part of a complete ATE system.

• ROM emulators are available as separate instruments with a standard interface bus such as ISA or PCI card. These units are designed for you to integrate into an ATE environment. They come with DLLs or instrument drivers so they can be accessed through standard, high-level programming languages (or test environments) such as C, VisualBasic, LabView, or ATEasy.

Emulator Features
In addition to the basic command set, there are other features you should consider when choosing a ROM emulator:

• Make sure the emulator will support a range of microprocessors. Changing to a new microprocessor should require only a software update.

• Make sure the emulator supports a variety of ROM sizes and form factors such as DIP or PLCC packages. Ideally, you can use the same emulator pod with any package type with only a cable change.

Although used primarily to test microprocessor boards, ROM emulation can also be used to test peripheral boards designed to plug into microprocessor boards. You plug the peripheral board into the host microprocessor board, which becomes part of the test fixture. The ROM emulator then connects to the host microprocessor board and tests the peripheral board by performing read/writes to control it.

ROM emulation is a powerful technique for functional testing of microprocessor and microprocessor peripheral boards. It is an easy-to- implement, comprehensive, and elegant test method that you should consider whenever you must develop tests for microprocessor boards. T&MW

Jim McBride is a test engineer at LXE, Norcross, GA, working in product development for wireless data-communications equipment. He holds a B.S. degree in physics from Georgia State University and is currently working on an M.S.E.E degree at Mercer University.
E-mail: mcbride_j@LXE.com.