Answers to Interesting Emulation Questions
The first emulators weren’t intended for testing hardware. They were engineered for developing software, such as the Intel Microprocessor Development Station. It didn’t take companies long to realize, though, that emulation also works for hardware verification and troubleshooting.
Three types of emulation exist: in-circuit, ROM and bus-cycle. For in-circuit emulation, the UUT’s processor is replaced by a “hardware pod” with a processor from the tester that emulates the UUT’s processor.
With ROM emulation, the tester takes the place of the UUT’s ROM. The UUT’s processor executes tests written in the native language of that processor, directed from program information supplied by the tester.
In bus-cycle emulation, the UUT’s processor is removed or disabled and the tester emulates the bus cycle so the board thinks a processor is present. Bus-cycle emulation can be conducted on boards that have processors or on peripheral boards that are bus-based but have no processor.
How Does Emulation Work?
Digital test, like anything else, involves effective communication. To assure product quality, you must communicate with the product while it is being tested.
Digital products communicate via bus transactions. Emulation provides the test programmer with the capability to speak the product’s language. By emulating the timing operations (bus transactions) that the product uses during normal operation, a tester can communicate with everything connected to the bus. By segmenting this communication, talking with one hardware device at a time, failures can be centralized to specific circuits on the board.
In many ways, an emulation tester is just like a bus analyzer. Most bus analyzers allow you to be a master, slave or monitor for bus communications. Single-purpose bus analyzers speak the language of a specific interface bus. Emulation allows you to speak the language of the internal communications bus on your board.
Emulation is as easy as making a phone call. Digital products communicate and function very much like a phone system. Digital buses have six type of signals:
· Address Lines: Indicate the phone number you are calling.
· Data Lines: Carry the message you wish to leave or receive.
· Control Lines: Determine who is doing the talking.
· Ready or Dtack: Equates to the party you’re calling picking up, and indicates that communication has taken place.
· Arbitration: Deals with the fact that the phone (bus) is a party line and other callers can use it.
· Interrupt: Is the equivalent of call waiting.
Only one transaction can take place at a time. Even with pipelined architecture, to avoid bus contention, the bus lines must be driven by only one device at a time.
What Are the Functions of a Kernel?
A microprocessor kernel can be compared to the basic capability to make a phone call. For example, picking up the phone equates to the reset is OK and the clock is running. If you receive a dial tone translates into Dtack/Ready and the control lines are OK.
Continuing in the analogy, if you can call a valid number, it means the address bus is OK. If you can send and receive, the data and control lines are OK. If you reach the right party, the address decoding is OK. And if the party you call can pick up, the Dtack/Ready circuits are working.
Communication with the product-under-test is critical for testing digital products. Emulation provides the tools needed for effective communication.
When Can Emulation Be Used?
Emulation should be considered any time your product includes microprocessors or digital peripherals. Emulation is the quickest way to get a comprehensive performance test up and running.
Product test often delays new-product introduction. Test bottlenecks can cause large work-in-process inventories to pile up, delaying product shipment. Functional testing with emulation offers a way to solve these problems efficiently.
Most companies use some form of hot-mockup performance testing. If they are building a computer board, they simply put the UUT in the computer to see if it works. Hot-mockup testing can often detect bad boards, but this method offers little help in determining how to fix boards that fail.
Why Use Emulation?
· Test Access: Surface-mount or coated boards render in-circuit test methods ineffective. Using emulation, a board’s internal circuitry can be tested from the board’s edge connectors.
· Test Integrity: The interface between the tester and the UUT is consistent with the board’s electrical design parameters. With emulation, back-driving or forced stimulus is avoided, improving correlation and fault coverage.
· Test Development Time: Emulation speeds test development and provides the test developer with tools to find out how the product really works. Emulation test debugging can be performed interactively, which allows a developer to gauge the validity and stability of each test.
· Test Time: A board can be completely tested using emulation in much less time than a hot mockup because emulation provides a more tightly controlled test flow. With emulation, I/O circuitry can be verified in less than 1 ms. A test programmer can also use emulation to eliminate the UUT’s I/O debounce software delays.
· Diagnostics: Most hot mockups offer no diagnostics. Even if boards include self-test or diagnostic circuitry, emulation is needed to verify that the circuits designed to detect failures are working properly.
Most bus-based systems have watchdog or computer-operating-properly circuits. If these circuits fail, good diagnostic information would not be available without using emulation or some other independent form of verification.
· Product Characterization: Excessive field failures often require the development of performance characterization tests. Some of these tests are related to empirical time-margin observations and simulation of illegal bus operations or time-out conditions.
Most hot mockups are go, no-go-oriented and do not allow the fine adjustment of test parameters needed for in-depth characterization or margin testing. Testing with emulation offers more control of the test process and parameters, making it easier to determine the product’s true envelope of operation.
How Does a Computer Bus Affect Testability?
In the past, a design was considered testable if it could be initialized to a known state and external control was provided for specific internal nodes. This usually meant using resistors and test jumpers on SET/RESET/CLR lines not active during product operation.
Now, a typical product has multiple clocks and intelligent devices that require setup via bus transactions. Test software must include a set-up process. The decision-making capability of emulation is needed to initialize bus-based devices and subsystems.
Testability and repairability of digital bus-based products equates to enabling the tester to gain control of the main communications bus. When the UUT’s design allows complete control of the bus, then bus-cycle emulation can be used.
Test generation goes quickly when the tester is in control of the UUT. Unfortunately, some microcontrollers do not allow external control of the bus. In these cases, ROM emulation is usually employed.
With ROM emulation, the tester doesn’t control the communications. It tells the microprocessor what to say and with whom to talk. Even with ROM emulation, the design engineer must provide a means of disabling the on-board ROM. This is an easy task usually accomplished via a test jumper.
A board that has no provisions for tester control is the hardest to test. With these boards, you have to perform systems emulation. That is, you must make the UUT think it really is installed in the system. As a result, the test must be written with both the hardware and software that the board is running in mind.
How Do You Test Embedded Processors or Boards With Multiple Buses?
Testability is critical. Good designs allow test modes to be enabled so one master interface can gain control of all major communication buses. One example would be a board with dual-ported memory, where two masters or the equivalent of two call-placers can leave messages for each other in an asynchronous manner. With testability addressed properly, the capability for one master to control both phone lines is provided.
This capability enables the tester to do more than control the conversations; it can also observe what’s happening. You have a closed loop that can verify that both masters can communicate properly. This provides better diagnostics and reduces test time.
Where Do You Start?
The fundamental issue in developing test programs with emulation is determining how you should view the UUT. Sometimes it is not easy to grasp how the product works.
Hardware Design Viewpoint
For hardware engineers, the product has a variety of devices, such as PALs, gate arrays, ASICs and LSIs. They concentrate on propagation delays, timing chains, and setup-and-hold requirements. They may elect to use ECL, GAS, LS, HCT or whatever logic family meets their needs. Their goal is to provide the hardware and the speed necessary to meet product requirements.
Software Development Viewpoint
What do software engineers see when they look at the UUT? They don’t care if there are PALs or glue logic, or if the devices are ECL, GAS or CMOS. What they see is 6 MB of RAM, starting at address $00000000. They are told they have three timer counters at $f00fe000 through $f00fe00f. There is a counter at location X, an 8-bit parallel port at location Y, and so on. In short, they see a memory map and bit definitions of the locations in that memory map.
How Should a Test Engineer View a Digital UUT?
It certainly is easy to get lost in a sea of 1s and 0s. You could see state machines, decoders and flip-flops all distributed across 50 pages of schematics. It is easier to view the board as a group of resources that are available for software utilization. The memory map and register definitions for a board are much easier to understand than scores of PAL equations. View the board like a software engineer and view the test as a series of conversations with devices on the bus.
Test cycles are bus transactions when using emulation. Since your job is to test the hardware, you must also verify bus timing. With emulation, you can verify wait states, interrupt propagation and signal integrity of the UUT. Since each test cycle is a complete bus operation, you can see this activity in real time.
The key to developing tests with emulation is to cover the memory map completely. Consider the memory map as a list of phone numbers. Developing your tests will be a series of calls to everyone on the list. Divide and conquer the board on an address-by-address basis.
Summary
Product Operation and Characterization: Emulation helps a test engineer to find out how the product works. With emulation, the conditions of operation can be varied to allow characterization of the UUT’s true envelope of operation.
Test Comprehensiveness: Emulation tests the UUT, at speed, the way it operates in its end application. The UUT memory map is used in test development so fault coverage is maximized by exercising and observing every UUT function.
Production Test Development and Debug: Emulation techniques improve program-development efficiency by allowing a test engineer to control the flow of testing and to interact with the UUT during debug.
Fault Diagnostics and Troubleshooting: Emulation gives a technician the tools needed to observe and focus on specific failure mechanisms. Since the emulator controls the activity on the bus, a divide-and-conquer approach can be used to pinpoint the device responsible for the problem.
About the Author
Bob Grist is the Director of Field Applications for Digalog Systems. Before joining the company eight years ago, he was employed at Factron and Scientific Machines Corp. as an Application Engineer. Digalog Systems, Inc., 3180 S. 166th St., New Berlin, WI 53151, (414) 797-8000.
Copyright 1995 Nelson Publishing Inc.
April 1995
|
|