Testing electronic designs that include microprocessors and microcontrollers has always presented a challenge. Often, bus emulation is perceived as the only valid way to verify the operation of a bus.
But this is not necessarily so. While it is true that bus emulation controls a bus in a manner similar to the actual device, bus emulation often cannot accurately reproduce the timing relationships of the signals associated with the bus.
Motorola Bus Overview
The Motorola microprocessor bus provides a good example. It has been around for many years and is well understood. The same basic structure is used on many buses including 68000 series microprocessors and the VME and VXI buses.
Figure 1 shows a simplified diagram of a write cycle on the Motorola bus sans clock and timing information. The basic sequence for performing a write cycle is as follows:
- Assert a valid address on the address bus.
- Assert the Address Strobe*.
- Assert R/W* to the “write” state.
- Assert valid data on the data bus.
- Assert the Data Strobe(s)*.
- Wait for data acknowledgement from the device being addressed.
- Release the Address Strobe*.
- Release the Data Strobe(s)*.
- Release the R/W*.
- Wait for data acknowledgement to be released from the addressed device.
- Release the data bus.
- Release the address bus.
One of the great features of this type of bus cycle is the handshaking between the data strobe and the data acknowledge (DTACK*). Having the hardware step through a bus cycle, by setting states on control lines and then monitoring for corresponding responses to those states, allows asynchronous devices to communicate on the same bus. It guarantees that any device, no matter how slow (within the time-out limits of the bus), can receive and send data to the controlling processor.
Performance Testing
For performance testing, it is not necessary to wait for a signal before acting. You only need to test for the presence of the appropriate condition.
A step common to any test philosophy is understanding the parameters of the device being tested. This includes the timing characteristics of the device, such as the minimum and maximum data acknowledge response time. By understanding the critical timing characteristics of your device, you can create a test scenario that assumes the timing is being met and tests for the signal at the critical time.
The goal is to identify violations on the bus. The capability to compare and record an input signal, in this case DTACK*, but not wait on the signal meets that goal. If your tester can program the timing characteristics of the output signals and the sample strobe on the input side, the integrity of a bus can be verified, and the devices on the bus can be tested. The finer the resolution of the output timing and the sample timing, the closer you can get to providing the actual timing of the unit-under-test using the tester.
Why Not Bus Emulation
Simply stated, bus emulation seeks to mimic the control a microprocessor has on a bus to exercise or test devices or peripherals connected to the bus. In the Motorola bus example, a traditional bus emulator drives the appropriate signals to their proper states during steps 1 to 5. Then it waits for data acknowledgement at step 6, after which it releases or de-asserts the appropriate signals in steps 7 to 9.
Again, it waits for DTACK* to be released in step 10, after which it releases the address and data buses to complete the cycle. Many engineers would strictly follow this process to perform a valid test of any device on the bus.
There are two problems with this position. First, the goal of testing is to verify integrity of the bus, usually by checking operation of devices on the bus. The intent is not to mimic the microprocessor that controls the bus, per se. It is possible—in fact, sometimes preferable—not to emulate the process the microprocessor uses to perform data transfers.
The second problem concerns the architecture of the tester itself. A common method used in high-speed digital designs pipelines logic stages. This is true for all high-end microprocessors and complex high-speed digital designs and often for the digital subsystems found in ATE.
While pipelines allow high-speed designs to function in a predictable, synchronous manner, these also introduce latency. Latency is the delay associated with clocking a logic state through the pipeline. Bus emulation runs head-on into latency issues when attempting to mimic a microprocessor. In fact, latency often becomes the limiting factor in determining how quickly a device or test instrument can react to external stimuli.
In Figure 2, for example, the tester is programmed to wait for the data acknowledge (DTACK*) to go to a particular state. Upon detection of that state, the control section is programmed to change the output states, which completes a portion of a handshake cycle. While DTACK* is in the invalid state, the program is essentially paused.
When DTACK* transitions to the valid state, it takes three clock cycles for the control section to recognize the state change and act on it. This is due to the pipeline architecture.
If you assume that the tester is running at a 25-MHz data rate (40-ns clock period), then it would require 120 ns minimum to detect a state change on the DTACK* input. And if the output stage had a similar pipeline structure with similar latencies, then it would need 240 ns for the output to actually change state in response to DTACK* changing state.
A typical response time for the Motorola bus, depending on the clock frequency of the processor, is tens of nanoseconds. This demonstrates, due in part to system latencies, that if you mimic the process of the microprocessor by monitoring the DTACK* input and waiting for an input state change prior to changing output states, you will not faithfully reproduce the system timing. In performance testing circumstances where the desire is to test a device in an environment where the timing of the tester closely matches actual system timing, bus emulation falls short.
Performance Test Example
Here is an example of how performance testing can verify the integrity of the bus while maintaining near ideal system timing. Assume your design analysis concludes that DTACK* should become active 30 ns after your data strobes go active and inactive 150 ns after the data strobes go inactive.
This information could be obtained by examining design documents, such as the timing specifications of the microprocessor, or taking measurements of the circuit under actual operation. Either way, once the timing characteristics of the circuit are known, you can create a test program that accurately reproduces the system timing, tests for the presence of DTACK* at the critical time, and flags any violations. Figure 3 illustrates this process.
Using the real-time compare feature available in digital test instruments, the state of the DTACK* signal can be tested at any point during the time indicated. Alternatively, using a window compare feature, DTACK* can be tested for the duration of the valid portion of the bus cycle.
To verify that DTACK* is not stuck low, a cycle can be generated so the data strobes are not set to their valid states. In response, the DTACK* itself should never go valid. This is easy to test using real-time compare.
It is equally easy to access an invalid address and verify that DTACK* remains inactive. Using this approach, great flexibility is achieved without significantly altering ideal bus timing parameters.
Summary
While bus emulation is good for functionally controlling or exercising devices on a microprocessor bus, it is not always the best approach. Figure 3 may indicate a bus cycle that is 250-ns to 350-ns long. Under the latency conditions discussed, bus emulation may distort that bus cycle to 800 ns or more. If performance testing is called for (functional testing while maintaining actual system timing characteristics), a tester with a real-time compare capability, high-precision control of the output timing parameters, and the same level of control for the sample timing is required.
About the Author
Dale Johnson is the product manager at Interface Technology. He has been employed by the company for 20 years, during which time he has held the positions of production technician, service manager, applications engineer, and sales manager. Interface Technology, 300 S. Lemon Creek Dr., Walnut, CA 91789, 909-595-6030, e-mail: [email protected].
Published by EE-Evaluation Engineering
All contents © 2000 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
October 2000