ShareCG: ASICs .. the Book

Chapter start ] [ Previous page ] [ Next page ]

14.9  The Viterbi Decoder Example

Table 14.22 shows the timing analysis for the Viterbi decoder before and after test insertion. The Compass test software inserts internal scan and boundary scan exactly as in the Threegates example. The timing analysis is in the form of histograms showing the distributions of the timing delays for all paths. In this analysis we set an aggressive constraint of 20 ns (50 MHz) for the clock. The critical path before test insertion is 21.75 ns (the slack is thus negative at –1.75 ns). The path starts at u1.subout6.Q_ff_b0 and ends at u2.metric0.Q_ff_b4 , both flip-flops inside the flattened block, v_1.u100 , that we created during synthesis in an attempt to improve speed. The first flip-flop in the path is a dfctnb ; the last flip-flop is a dfctnh . The suffix 'b' denotes 1X drive and suffix 'h' denotes 2X drive.

After test insertion the critical path is 21.98 ns. The end point is identical, but the start point is now subout7.Q_ff_b1 . This is not too surprising. What is happening is that there are a set of paths of nearly equal length. Changing the flip-flops to their scan versions ( mfctnb and mfctnh ) increases the delay slightly. The exact delay depends on the capacitive load at the output, the path (clock-to-Q, clock-to-QN, or setup), and the input signal rise time.

Adding test logic has not increased the critical path delay substantially. Almost as important is that the distribution of delays has not changed substantially. Also very important is the fact that the distributions show that there are only approximately 20 paths with delays close to the critical path delay. This means that we should be able to constrain these paths during physical design and achieve a performance after routing that is close to our preroute predictions.

TABLE 14.23  Fault coverage for the Viterbi decoder.


Fault list generation/collapsing

Total number of faults: 8846

Number of faults in collapsed fault list: 3869

Vector generation



# processed


# 20 7515 82.92%

# 40 8087 89.39%

# 60 8313 91.74%

# 80 8632 95.29%

# 87 8846 96.06%


# Total number of backtracks: 3000

# Highest backtrack : 30

# Total number of vectors : 87


# STAR RESULTS summary

#  Noncollapsed Collapsed

# Fault counts:

# Aborted 178 85

# Detected 8427 3680

# Untested 168 60

# ------ ------

# Total of detectable 8773 3825


# Redundant 10 6

# Tied 63 38


# FAULT COVERAGE 96.06 % 96.21 %

Next we check the logic for fault coverage. Table 14.23 shows that the ATPG software has inserted nearly 9000 faults, which is reasonable for the size of our design. Fault coverage is 96 percent. Most of the untested and tied faults arise from the BST logic exactly as we have already described in the Threegates example. If we had not completed this small test case first, we might not have noticed this. The aborted faults are almost all within the large flattened block, v_1.u100 . If we assume the approximately 60 faults due to the BST logic are covered by a flush test, our fault coverage increases to 3740/3825 or 98 percent. To improve upon this figure, some, but not all, of the aborted faults can be detected by substantially increasing the backtrack limit from the default value of 30. To discover the reasons for the remaining aborted faults, we could use a controllability/observability program. If we wish to increase the fault coverage even further, we either need to change our test approach or change the design architecture. In our case we believe that we can probably obtain close to 99 percent stuck-at fault coverage with the existing architecture and thus we are ready to move on to physical design.

Chapter start ] [ Previous page ] [ Next page ]

Digital Cities

© 2020 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — Contact Us
ShareCG™ is a trademark of Internet Business Systems, Inc.

Report a Bug Report Abuse Make a Suggestion About Privacy Policy Contact Us User Agreement Advertise