Designing for Testability & Sharpeye Testability Analysis

This note describes designs that are easily testable by computer program. "Easily testable" means that a program uses reasonable time and memory to produce a small number of test vectors that yield high fault coverage. This definition evades theoretical issues by adopting a market-driven paradigm: a design is testable if you can buy or write a piece of software that generates tests for that design.

Attributes of Easily Testable Designs by Software Programs

Short initializations: Test is simplest if a device initializes using one vector. Initialization using multiple vectors or homing loops are OK on small devices, but too many vectors cause trouble on large devices.

Short counters: Long counters are OK if they are loadable.

External clocks: Clock each flip-flop from an input pin.

Simple sets and resets: Control reset lines from input pins.

Single-vector tri-statable outputs For in-circuit board test, make each output tri-statable from a PI.

Purely combinatorial logic: Use built-in flip-flops to hold state bits.

Simple and observable logic: Use free output pins as observation posts for deep logic elements. Use free input pins as control posts for deep logic elements.



Avoiding Untestable Designs to Allow Use of Software Programs

Here at ACUGEN® Software we believe that these sensible design practices produce designs that programs can test. These practices work by avoiding design attributes that cause long run times, have high memory usage, produce low fault coverage. To that end, it makes sense to:

• Avoid initializations that depend on the tester overdriving the chip.

• Shorten counters by using a free input pin to divide long counters in half.

• Avoid internally-generated clocks, particularly one-shots.

• Avoid resets controlled by state machines.

• Avoid disable lines controlled by state-machines.

• Avoid building latches out of boolean gates, particularly when gates are shared between the latches and the logic feeding built-in flip-flops.

• Avoid long chains of logic gates not directly feeding outputs and not directly fed by inputs.



Inherently Untestable Designs and Designs that Overflow Computational Limits

We divide unacceptable designs into two categories. One category contains the inherently untestable designs: those that cannot be tested by any methodology. The other category contains those designs that overflow computational limits: these designs might be testable in theory, and sometimes testable within practical limits, but the search for a solution could take a long time. Such designs are problematic for computer-based test methodologies. Since most companies use computer-based technologies to test these designs, we must come to an understanding of how to get "testable designs".

Details Of Software-Testability Guidelines

• The best designs have short initializations, preferably using one vector. The length of an initialization significantly affects test length because every test set begins by applying the initialization. For example, if the initialization uses 17 vectors, each set will have 16 vectors more than the minimum necessary. If the test uses 100 sets, then you have 1600 vectors more. This is an inherent problem. Another problem is simply finding the initialization. On a small design it might be computationally feasible to discover homing loops or initializations 20 vectors long. However, the larger a design is, the harder this becomes.

Uninitializable designs are unacceptable to everyone and the toggle flip-flop, which oscillates state, is notorious. Operationally, it may only matter that the toggle changes state on every clock but a test engineer is concerned with the exact state of the toggle. Thus, every flip-flop must be initializable to a known state. Besides, in-circuit board testing requires initializable designs because you cannot rely on the chip's power-up state since the device might be affected by testing other chips on the board.

• Short counters are dramatically easier to test than long counters. It takes 256 vectors to test an 8 bit counter, and just 16 vectors to test two 4-bit counters. Long counters pose computational difficulty due to these extra vectors and the limited vector memory of some testers. Divide long counters in half!

• Software test generators perform better on designs that use external clocking. Discussing three kinds of internal clocks will show why. First, an internal clock generated by combinatorial logic (excluding one-shots) is an inherent testability problem because of the possibility of interpreting glitches as clock edges. A one-shot, is computationally difficult to analyze because its properties cannot be determined by a static analysis of the circuit. The third clock-type is generated by state machines and is computationally difficult so any computer-generated test method has more trouble with these designs than when the entire state machine uses a common, externally generated clock.

• Keep it simple: use simple sets and resets . Avoid sets and resets controlled by state machines because such constructions increase the computational cost of test generation. For example, on each test set you have to initialize the flip-flops. Next, you must get the controlling machine’s state so it won’t reset the flip-flops during the test. Then, you have to compute the vectors that expose a fault, all the while holding the condition that will keep the set and reset lines inactive. These types of constraints make a tough job tougher.

• In-circuit board testing requires each output to be a tri-statable output -- preferably a single vector tri-statable output -- for two reasons. First, in-circuit testers have a limited amount of memory for storing vectors, so cutting down on the vector count avoids an inherent problem. Second, simplifying tri-state logic simplifies test development the same way as simplifying set and reset logic.

• Programs can test designs that build latches out of boolean gates, but the difficulty depends on how those latches are used. When the latch holds state information, on an equal footing with the chip’s built-in flip-flops, it is a simple matter. But when the latch also figures into the combinatorial logic feeding a built-in flip-flop, or when it feeds a flip-flop’s set or reset lines, then trouble evolves because the flip-flop’s controllability is determined by the state of the latch. This adds complexity to the test sequences in the same way as complex sets and resets.

• Finally, it is best to use simple and observable logic because combinatorial complexity is a crucial determinant of program running time and space usage. Your designer may not be able to help you here since his design must compute a specific function that largely determines the design’s combinatorial complexity. However, it might help to use spare output pins as observation posts to bring intermediate values to the exterior. It might also help to use a spare input pin as a control post to control the value of some intermediate term in the function.

Options for Dealing with Testability Problems -- SHARPEYE Testability Analyzer

Test Engineers are not happy when they have to go back to the design engineer for testability reasons. Design Engineers are not happy about the visit either. But, when a test generator has trouble, it is often because the design is inherently hard, tricky, unreliable, or even wrong. The designer will want to know this. Worst case: he will be unable to help test engineers due to schedule, or cost, or other constraint. At best, he will give test engineers an easy-to-test design, so test can look forward to a short test generator run that produces a short test yielding high fault coverage.

For help in determining testability issues, consider a testability analyzer that will automatically analyze logic designs and report testability problems in easy-to-read format. SHARPEYE software can improve design testability and eliminate costly testability-related problems in manufacturing.


ATGEN and ACUGEN are registered trademarks and AAACT, AALCA, AAMAX, AALAT, AAQL, SHARPEYE & FASTpass are trademarks of ACUGEN Software, Inc. All other trademarks are the property of their respective holders.