Debugging Simulation Mismatches in Fastscan: by Geir Eide Last Modified: July 03, 2001
Debugging Simulation Mismatches in Fastscan: by Geir Eide Last Modified: July 03, 2001
Debugging Simulation Mismatches in Fastscan: by Geir Eide Last Modified: July 03, 2001
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.
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
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
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.
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.
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.
4. Timing
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
reported might be due to this problem. For details on this issue, see TechNote 21103,
• 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.
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
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.
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.
/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
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
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.
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
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
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.
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
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
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.
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 15271 for details.
When using this modified procedure file, save the chaintest again, but this time in parallel
format. Below follows parts of a transcript from FastScan:
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.
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.
• 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;
…
…
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
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.
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.
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.
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)
// 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.
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.
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: