Debugging Simulation Mismatches
Debugging Simulation Mismatches
Overview
You have already used TetraMAX to create ATPG patterns and now you are at the simulation verification
step.
You have written out these patterns in a serial Verilog format to simulate with a Verilog simulator and
now have simulation miscompares. This application note will point you where to look for help, and provide
you with some more debug hints.
Shift error?
If you are seeing an error during scan pattern 0 ( basic_chain_test ) then it must be a shift
violation that needs to be debugged. See:
Can I Run Multiple Chain Tests in a Row and then Save Them in the Same File?
Product: TetraMAX Type: Q&A Doc ID: 900982
This SolvNet article explains what the serial testbench is doing, shows you how to write out multiple
patterns for chain_test debug to make debug easier, and gives you some additional hints on simulating
with VCS.
For serial testbench simulation, you will get an error like this:
In this case, the failure is caught during the unload of the values captured in the scan cells from pattern 1
capture clock pulse. It's caught during the load of pattern 2, because the load/unload
operation is overapped when the testbench is written out.
The time listed T=16510.00 ns is the time of the unload of the failing scan cell. Since this is the
serial testbench, it's the time the value of this cell is seen at the scan_out port. This means that you
must look at the last capture pulse that happened in pattern 1 to see what was captured into this cell.
You can get the testbench to print this info out for you by adding a simple display statement. To do this,
edit the capture_clockname event to add a display statement to print the time of the capture clock. For
example:
https://solvnet.synopsys.com/retrieve/print/010298.html 1/4
8/25/2014 Hints for Successful Simulation Pattern Debug
event capture_CLOCK;
always @ capture_CLOCK begin
->forcePI_default_WFT;
#110; ->measurePO_default_WFT;
#135 PI[5] = 1; // CLOCK
$display("// %t : capture_clock being pulsed at this time ",$time); //add this
#10 PI[5] = 0; // CLOCK
end
This way you will get the simulation output to look as follows:
At this point, you know that the last capture before the unload of this cell happened at time 4745.00 ns.
This is where you need to look at in the waveforms. We expected to capture a 1, but simulation got a 0.
Now you also need to find out which cell is cell 16 of 0chain. You can find this out by doing a report scan
cell command in TetraMAX:
This will show the full name of the scan cell that you need to zero in on:
In the interactive simulation tool that you use, display the needed pins of this scan cell at the time of the
last capture. As shown below, it shows that the D pin of this cell was at a 0, hence the scan cell captures
a 0 at the capture_clock pulse as shown by the Q
https://solvnet.synopsys.com/retrieve/print/010298.html 2/4
8/25/2014 Hints for Successful Simulation Pattern Debug
Then you can also take a look at the values in the TetraMAX GUI.
You need to get TetraMAX to the same setup as you did when the patterns where create,d by running
build
and drc with the exact same switches and STIL file. Use the GSV to display the failing scan cell by using
"Show-> Scan cell " command
&TEST> set pat external saved_pat.bin //if you saved the patterns in binary format
-Or-
This will simulate pattern 1 and display debug_sim_data as the pin data. Looking at the failing scan cell,
you should be
able to see what is expected to be captured on this cell.
D is #100
CP is #010
Q is #111
Now you would trace the D pin and see why in simulation you got a 0 on it instead of a 1 at the pre_clock
time. This means
you will need to expand on the logic that drives pin D in the GSV and also display the waveforms in the
Verilog simulation.
In the case above, you would trace the NOR gate U1/U1/U1/U4. For it to be a 1 at the pre_clock time, all
https://solvnet.synopsys.com/retrieve/print/010298.html 3/4
8/25/2014 Hints for Successful Simulation Pattern Debug
the three inputs must
be a 0. So, you would trace these inputs in the interactive Verilog simulation until the problem is identified.
Some other hints that could help you debug this. You can turn on verbose messaging for your simulation to
get more info
printed out; for example,
You can also modify the pattern reporting interval via changing the default setting from 5 to another
smaller number,
&define+tmax_rpt=2
To create a extended VCD file, you can also define +define+tmax_vcde at the command line.
This will create a file named sim_vcde.out that could be used for debugging.
Another hint is to always write out the pattern report for your patterns from TetraMAX; for example,
Then, you can look at the failing pattern to see what was loaded into the chain, forced on the primary
inputs, measured at the primary outputs, which clock was pulsed and what was finally unloaded.
Pattern 1 (basic_scan)
Time 0: load 0chain = 0010011000 0111000010
Time 0: load 1chain = 1100000100 1011000001
Time 1: force_all_pis = 1101001101 11
Time 2: measure_all_pos = 0000000000 0000011011 0111110010 0Z
Time 3: pulse clocks CLOCK (5)
Time 4: unload 0chain = 0110111000 0111111111
Time 4: unload 1chain = 0101100101 0100110101
For more debug hints please see the TetraMAX online help topic Troubleshooting Simulation Failures. It's a
complete write up of how to go about debugging this issue.
https://solvnet.synopsys.com/retrieve/print/010298.html 4/4