AppNote 3002

Debugging Simulation Mismatches in

FastScan
by Geir Eide
Last Modified: July 03, 2001

©Copyright Mentor Graphics Corporation 1995-2001. All rights reserved.

This document contains information that is proprietary to Mentor Graphics Corporation. The original recipient of this
document may duplicate this document in whole or in part for internal business purposes only, provided that this entire notice
appears in all copies.In duplicating any part of this document, the recipient agrees to make every reasonable effort to prevent
the unauthorized use and distribution of the proprietary information.
Trademarks that appear in Mentor Graphics product publications that are not owned by Mentor Graphics are trademarks of
their respective owners.

Abstract
Introduction
Simulation Methodology
Testbenches
Mismatch - Where to Start
DRC Violations
When, Where, and How Many?
Library Problems
Timing
Thorough Analysis of the Simulation Data
Resolve Mismatch Using Simulation Data
Mismatch on Scan Cells
Mismatch on Primary Output Pins
Debugging Serial Simulation Mismatches
Pattern Analysis
ASCII Patterns
WGL Patterns
Verilog / VHDL
FastScan Commands
Additional Information

Abstract
This AppNote describes how to debug simulation mismatches in FastScan. Some of the
most common causes to mismatches are discussed, as well as a description of the testbench
and pattern formats.

Debugging Simulation Mismatches in FastScan 1 of 21

July 03, 2001
AppNote 3002 Introduction

Introduction
FastScan and FlexTest provide parallel and serial Verilog and VHDL testbenches, which can
be simulated in a timing-based simulator such as ModelSim. When these patterns are
simulated, FastScan's expected values can be verified against the simulator's simulated values.
When these values do not match, you have a "simulation mismatch", which needs to be
debugged before the patterns can be used on a tester.
This AppNote focuses on the Enhanced Verilog testbench, the Verilog testbench that is written
when using the "-procfile" switch with the "save patterns" command in FastScan v8.6_4.5 and
later. An Enhanced procedure file is needed for this format. The enhanced procedure file is a
replacement for the test procedure file and the timing file. The format of the Enhanced
procedure file is described in Appendix A of the Design-For-Test Common Resources Manual.
Most of the information in this AppNote, except the part that describes the Verilog testbench in
detail, also applies to the old Verilog testbench format and the VHDL testbenches. A testbench
in the "old" format is generated when using the FastScan v8.6_2 (or older), or the "-timingfile"
switch with the "save patterns" command on FastScan v8.6_4 and later.

Simulation Methodology
After testing the functionality of the circuit and generating the test vectors with FastScan, you
should also run the FastScan-generated test vectors in a timing based simulator and compare
the results with the predicted behavior from the ATPG tools. This run points out any
functionality discrepancies between the two tools, and also show timing differences that may
cause different results. At this point in the design process, you should run a full timing
verification to ensure a match between the results of golden simulation and ATPG. This
verification is especially crucial for designs containing asynchronous circuitry. The
recommended methodology for verification of FastScan-generated test vectors is to save all
parallel patterns, and 2-3 serial patterns in Verilog (or VHDL) and simulate these in a timing-
based simulator. Notice that a chain integrity test (chaintest) is by default included in both the
parallel and serial testbench. This chaintest can be very useful when debugging timing-related
mismatch issues.
One should also save all patterns in ASCII or binary format for troubleshooting, since these
two are the only formats that can be read back into FastScan. If there are no mismatches in the
simulator, save the patterns in the format required by the tester (for instance WGL or TI-TDL).

Testbenches
As previously mentioned, FastScan can generate both "parallel" and "serial" testbenches in
Verilog and VHDL. It is easier to debug simulation mismatch problems if you have a good

2 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Testbenches AppNote 3002

understanding of how these testbenches work. Consider the simple design with three mux-dff
scan cells connected in a chain in Figure 1 .
Figure 1. Simple Scan Chain

In this simplified schematic, combinational circuitry between the Q outputs and D inputs has
not been included. As you see from the schematic, you shift data through the chain when
Scan_en is set to 1. Then Scan_en is set to 0, you capture data through the D inputs. A basic
scan pattern has the following components:
1. Load Scan chain(s)

2. Force Pis

3. Measure Pos

4. Pulse Capture Clock

5. Unload Scan chain(s)

These components are described in procedures in an Enhanced Procedure file (or a procedure
file and a timeplate file). The first component in the pattern, loading the scan chains, is
described in two procedures. First, the load_unload procedure is applied. This prepares the
scan chains for shifting. Normally, that means setting the clocks to their off-state, and setting
scan enable to its active state. Then, the shift procedure is applied as many times as you have
cells in the longest scan chain. In this procedure, you force a value to the scan input pin
(scan_in in the design above), measure a value on the scan output pin, and apply the shift clock
once.
Note: This is actually a simplified explanation. The load_unload and shift procedures do work
together as a unit. It is possible to have more complex situations with for instance cycles
following the application of the shift procedures in the load_unload procedure. This creates a
vector that is applied at the end of the loading/unloading of the scan chains).
When the scan chain is loaded, you apply the capture procedure, which consists of components
2-4 above. When the capture clock is pulsed, data is captured into the scan cells. To observe
this data, the scan chain is unloaded by applying the load_unload and shift procedures again. In
reality, you load and unload the scan chain at the same time; you unload pattern 1 at the same
time as you load pattern 2.

Debugging Simulation Mismatches in FastScan 3 of 21

July 03, 2001
AppNote 3002 Testbenches

In the serial testbench, you operate the scan chain just as you do on the tester. The scan chain
is loaded by placing one value on the scan in pin, pulsing the clock once, placing another value
on the scan in pin, pulsing the clock again, etc. For each single pattern, you must shift (clock)
as many times as you have scan cells in the longest chain, plus once for the capture cycle. With
the exception of the first and the last pattern, the chain will be loaded with the new pattern at
the same time as the result from the previous pattern is unloaded. Therefore, n+1 load/unloads
are needed for n patterns. For the design in figure 1, you need to clock 3 times to shift data in
and out of the scan chain (load and unload the chain). For a design with 5,000 scan cells in the
longest chain, and 2,000 patterns, you need to pulse the clock 5,000 x 2,001 (shift) + 2,000
(capture) = 10,007,000 cycles.
In a regular simulator, it takes extremely long time to simulate all the test vectors in a state-of
the art design. Therefore, you take a shortcut in the parallel testbench. In the simulator, you
have access to internal nodes in the design. and this is utilized in the parallel testbench. Instead
of using scan_in and scan_out, and shift data serially through the chain, you force the scan
input pins of all the scan flops in parallel. To load the scan chain, you prepare the scan chain
for shifting by applying the load_unload procedure. Then, you apply the shift procedure once.
In the shift procedure you first measure the output of every scan cell. Then, you force new
values on the scan input pins (in the example above, Sin of A, B, and C) using the Verilog force
statements. Then, data is shifted into the scan cells by pulsing the clock. When the new values
have been captured into the scancells, you release the internal nodes. This enables you to load
and unload the entire scan chain in only one clock cycle. The entire test now takes only 2,001
(shift) + 2,000 (capture) = 4,001 clock cycles!
Another important difference in the parallel and the serial testbench is that the parallel
testbench reports on which specific scancell a mismatch was reported. The serial testbench
only reports which scan output pin the mismatch was observed on, and at which time during
the simulation. As previously mentioned, it is recommended to simulate all parallel patterns,
and a few serial patterns. If any of these parallel patterns fail, it can be useful to simulate the
serial version of these specific patterns.
While the parallel testbench reduced simulation time and simplifies the debugging effort, there
are a couple of things that can make the resulting waveforms seem a bit confusing. The force
statements apply to nets, and not ports. In other words, when you force the scan input of B, you
force the net that is also the QB output of A. After the clock pulse, the net is "released", and
goes back to the value to which it was originally driven. Because of this, you need to measure
the scan output pin before you force the scan input pin. Even when the shift procedure specifies
that the force takes place before the measure, the scan output is always be measured before the
scan input in the parallel testbench.
For other pattern types (such as clock sequential and ram sequential) and designs with
subchains, the picture becomes slightly more complex. Certain pattern types apply the
load_unload procedure and/or the capture cycle multiple times for each pattern. For details on
these pattern formats, see FastScan Pattern Types in Chapter 6 of the Scan and ATPG Process
Guide. For all pattern types, the difference between parallel and serial representation is that the
shift procedure is applied only once for each load/unload process in the parallel format. One
exception is for designs with subchains. A subchain is defined as a chain that resides inside a
library model. Since the simulator does not have access to the inside of a model, the subchain
serially shifts. Assume a design has a chain with 500 scan cells. Of this chain, maximum 5 cells
connect together in a subchain. In the parallel testbench, you observe 5 shifts per pattern. To
locate a subchain, you use the report scan cells command and look for cells with unspecified
scan in and scan out ports.

4 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Mismatch - Where to Start AppNote 3002

Note: As previously mentioned, this AppNote concentrates on the Verilog testbench, and the
following examples are from the Enhanced Verilog Parallel testbench. The VHDL testbench
functions similarly. However, since it in VHDL is not possible to force internal nodes in a
design. The ModelSim/QuickHDL dofile accompanies the parallel VHDL testbench, which
forces the internal nodes. Otherwise, the VHDL testbench works similarly to the Verilog
testbench.

Mismatch - Where to Start

The most difficult part of debugging simulation mismatches is knowing where to start. There
are many causes to simulation mismatches. A lot of information is available, and it is important
to debug the "right" problem and go through the potential sources of the problem in the right
order. The following is a suggestion of how to proceed :
1. Check DRC violations

2. Where, when and how many are the mismatches

3. Check library problems

4. Timing

5. Thorough analysis of the simulation data

6. Analysis of patterns

DRC Violations
The DRC violations that are most likely to cause simulation mismatches are C3, C4, C6, and
W17 violations. For details on these violations, see Chapter 2 in the Design-For-Test Common
Resources Manual and TechNotes describing each of these violations. For most DRC-related
violations, you should be able to see mismatches on the same flops as you have DRC
violations.
In most cases, the command set split capture on resolves the mismatches caused by the C3
DRC violation. Mismatches caused by the C6 violation can be avoided using set clock_off
simulation on. See the FastScan and FlexTest Reference Manual for details on these
commands. Notice that the commands does not remove the drc violations, but instead change
FastScan's expected values thus resolving the mismatch.
A W17 violation is issued when you save patterns (in any format but ASCII or binary), if you
have clock_po patterns and you do not have a clock_po procedure in your Enhanced Procedure
File. This (in most cases) causes simulation mismatches for clock_po patterns. The solution is
to define a separate clock_po procedure in the Enhanced Procedure file. See Appendix A in the
DFT Common Resources Manual for details on such procedures.
Another common problem is shadow cells. Such cells do not cause DRC violations, but the
tool issues the following message when going into atpg mode : // 1 external shadows that use
shift clocking have been identified. A shadow flop is a non-scan flop that has the D input
connected to the Q output of a scan flop. Under certain circumstances, such shadow cells are
not loaded correctly in the parallel testbench. If you see the message mentioned above, it
indicates that you have SHADOW cells in your design, and that the mismatch that has been

Debugging Simulation Mismatches in FastScan 5 of 21

July 03, 2001
AppNote 3002 Mismatch - Where to Start

reported might be due to this problem. For details on this issue, see TechNote 13654,
Simulation Mismatches: Parallel Patterns Fail, Serial Patterns Pass.

When, Where, and How Many?

If DRC violations do not seem to be a problem, you need to take a closer look at the
mismatches and check for the following:
• Are the mismatches reported on primary outputs (POs), scancells or both?
Mismatches on scan cells can be related to capture ability and timing problems on the scan
cells. For mismatches on primary outputs, the issue is more likely to be related to incorrect
value being loaded into the scan cells.

• Are the mismatches reported on just a few or most of the patterns?

Mismatches on few patterns indicates a problem that is unique to certain patterns, while
mismatches on most pattern indicates that something more general is causing the problem.

• Are the mismatches observed on just a few pins/cells, or most pins/cells?

Mismatches on few pins/cells indicates a problem related to a few specific instances, or one
part of the logic, while mismatches on most pattern indicates that something more general is
causing the problem.

• Do both the serial and the parallel testbench fail, or just one of them?
A problem in the serial testbench only, indicates that the mismatch is related to shifting of
the scan chains, for instance that data shift through two cells on one clock cycle, due to
clock skew. As mentioned above, the problem with shadows causes the serial testbench to
pass and the parallel to fail.

• Does the chain test fail?

As described above, serial pattern failure can be related to shifting of the scan chain. If this
is true, the chain test (which simply shifts data from scan in to scan out, there is no capture
of functional data) also fails. This AppNote discusses debugging of problems where the
serial chain test fails later in Debugging Serial Simulation Mismatches.
• Do only certain pattern types fail?
If only ram sequential patterns fail, the problem is most certainly related to the RAMs (for
instance incorrect modeling). If only clock_sequential patterns fail, the problem is probably
related to nonscan flip-flops and latches. If clock_po patterns fail, it might be due to a W17
violation. For designs with multiple clocks, it can be useful to see which clock is toggled for
the patterns that fail.

Examining the above does not necessarily locate the source of the mismatch 100% of the time,
but it is a good help in the debugging process.

Library Problems
Sometimes, the problem can be related to incorrect library models. If for instance the reset
input of a flip-flop is modeled as active high in the ATPG model used by FastScan, and as
active low in the Verilog model used by the simulator, simulation mismatches most likely
occur. The likeliness of such problems depends on the library. If the library has been

6 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Resolve Mismatch Using Simulation Data AppNote 3002

successfully used for several other designs, the mismatch is probably caused by something
else. On the other hand, a newly developed, not thoroughly verified library could easily cause
problems. For regular combinational and sequential elements, this causes mismatches for all
patterns, while for instances such as RAMs, mismatches only occur for a few patterns (such as
ram sequential patterns).
Another library-related issue is the behavior of multi-driven nets and the fault effect of bus
contention on tristate nets. By default, FastScan is pessimistic, and for instance on non-tristate
multi-driven nets, non-equal values on the inputs always result in an X on the net. For
additional information, see the commands set net resolution and set net dominance.

Timing
One indication of timing-related mismatches are Setup and hold violations during the
simulation of the testbench. In some cases, you see such violations on the same scan cell as has
a reported mismatches, while in other cases the problem might be more complex. For instance,
a violation during the loading of a scan cell is observed as a mismatch, not on this cell, but the
cell(s) and PO(s) that the violating cell propagates to. Another common problem is clock skew.
This is discussed in Checking for Clock-Skew Problems with Mux-DFF Designs in Chapter 6
of the Scan and ATPG Process Guide.
Another common timing related issue is that the timeplate and/or test procedure file has not
expanded. By default, the test procedure and timeplate files have 1 "time unit" between each
event. When testbenches are created using the default -timing switch for the save patterns
command, the time unit expands to 1000ns in the Verilog and VHDL testbenches. When the
Enhanced Procedure file is used and the -procfile switch is used with the save patterns
command, each time unit in the timeplate is translated to 1 ns. This can easily cause
mismatches.

Thorough Analysis of the Simulation Data

If mismatches are not resolved after analyzing the above issue, you need to thoroughly
examine the simulation data and compare the values observed in the simulator with the values
expected by FastScan. The next part of this AppNote examines this process in detail using the
Enhanced Verilog Parallel Testbench. The process is identical for the "old" Verilog testbench
and very similar for the VHDL testbench. Together with the testbench, it is often useful to get
additional information from the ASCII (or even WGL) pattern formats. See the section on
Pattern Analysis.

Resolve Mismatch Using Simulation Data

The testbench reports when the simulated value do not match FastScan's expected values. In
the parallel testbench, both time, pattern number, and scan cell or primary output are reported.
In the serial testbench, only output and time are reported and it is more difficult to find the scan
cell where the incorrect value has been captured. If there are no mismatches, the testbench
reports: No error between simulated and expected patterns. Based on the time and scan cell
reported in the testbench, you can generate waveforms or dumps that display the values just
prior to the mismatch. These values can then be compared to the values FastScan expected.
With this information, you can trace back in the design (in both FastScan and the simulator) to

Debugging Simulation Mismatches in FastScan 7 of 21

July 03, 2001
AppNote 3002 Resolve Mismatch Using Simulation Data

see where the mismatch originates from. Transcript 1 shows the beginning of a simulation
transcript from the Verilog testbench.
Transcript 1

run -all
# Loading testpat.v.0.vec
#
# 4200: Simulated response 1101x10100000000000000001110010001001
01001000100000000000111110010101100110 pattern 0
# 4200: Expected response 1x01110100000000000000001110010001001
01001000100000000000111110010101100110 pattern 0
# 4200: Mismatch at chain chain1 cell 4 name sub.reg_ws6.QB, Simulated x,
Expected 1
# 6000: Simulated response 0011100010010000101001011011100001110
00100001000000011100011001000111110111 pattern 1
# 6000: Expected response 0x10000010010000101001011011100001110
00100001000000011100011001000111110111 pattern 1
# 6000: Mismatch at chain chain1 cell 4 name sub.reg_ws6.QB, Simulated 1,
Expected 0
# 6000: Mismatch at chain chain1 cell 3 name sub.reg_w8.QB, Simulated 1,
Expected 0
# 6600: Simulated response 0011010111010101001111010011010101001
00011000001011100110101110000110100011101111010000100 pattern 2
# 6600: Expected response 0011010111010101001111010011010101001
00011000001011100110101110000110100011101111010000000 pattern 2
# 6600: Mismatch at pin 2 name \Xout[1] , Simulated 1, Expected 0

Notice that when the scan chains are long, it can be hard to filter out the most interesting
information in the transcript. What is of highest interest is the following information:
• Time of mismatch

• Pattern number

• Name/location of scan cell (or primary output) where mismatch was observed.

You now use this information in debugging simulation mismatches, first on scan cells, then on
primary outputs.

Mismatch on Scan Cells

The first important detail to notice is that the time of the mismatch refers to when the scan cell
was measured. It does not refer to when that data was captured into the scan cell. For
mismatches on a scan cell, this is a very important difference. You see what effect this
difference has on the debugging process by analyzing the first mismatch that was reported in
the transcript above. From Transcript 1, notice that the mismatch is observed at time 4200 in
pattern 0 on the QB output of the scan cell /sub/reg_ws6. FastScan expected to observe a "1",
while the simulator simulated an "X".
Figure 2 shows the waveform from our simulator, where you see the waveforms for the
register with the mismatch. The first signals are QB , Q, D1 (which is scan in), D0 (data in) for

8 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Resolve Mismatch Using Simulation Data AppNote 3002

/sub/reg_ws6. The signals clk and scan_en on the bottom of the waveform are clock and scan
enable for this (and most other) scan cell.
This specific design has some unusual modifications that are implemented to ease the
debugging process. Four pins have been added to the design (by modifying the netlist). In the
FastScan dofile, these pins are constrained to 0. Each of the signals are then forced during
various procedures using Force statements in the test procedure file. This causes each signal to
be "1" during a specific procedure, and "0" otherwise. This is done to make it easier to see how
the various procedures are used during the simulation. The dum_test signal is active during the
test_setup procedure. The dum_load is "1" during the load_unload procedure. Dum_shift and
dum_capture are "1" during the shift and capture procedures respectively.
These signals can now be used to see which procedure is applied at which time in the pattern
set, and which events occur during which procedure. From the waveforms in Figure 2 , you see
how the load_unload procedure is followed by a shift procedure, a capture procedure, and then
a load_unload procedure again. As mentioned above, these dummy signals are normally not
available, but are added to this design to help you understand how the patterns are constructed.
A helpful signal which is always available in the testbench is pattern_cout variable which
indicates which pattern you are looking at.
Figure 2. Demonstration of How Patterns are Constructed

Before analyzing the values in this waveform, there is some unusual behavior that needs to be
explained. At around 2500 ns, Q and QB do not have opposite values. Also, QB seems to
change when the clock is not pulsing, and not at the same time as Q. To be able to understand
why this is happening, you need to review how the parallel testbench works.
The simulation transcript (transcript 1) reported the mismatch at time 4200ns. This is marked
with a vertical bar in Figure 2 . The dummy signals indicate that the measurement is done
during the shift procedure. In FastScan, you report values on any gate for any pattern. The
values are reported at a time just before the capture clock, which is not the same time as the
testbench measures the signal. The time FastScan reports the value of is represented with the
vertical bar at time 3300 in Figure 3 . If you step further back, you notice that during the "shift"
procedure, QB changes "independently" of Q. In the shift procedure, you first measure the
output of the scan cells. This is done at 2400ns and 4200ns. At the same time, you force the
scan input nets with a new value. Since the QB and Q of register reg_ws6 are different pins,
only the pin connected to a scan in pin (which is QB in this case) is affected by this force
statement. Q changes when the clock pulses in the shift procedure. At time 2800 ns, the force is
released, and QB has the value that is driven by the register. In other words, on this part of the
waveforms, you have three clock pulses, the left most clock is a shift clock, the middle one a

Debugging Simulation Mismatches in FastScan 9 of 21

July 03, 2001
AppNote 3002 Resolve Mismatch Using Simulation Data

capture clock, and the right most a shift clock. Also notice the pattern_count signal that
increments during the beginning of the capture cycle.
Figure 3. Time Values Reported By FastScan

Notice that for the bar at time 4200ns, the measured value is what is just to the left of the bar.
At time 3300ns, the value reported in FastScan for the pattern is the value just to the left of the
bar. Now, you need to invoke FastScan and read back the simulated patterns. See Transcript 2.
Transcript 2

// command: set pattern source external testpat.ascii

// command: save patterns testpat0-9.ascii -begin 0 -end 9 -
external
// command: set pattern source external testpat0-9.ascii
// command: run
//
// command: set gate report parallel 0
// command: set gate level design
// command: rep gate /sub/reg_ws6
// /sub/reg_ws6 dfsc
// CK I (1) /clk
// SC I (0) /scan_en
// D0 I (0) /sub/reg_ws5/Q
// D1 I (1) /sub/reg_w4/QB
// Q O (1) /sub/reg_ws7/D
// QB O (0) /sub/reg_w8/D1

First, the original pattern set is read back in ASCII or binary format. The advantage of ASCII is
that it is easier to visually inspect, while binary takes less disk space. We are going to utilize a
function where you can see the value for a specific pattern using the "report gate" command.
DFTInsight can also be used. To be able to use this functionality, you can only have up to 32
patterns in memory (64 if running the 64-bit version of FastScan). Therefore, you first create a
smaller pattern set, in this case containing only 10 patterns. This pattern set is then read back
into FastScan, and you are looking at the values for pattern 0. If you want to analyze pattern
100, the easiest is to write out a file only containing pattern 100. This is possible because each
pattern in FastScan is independent.

10 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Resolve Mismatch Using Simulation Data AppNote 3002

When using the set gate report parallel command, you are looking at the values just before the
capture clock has been pulsed. For the flip-flop above, the "1" on the clock pin indicates that
the clock will pulse for this pattern. Prior to the clock pulse, a "1" is stored in the flop. Since
scan enable is "0", a "0" is captured into the flip-flop when this clock pulses.
Instead of using "report gate", you can also use DFT Insight. You replace the command set
gate report parallel by selecting Simulated values for Pattern Number from the Reporting
Detail menu. You can also select Primitive design level from the Setup menu.
At this point, the mismatch message from the simulator can be compared with the waveforms
and the values observed in FastScan. It is important to be able to understand these three sources
of information. The next step is to trace backwards in the design, to see where the mismatch
originates. This can be done in FastScan, and it is relatively simple to do such a trace here. In
this case, start at the scan cell where the mismatch was observed, and trace backwards until you
reach another scan cell. Consider Transcript 3.
Transcript 3

// command: set gate level prim

// command: rep gate /sub/reg_ws6/D0
// /sub/reg_ws6 (1161) BUF
// D0 I (0) 694-/sub/reg_ws5/Q
// "OUT" O (0) 1888-/sub/reg_ws6/MU3/IN0
// command: b
// /sub/reg_ws5/DF2 (6717) DFF
// "S" I (0) 208-
// RESET I (0) 51-
// CLK1 I (1) 995-
// D1 I (0) 1162-
// "OUT" O (0) 209- 210-
// SHADOW cell_id=4 chain=chain1 group=grp1 invert_data=TTTF
// command: b 4
// /sub/reg_ws5 (1162) BUF
// D I (0) 696-/sub/reg_w4/Q
// "OUT" O (0) 6717-/sub/reg_ws5/DF2/D1
// /sub/reg_w4/DF2 (6718) DFF
// "S" I (0) 211-
// RESET I (0) 52-
// CLK1 I (1) 994-
// D1 I (0) 2367-/sub/reg_w4/MU3/OUT
// "OUT" O (0) 212- 213-
// MASTER cell_id=5 chain=chain1 group=grp1 invert_data=FFFT

In this example, a trace is done in primitive level. One advantage of looking at the design at
this level, is that all the clocks are always active high. For a negative-edge triggered flop, a dff
primitive (that is active high) is displayed together with an inverter on the clock line. For this
design, start at the gate where the mismatch is reported and trace back in the design until you
reach a scan cell or a primary input. This brings you through a "shadow" cell. From this
transcript, see that for this specific pattern, a value is loaded in /sub/reg_w4, this value is

Debugging Simulation Mismatches in FastScan 11 of 21

July 03, 2001
AppNote 3002 Resolve Mismatch Using Simulation Data

propagated through /sub/reg_ws5 and captured in /sub/reg_ws6. Then, you need to go back to
the simulator and look at the simulated values for the same gates. See Figure 4 .
Figure 4. Simulated Values for Same Gates

Notice that the beginning of the trace, reg_w4 has the same values as in FastScan. That means
that the correct value was loaded into this register. When you go to reg_ws5, you notice a
difference. For some reason, FastScan expected this flip-flop to have a known value ("0")
before the capture clock. Remember that for all patterns, right after a scan chain has been
loaded, FastScan assumes that all non-scan sequential elements have the value "X". So why did
FastScan expect a "0"?
The issue is that reg_ws5 is classified as a SHADOW register (see "Shadow Element" in
Chapter 3 of the Scan and ATPG Process Guide for details). That means that a value should be
loaded into this register during the scan chain loading. Under certain circumstances, such cells
are not correctly loaded in the testbench, and require special handling. The solution is rewrite
the load_unload procedure so that it contains two apply shift statements instead of one.

Mismatch on Primary Output Pins

For mismatches on primary output pins, the time the mismatch that is reported in the testbench
is during the capture cycle. Therefore, the measurement is at the same time as when values are
reported in FastScan (before the capture clock). Transcript 4 shows the the part of the
simulation transcript describing the mismatch on the primary output pin:
Transcript 4

# 6600: Simulated response 0011010111010101001111010011010101001

00011000001011100110101110000110100011101111010000100 pattern 2
# 6600: Expected response 0011010111010101001111010011010101001
00011000001011100110101110000110100011101111010000000 pattern 2
# 6600: Mismatch at pin 2 name \Xout[1] , Simulated 1, Expected 0

12 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Resolve Mismatch Using Simulation Data AppNote 3002

As in the previous case, you start by looking at the waveform for this specific output pin. Then,
you trace back the design in FastScan, and compare the waveforms to the expected values in
FastScan. Figure 5 shows the values on the output pin, as well as, the backward trace.
Figure 5. Signals Based on Trace in Transcript 5

The signals shown in Figure 5 are based on the trace in Transcript 5. Notice that this transcript
is also done in primitive level. For simplification, some of the buffers have been removed from
the transcript.
Transcript 5

// command: set gate level primitive

// command: rep gate xout[1]
// /Xout[1] (6938) PO
// "I0" I (0) 2041-/sub/ix1/Y
// Xout[1] O (0)
// command: b
// /sub/ix1 (2041) BUF
// command: b
// /sub/ix1/AN0 (1885) AND
// IN0 I (1) 1150-
// IN1 I (1) 1155-
// IN2 I (0) 1153-
// OUT O (0) 2041-
// command: b 3
…..
// command: b
// /sub/lat_w10/DL2 (6712) TLA
// "S" I (0) 190-
// RESET I (0) 45-
// CLK1 I (1) 659-
// D1 I (0) 2128-
// "OUT" O (0) 191- 192-

The first report gate command indicates that the expected value for Xout[1] is "0". When
tracing in FastScan and comparing with the values in the simulator, it is possible to see where
the difference originates from. In this case, the latch /sub/lat_w10/DL2 is particularly

Debugging Simulation Mismatches in FastScan 13 of 21

July 03, 2001
AppNote 3002 Debugging Serial Simulation Mismatches

interesting. Notice that in primitive level in FastScan, all clocks (also sets and resets) are
always active high. Therefore, from FastScan's point of view, the latch lat_w10 is active for
this pattern. Also notice that this latch is considered a transparent latch (TLA). That means that
FastScan believes that the latch enable can be turned on so that the latch is transparent and
behaves as a buffer. (The clock is not pulsed like a DFF clock).
In the simulator, on the other hand, the latch appears to be turned off. In Figure 5 , notice that
the enable of the latch is "0", D "0", and Q is "1". This indicates that there is a difference in the
model used by FastScan (the ATPG model) and the model used by the simulator. In a case like
this, you need to compare these two models to verify whether the enable signal has the same
polarity in both models.

Debugging Serial Simulation Mismatches

In most cases where serial simulation mismatches and parallel simulation passes, the serial
chain test will also fail. The first step is therefore to confirm that the serial chain test fails. To
save out a pattern with just the chain test, use the options "-serial -chain" for the "save patterns"
command.
If the chain test fails, the easiest way to debug the problem is to manipulate the procedure file
so that it contains two independent shifts, and then use the parallel testbench. If the existing
procedure is like this:
procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force CLOCK 0 ;
force scan_en 1 ;
end ;
apply shift 100;
end;

Then change it to the following:

procedure load_unload =
scan_group grp1 ;
timeplate gen_tp1 ;
cycle =
force CLOCK 0 ;
force scan_en 1 ;
end ;
apply shift 98;
apply shift 1;
apply shift 1;
end;

The example above is for the enhanced procedure file format. The same method can be used
for the old procedure file format, but requires "break" statements between the "apply shift"
statements to avoid AG violations. See TechNote 21190 for details.

14 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Pattern Analysis AppNote 3002

When using this modified procedure file, save the chaintest again, but this time in parallel
format. Below follows parts of a transcript from FastScan:

ATPG> set system mode setup

SETUP> set system mode atpg // Re-read then modified procedure file
ATPG> set atpg limit -pattern 1 //You only need one pattern
ATPG> add faults -all
ATPG> run
ATPG> save patterns chaintest_p.v -verilog -parallel -chain -
procfile

When you have independent shifts in the procedure file (the two additional "apply shift 1"
statements), two "real" shifts are applied in the parallel testbench. Two shifts are needed for the
chaintest, because of the format of the chaintest pattern (00110011...). The test will have this
format:
1. Force all internal scan input pins
2. Perform a parallel shift (pulse shift clock)
3. Perform single serial shift (pulse shift clock)
4. Perform single serial shift (pulse shift clock)

Mismatches will now be reported on the scan cell where the problem is observed. The actual
problem will be on the reported cell or one cell closer to the scan input pin. Notice that for the
chain test, you are not capturing data in the scan cells. Therefore, you are not interested in
comparing values with FastScan. Look at scan cells in the chain path.
Assume a scan chain has four cells:
INPUT --> CELL4 --> CELL3 --> CELL2 --> CELL1 --> OUTPUT

Using this method, a mismatch is reported in CELL1. In the simulator waveform, display
CELL3, CELL2, and CELL1. Examine all the inputs and outputs of each cell in this area. In
the example where the mismatch is reported on CELL1, examine CELL1, CELL2, and
CELL3. Pay special attention to the D and Q outputs of each cell. When the clock pulses, the Q
should capture the "old" value of D. A problem that occurs commonly is if Q is updated with
the "new" value, because of clock skew. If the CELL1 is clocked slightly after CELL2, this
effect can be observed in CELL1. The solution is then to either add buffers along the scan path,
or redo clock synthesis.

Pattern Analysis
Some times, additional information that is difficult to access in the Verilog (or VHDL)
testbenches can be found in other pattern formats. When comparing different pattern formats, it
is useful to know that the pattern numbering is the same in all formats. In other words, pattern
#37 in the ASCII pattern file corresponds to pattern #37 in the WGL or Verilog format.

Debugging Simulation Mismatches in FastScan 15 of 21

July 03, 2001
AppNote 3002 Pattern Analysis

ASCII Patterns
The ASCII pattern format is the most readable of the pattern format. You can use the ASCII
format to examine:
• Values loaded into scan cells.

• Values forced and measured on PIs and POs during the capture cycle.

• Expected values on scancells.

• What type a certain pattern is (clock-sequential, etc.). Basic patterns and clock_po patterns
do not have a "label", while the other types have a label indicating pattern type. See pattern
167 in Transcript 6.

The ASCII and binary formats are the only formats that can be read back into FastScan.

Transcript 6

pattern = 0;
apply "grp1_load" 0 =
chain "chain1" = "0001010101110101111011111001011111000110110";
end;
force "PI" "0001010100101011000000100000001111110100001" 1;
measure "PO" "0010001000000000010100111001111110001011" 2;
pulse "/clk" 3;
apply "grp1_unload" 4 =
chain "chain1" = "1001111010011101000000101000100000101001001";
end;

…
…

pattern = 167 clock_sequential ;

apply "grp1_load" 0 =
chain "chain1" = "0000011000110110000111111000111000001111011";
chain "chain2" = "XXXXXXXXXXXXXX00111111000111101011010110100";
end;
force "PI" "0001000000100010000101101011110111010000001" 1;
pulse "/clk" 2;
force "PI" "0001000100011111000101011010101100101100001" 3;
measure "PO" "1010000000010011001100100100000000011111" 4;
pulse "/clk" 5;
apply "grp1_unload" 6 =
chain "chain1" = "0110101010001101111000000111001111101111010";
chain "chain2" = "10101011000000101011010001110111011001110XX";
end;

16 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Pattern Analysis AppNote 3002

When examining the patterns loaded into and unloaded from the scan chains, it is important to
consider inversion in the scan chain. The values in the ASCII patterns are the values that are
shifted through the scan in and scan out pins of the design. Assume a design with two scan
cells where the QBAR output of the first scan cell is connected to the scan_in input of the
second scan cell. If the ASCII pattern indicates that "00" is loaded into the scan chain, it means
that the first cell is loaded with "0", and the second cell with "1".

WGL Patterns
The WGL patterns is particularly useful when analyzing how the timeplates are applied into
the test pattern set. Early in the file, the timeplates are defined (based on the definitions in the
Enhanced Procedure File). Then, for each cycle in the pattern set, it indicates which timeplate
is used for each cycle. For pattern 1 in Transcript 7, the load_unload and shift procedures are
applied using the timeplate gen_tp1. The capture cycle is applied using the timeplate cap_tp1.

Transcript 7

{ Pattern 1 Cycle 6 Loop 80 }

vector(+, gen_tp1) := [ 0 0 0 1 0 1 0 1 0 0 1 0 0 1 1 0 0 0 0 0
scan(+, gen_tp1) := [ 1 0 0 1 0 1 0 1 0 0 1 0 0 1 1 0 0 0 0 0
output[chain1_chain: Ochain1_sts000001_000008],
input[chain1_chain: Ichain1_sts000001_000008],
output[chain2_chain: Ochain2_sts000001_000008],
input[chain2_chain: Ichain2_sts000001_000008];
vector(+, cap_tp1) := [ 1 0 0 1 0 0 0 1 0 0 1 0 0 1 1 0 1 0 1 0

Additional information on the TSSI WGL format is available in Chapter 2 of Languages , Vol.
II, R9.0 which is available from Fluence Technology (formerly TSSI) and Mentor Graphics
DFT Customer support.

Verilog / VHDL
When using the Enhanced Procedure File, the format of the Verilog and VHDL testbenches is
dramatically different than when using the old format with a test procedure file and timeplate
file. The following applies when using the Enhanced Procedure File.
The Verilog testbench consists of two (or more) files. One file (typically with .v extension)
contains the testbench that instantiates the top level of the design. The patterns themselves are
stored in additional file(s) (typically with extension .v.0.vec, .v.1.vec, etc.). If you need to go
into detail and examine which value is being forced onto which pin at which time, you need to
gather information from both the testbench (.v) and the vector file (.v.0.vec). All the values that
are forced on the primary inputs for a specific pattern are collected in a vector. So are the
values that are measured on the outputs, as well as, loaded and unloaded values for the scan
chains. In the testbench, you can find the pin/cell to vector bit mapping for these vectors.
The vector file has one vector for each test cycle; one pattern can have multiple cycles. Each
vector contains information about what type of cycle (and whit timeplate that is used). This
information is stored in some of the bits in this vector. The testbench explains which values
represent which pattern type / timeplate.

Debugging Simulation Mismatches in FastScan 17 of 21

July 03, 2001
AppNote 3002 Pattern Analysis

Transcript 8

--
assign clk = _ibus[42];
assign ramclk = _ibus[41];
assign reset = _ibus[40];
assign enable = _ibus[39];
assign \pdata[11] = _ibus[38];
--
assign _sim_obus[89] = \paddr[10] ;
assign _sim_obus[88] = \paddr[9] ;
assign _sim_obus[87] = \paddr[8] ;
assign _sim_obus[86] = \paddr[7] ;
assign _sim_obus[86] = \paddr[6] ;
--
event force_frc_chain1_sibus;
always @(force_frc_chain1_sibus) begin
force {piccpu_inst.sub.reg_w12.D1 , piccpu_inst.sub.reg_w11.D1 ,
piccpu_inst.sub.reg_w14.D1 , piccpu_inst.sub.reg_w8.D1 ,
piccpu_inst.sub.reg_ws6.D1 , piccpu_inst.sub.reg_w4.D1 ,
piccpu_inst.sub.reg_w1.D1 , piccpu_inst.sub.reg_w3.D1
--
assign _sim_chain1_sobus[74] = piccpu_inst.sub.reg_w12.Q;
assign _sim_chain1_sobus[73] = piccpu_inst.sub.reg_w11.QB;
assign _sim_chain1_sobus[72] = piccpu_inst.sub.reg_w14.QB;
assign _sim_chain1_sobus[71] = piccpu_inst.sub.reg_w8.QB;
assign _sim_chain1_sobus[70] = piccpu_inst.sub.reg_ws6.QB;

--

Transcript 8 shows part of a Verilog testbench. _ibus is the name of the vector that represent all
the primary inputs. The first bit in the list (_ibus[42] in this example) is the leftmost bit in the
vector. The vector for the primary outputs is similar.
The scan cells are represented by two vectors. The _chain1_sibus vector represents the values
that are loaded into the scan cells, while _chain1_sobus represent the values that are unloaded
from the cells. These are the values that are captured into the scan cells during the capture
cycle.
Similar to the WGL patterns, the Verilog patterns uses the timeplates described in the
Enhanced Procedure File. The pattern type and timeplate type used for a specific cycle is
indicated by some of the bits in the vectors. There are comments in the testbench that maps
these bits to the indicated vector type and timeplate. Transcript 9 shows the part of the
testbench file that describes which values in the vector represent which timeplates. In this
example, "gen_tp1", "cap_tp1", "cap_tp2", and "cap_tp3" are timeplates described in the
Enhanced Procedure File.

18 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Pattern Analysis AppNote 3002

Transcript 9

case (_pat_type)
3'b000: begin // end vector
3'b001: ;// skip scan vector, handled by shift
3'b010: begin // broadside vector
case (_tp_num)
3'b001: begin // timeplate 1 - gen_tp1
3'b010: begin // timeplate 2 - cap_tp1
3'b011: begin // timeplate 3 - cap_tp2
3'b100: begin // timeplate 4 - cap_tp3
3'b011: begin // shift vector for grp1
case (_tp_num)
3'b001: begin // timeplate 1 - gen_tp1
3'b010: begin // timeplate 2 - cap_tp1
3'b011: begin // timeplate 3 - cap_tp2
3'b100: begin // timeplate 4 - cap_tp3

As mentioned above, you need the information in the testbench file to be able to analyze the
pattern file(s). Transcript 10 shows the beginning of a typical pattern file. Notice that the
comments describe how each vector is composed.

Debugging Simulation Mismatches in FastScan 19 of 21

July 03, 2001
AppNote 3002 Pattern Analysis

Transcript 10

//
// Verilog format test patterns produced by Fastscan v8.6_4.8
// Filename : testpat.v.0.vec
// Scan operation : PARALLEL
// Idstamp : v8.6_4.8:b48e:28d7:170:07eb
// Fault : STUCK
// Coverage : 98.94(TC) 96.58(FC)
// Date : Fri Jan 21 09:42:33 2000
//
// Format of broadside vector:
// PI_bits PO_bits MASK_bits Increment_bit Timeplate_bits(3)
PatType_bits(3)
// Format of scan vector:
// SI_bits SO_bits MASK_bits PatType_bits(3)

// Increment_bit - indicates when to increment pattern count

// Timeplate_bits - encodes timeplate number to use
// PatType_bits - encodes pattern type

// Pattern 1
0001011000110011110001100011001011001010100XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXX00000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000001010
1001011000110011110001100011001011001010010XXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXX00000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000001011
10100011001000110001000110111000010100010010100000001110001100100
01000010001X01110100000000000000001110010001001010010001000000000
00111110010101100110101111111111111111111111111111111111111111111
111111111111111111111111111111001
01011101110110011100011011111001011001001010011101100000101011011
10101001000010000101111010011010001011110110011010101001011111111
11111111111111111111111111111111111111111111111111111001
10011000100101001100001001000111111111000010000000000110110010100
00101000000010100010000001110000000000001001000100010101101100001
01111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111010010

When information from the testbench and the pattern file is combined, you can find out exactly
which values are forced on which pins for which patterns. The last bits in the vectors indicate
which timeplate and what type of vector is used. For this specific design, the dummy pins also
illustrate which vector represents which procedure.

20 of 21 Debugging Simulation Mismatches in FastScan

July 03, 2001
Additional Information AppNote 3002

FastScan Commands
Some FastScan commands provide information that is useful when looking at pattern files.
These commands include:
report scan cells - Provides a report on the scan cells within a specific or all scan chains. The
report provides the following information:
- Chain cell index number, where 0 is the scan cell closest to the scan-out pin.
- Scan chain and the scan chain group in which the scan cell resides
- Memory element type (MASTER, SLAVE, COPY, SHADOW, etc.)
- Inversion data
- Gate index number
- Instance name
- Model name
- Cell input and output pins
report scan chains - Provides name of scan chains and scan groups, scan chain input and
output pins, and length of the scan chains.
add lists - The Add Lists command adds pins to a list of pins on which to report, and is useful
when debugging. In the Good simulation mode, the command reports the value of the good
machine. In the Fault simulation mode and ATPG modes, the command reports the value of the
good machine as well as the value of the faulty machine if the two values differ.

Additional Information
Additional information regarding DRC rule violations and other issues related to simulation
mismatches and pattern formats can be found in TechNotes on Mentor Graphics SupportNet.

Debugging Simulation Mismatches in FastScan 21 of 21

July 03, 2001