Page 100 - Building A Succesful Board-Test Strategy

86 BUILDING A SUCCESSFUL BOARD-TEST STRATEGY

ventional PC contains most of the necessary hardware. An expansion board and
proper software may suffice to create a "test system,"
Program development may also be less expensive and less time-consuming
than development for a more-elaborate functional test. A microprocessor-
emulation test resembles a self-test for the corresponding system. Test engineers
tan avoid creating a software behavioral model of a complex IC, choosing instead
to emulate it with a hardware pod.
Emulation tests boards in their "natural" state. That is, it does not apply every
conceivable input combination, restricting the input set to those states that the
target product will experience.
Emulation can also find obscure faults by "performance analysis." It can
identify software problems by tracking how long the program executes in each area
of memory, in some cases, software contains vestigial routines that do not execute
at all. Recent revisions may have supplanted these routines, yet no one has deleted
them. They take up memory space, and their mere presence complicates debugging
and troubleshooting the software to no purpose. In other cases, a routine should
execute but does not.
1 "or example, an unused routine may provide a wait state between two events.
Unless the system usually or always fails without that delay, the fact that the soft-
ware lies idle goes unnoticed. If the emulation test knows to look for program exe-
cution in that section of memory and it never gets there, the test will fail. This
technique will also notice if the software remains too long in a section of memory
or not long enough (such as an n-cycle loop that executes only once).
Emulation permits finding certain failures that are difficult or impossible to
detect in any other way. One such example is single-bit-stack creep. A computer
system stuffs information into a data stack in bytes or other bit-groups for later
retrieval. If noise or some other errant signal adds or deletes one or more bits, all
subsequent stack data will violate the specified boundaries, and retrieved data will
be garbled. The ability to stop the system to examine hardware registers (such as
stacks) will uncover this particularly pernicious problem. As digital-device voltages
continue to fall, this kind of fail-safe testing becomes more important.
Disadvantages of this technique include the need for individual emulation
modules tor each target microprocessor, RAM configuration, or I/O bus. Module
availability presents few impediments other than cost if the target configuration is
common, such as an ISA or USB PC bus or a Pentium-class microprocessor.
Testing custom systems and new designs, however, may have to wait for the pod's
completion.
Program generation is nearly always a manual process and requires a
programmer with intimate knowledge of circuit behavior. Therefore, test devel-
opment tends to miss unusual failure mechanisms, because the person most famil-
iar with a board's design is not the person most likely to anticipate an oddball
result.
Emulation requires that the target system be microprocessor-based. Creating
guided-probe diagnostics is both expensive and time-consuming, especially for
memory and bus-timing variations where the microprocessor is not completely