Diagnosing Simulation Miscompares Modus

Diagnosing Simulation Mis-Compares in
Modus Test Patterns
Product Version: Modus Version 19.11, Xcelium Version 19.10

November 2019
Copyright Statement
© 2019 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Learn more at Cadence Support Portal - https://support.cadence.com

© 2019 Cadence Design Systems, Inc. All rights reserved worldwide. Page 2
Diagnosing Simulation Mis-Compares in Modus Test Patterns
Contents
Purpose........................................................................................................................ 4
Fault/Failure Introduced into the Xcelium Netlist .......................................................... 4
Audience ...................................................................................................................... 4
Overview ...................................................................................................................... 5
Items to Review before Starting Mis-Compare Analysis .............................................. 6
OPCG and SDF-Annotated Timing Items to Check .................................................. 7
Modus Verilog Patterns ............................................................................................ 8
Compile and Simulate .................................................................................................. 9
Description of the Simulation Mis-Compare Messages Shown in Figure 2............. 14
Using the Modus Diagnostic Tool (Serial Simulation Failures Only) .......................... 16
Import Failures into Modus Diagnostics .................................................................. 17
Diagnose Failures Using Modus Diagnostics ......................................................... 18
Diagnostic Analysis Success .................................................................................. 19
Understanding the Test Pattern Event Order ............................................................. 20
Important Notes for Parallel Verilog ........................................................................ 21
FULLSCAN Event Order ......................................................................................... 22
XOR or OPMISR Compression Conditional Pattern Sequence .............................. 23
Logic Timing for OPMISR with Masking ................................................................. 25
Debugging SO (Scan Output) FULLSCAN Logic Failures ......................................... 26
High-Level Debug Scenario .................................................................................... 26
Example Scan Output Failure Message ................................................................. 27
Detail Information from the TVE-660 Failure .......................................................... 27
Modus Simulation Mis-Compare Analysis: A Detailed Example ................................ 29
Finding the Root Cause of the Mis-Compare ............................................................. 37
Summary of Analysis Actions and Hints..................................................................... 44
XOR and Smartscan Serial Pattern Failure Analysis Scenario ............................... 46
A Few Checks Before Analysis ............................................................................... 46
Logic Pattern Timing for XOR- with Masking ............................................................. 48
Bonus Debug Information ....................................................................................... 50
Summary.................................................................................................................... 51
Support ...................................................................................................................... 51
Feedback ................................................................................................................... 51

Purpose
This application note illustrates how to diagnose Modus Verilog pattern mis-compares. If
you are not familiar with how to compile and simulate Modus Verilog patterns, see the
“Simulating Modus Verilog Patterns” application note.
The information in this application note provides you with the background knowledge
and tools to debug your simulation mis-compares. Requirements for your specific
design may dictate procedures slightly different from those described here.
Modus leads the industry in providing volume and fault-isolation diagnostics for patterns
that fail on a hardware tester. This document will introduce you to Modus Diagnostics
but does not cover the robust set of failure-diagnostic features that are available. For
information on this topic, contact your Cadence representative or download the Modus
Diagnostics RAK.
Fault/Failure Introduced into the Xcelium Netlist

The failure analysis example shown in this document is from the DELAY_SDF_TIMED
Lab within the Modus Advanced ATPG RAK. This is a Compression test mode with
OPCG clocking.
The DTMF netlist that is imported into the Xcelium simulator has been edited to cause a
few simulation mis-compares. You can download the ATPG RAK and insert this fault to
gain a hands-on experience.
Within module “results_conv_602”, we introduced this bug (An XNOR “A” input
stuck-at-1)
// XNOR2X1 g18241(.A (out_p1[5]), .B (out_p2[5]), .Y (n_134));

XNOR2X1 g18241(.A (1'b1), .B (out_p2[5]), .Y (n_134));
// The hierarchical Port instance name with the stuck-at-1 failure:

dtmf_chip.DTMF_INST3.RESULTS_CONV_INST.g18241.A
Audience
All Modus users who have Verilog simulation mis-compares.

Overview
Cadence Modus produces WGL, STIL, TDL, and Verilog output formats. Before
releasing WGL, STIL, or TDL to a hardware tester, engineers should simulate the
patterns via a Verilog simulator. Sometimes, simulation of the Verilog pattern set results
in mis-compare messages. When this happens, you must identify the cause of these
mis-compares and remedy the problem before releasing the test patterns.
This document provides advice and examples on how to identify the root cause of mis-
compares within a Modus pattern set. If you are not familiar with simulating Modus
patterns and are unaware of built-in debug features within Modus Verilog, first read the
“Simulating Modus Verilog Patterns” application note. That application note provides the
following information:
• How to compile your device under test and all the technology libraries
• How to compile the Modus Verilog testbench
• How to elaborate the Modus testbench
• How to reference a specific test pattern file
• Information about built-in debug features within Modus Verilog and how to invoke
those features
• Information about useful NC simulation parameters
• The SDF timing file and how to annotate that timing data for simulation

Items to Review before Starting Mis-Compare Analysis

This section contains suggestions for items to review and verify before beginning
analysis of simulation mis-compares.
Before diagnosing any simulation mis-compares, review the Modus

verify_test_structures log file. Modus has the most robust DFT checking in the
industry. Look for “Severe” level messages, especially those messages that identify
problems with the clock or scan operations. Here are a few TSV messages that should
be investigated.
• TSV-332: A channel mask shift register element <name> was

corrupted (compression logic only)
• TSV-331: An observable latch or flop <name> was corrupted

by the Channel Mask Load sequence. (compression logic only)
• TSV-310: One or more clock inputs are at “X” in the Test

Generation logic state.
• TSV-059: Potential Race condition in clock gating logic.
Debug using the easiest scenario: Zero-delay simulation on using FULLSCAN test
mode patterns using parallel-pattern output from write_vectors.
• Avoid debug with serial patterns, SDF annotation, or XOR test modes, if you can.
• Unit-delay simulation is not recommended.
For SDF timing annotated failure, are you seeing Expect <value> Simulate “X”?
• If yes, look for timing-violation messages in the simulation log. Any messages
result in the FF output being set to “X”. Fix these violations.
• Note that your SDF file may contain negative numbers. This may require a
compiler directive to select Negative Timing Check (NTC) code within the
technology library cells.
o SDF-annotated timing and negative timing checks are addressed in the

“Simulating Modus Verilog Patterns” application note.

Zero-delay simulation may cause event order problem. The output UDP Verilog models
may get updated on a clock edge AND propagate downstream to another Latch or FF
without the need to advance time in the simulator. This will look like you have simulated
a double-clock pulse.
• Ensure that you are using the xmelab/ncelab parameter “-

seq_udp_delay <int>ps”.
An Example is shown in Figure 1.
Bidirectional pin failures (mis-compare)
• Verify whether Modus is applying a “Z” input stimulus or trying to apply a pull-up
or pull-down . Look near the top of any Verilog pattern file for “203 0”, “203 1”,
or “203 Z”. This will tell you whether Modus is applying a weak-0, weak-1, or “Z”
stimulus when it expects the chip to drive the bidirectional pin.
• The Modus ATPG parameter for controlling these ‘pull’ values applied to
bidirectional pins is “globalterm”.
OPCG and SDF-Annotated Timing Items to Check

If you are running an OPCG check to verify that the PLL internal clock pulses actually
exist in simulation:
• The Modus pin assign file will have a “cutpoint” that defines this internal clock
source. Probe this location and ensure there is a clock pulse generated.
• Check the failing scan chain FF clock input.
o Make sure that it is getting a clock pulse if that is what Modus expects.
o Compare the clock pulse(s) you see in the simulation with the FF clock
input from Modus. (Make sure you have the correct Modus pattern
selected – Discussed below)
• If you do not see a clock being generated during the simulation, check the
simulation log file for “lock”. In most PLL models, there is a message stating that
the PLL has locked and is generating the internal high-speed clock. You may see
a message that says that the lock is lost. This is bad.

Hint: If you have “no PLL lock” or “lock is lost” message, check the reference
OSC input to ensure that it is being applied in every tester cycle. Any gaps can
cause the PLL to not lock or lose its lock.
If you have imported SDF timing data into Modus and Xcelium, look at the import logs to
make sure that the timing data for the library cells has been imported.
If you are running SDF timing annotation and you are getting “Expected 1 or 0” and
“Simulated X”, check for timing-violation messages prior to the mis-compare. A timing
violation is most likely the root cause.
• When a timing violation occurs, the Register/FF output is set to X.
• During simulation debug analysis, you will be tracing back an X that most likely
leads to a Register/FF.
• That X-source FF should have a timing violation message on it within the

simulation log.
Modus Verilog Patterns

Modus, by default, outputs the Verilog test patterns into the following directory:
<WORKDIR>/testresults/verilog
There is one “mainsim.v” file and one or more vector files that are created for each
test mode. All the file names begin with “VER.<testmode>”. Scan confidence patterns
are placed into a file with “scan” as part of the name. Logic patterns are placed into a
file with “logic” as part of the name. The following is an example of a Verilog file set
for a Compression Decomp OPCG test mode (One logic pattern set, one scan pattern
set).
VER.COMPRESSION_DECOMP_OPCG.data.logic.ex1.ts2.verilog
VER.COMPRESSION_DECOMP_OPCG.data.scan.ex1.ts1.verilog
VER.COMPRESSION_DECOMP_OPCG.mainsim.v

Compile and Simulate

Figure 1 below demonstrates simulating the bad netlist test case from the
DELAY_SDF_TIMED Lab within the Modus Advanced ATPG RAK. Notice that you
invoke the Verilog testbench failure report feature “+FAILSET”.
Figure 1: xrun compile and simulate
xrun -log xrun_bad_netlist.log \

+simvision \
-delay_mode zero -seq_udp_delay 50ps -nospecify \
-timescale 1ns/1ps -override_timescale \
-access +rwc \
VER.COMPRESSION_DECOMP_OPCG.mainsim.v \
../../../dtmf_chip.test_netlist_bad.v \
-v ../../../LIBS/verilog/include_libraries_sim.v \
-incdir ../../../ \
+HEARBEAT +FAILSET \
+TESTFILE1=VER.COMPRESSION_DECOMP_OPCG.data.scan.ex1.ts1.verilog \
+TESTFILE2=VER.COMPRESSION_DECOMP_OPCG.data.logic.ex1.ts2.verilog
Failures are reported in the log file and in the diagnostic +FAILSET file:
VER.COMPRESSION_DECOMP_OPCG.data.logic.ex1.ts2.verilog_FAILSET
The +FAILSET argument will produce CPP failure data for each mis-compare (See
Figure 4). For serial-pattern mis-compares, see “Using the Modus Diagnostic Tool”
section below.
Diagnostic analysis works with FULLSCAN and Compression. If your design has
Smartscan, you will first convert the failing Smartscan cycle to an XOR Compression
cycle using convert_smartscan_failures.

Figure 2: Sample of the parallel simulation log output
INFO (TVE-201): Simulation complete on vector file:

INFO (TVE-206): The number of good comparing vectors for

the file just completed is 21190
INFO (TVE-205): The number of miscomparing vectors for the

file just completed is 0
INFO (TVE-200): Reading vector file:

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

at Time: 190980000.00 ps Expected: 0 Simulated: 1
During Scan Cycle #: 15 Internal Unload =
COMPACTOR.compressor.g_6.g44.__iNsT1.01; Observe Register
(OR) = 48;

(OR) = 51;


the file just completed is 3127627

file just completed is 17

Figure 3: Sample of the serial simulation log output


the completed is 1440

completed is 0
INFO (TVE-200): Reading vector file:


at Time: 285402000.00 ps Expected: 1 Simulated: 0 On SO:
port_pad_data_out[0] During Scan Cycle #: 15

port_pad_data_out[1] During Scan Cycle #: 15

port_pad_data_in[3] During Scan Cycle #: 15

INFO (TVE-206): The number of good comparing vectors just

completed is 212515
INFO (TVE-205): The number of miscomparing vectors just

completed is 29

Notes for figures 2 and 3:
• The SCAN patterns pass. This is good.
• There are 17 mis-compares in the parallel logic pattern set and 29 for serial
simulation.
o The different failure count is okay.
• TVE-650 mis-compare message:
o If a data output fails, you will see TVE-650.
o The measure event takes place while the chip is in functional mode, not in
scan shift mode.
o There is no scan shift operation done before the measure.
 The functional capture clock is issued, and data output values are
measured.
• The failures in figures 2 and 3 are TVE-660.
o These are scan chain FF mis-compares.
o With parallel patterns, you are measuring the expected values on the scan
FF. There is no scan chain shift offset to consider.
 There can be a scan shift offset if your design has multiple-bit

register models. If this is true, you will see a TVE message from
write_vectors.
 Also look for the -multibitscanshifts parameter of

write_vectors.

• For serial scan shift simulation failures:
o Note the CYCLE and SO pin.
 Failure analysis will involve finding the scan chain and bit position
of the FF instance for schematic display.
o You will need to trace back in time through all the scan shift clock pulses
to find the functional capture clock.
Hint: Within the waveform display, trace backwards in time via the SE pin.
The clock pulse when the SE is inactive is the functional capture clock.
o Note that the failures shown above are CYCLE 15.
 This is a Compression test mode. An internal stump scan chain will

feed more than one SO pin; thus, you know the failing scan chain
bit position but do not know the failing scan chain.
• For parallel simulation:
o The “write_vectors -includelatchnames yes” parameter will

provide more information about the specific scan FF that is failing. This
results in the internal observe net being output as part of any SO
simulation failure message.

Description of the Simulation Mis-Compare Messages Shown in

Figure 2
• pattern: 1.2.1.11.9.9
This is the ATPG pattern number. You will need it when you invoke the Modus
schematic to see the logic values that are predicted by ATPG.
You can reference the “pattern” display variable in your simulation waveform
dump. With this value displayed, you can align your simulation results with
ATPG.
• Time: 190980000.00 ps
Note the time of the mis-compare. This time will differ between serial and parallel
simulations.
When you re-simulate to dump waveform values, you only need to simulate
slightly past this point.
Note: If you have initially run multiple TESTFILE pattern files, you can rerun and
simulate only the failing file. Removing TESTFILEs will affect the failing
simulation time that is reported.
Note: For parallel simulation, you may see that the failing net being measured
transitions at the point in time of failure. Move your time flag slightly earlier.
o In parallel simulation, you FORCE a new value onto the scan chain bit
positions for the next ATPG pattern.
o This will override the value in the chip and make it look like the FF’s
change value without any clock pulses.
• Scan Cycle #: 15
The CYCLE number reported on SO failures is the scan chain bit position relative
to SCAN OUT. The SO measure pin and scan chain register number (an “internal
to ET only” concept) will tell you which scan chain the failing FF is on.
o For parallel simulation, remember that you are measuring an internal net
driven by the scan chain FF. The measure is not done at the SO pin.

o For serial scan simulation, you will see all the scan chain shift clocks up to
the point of failure. You will want to work your way forward in time to find
where the SE is inactive and the clock pulse is the functional clock.
• Internal Unload = <instance name> Observe Register (OR) = <int>
For Compression test modes, there can be hundreds of internal scan chains.
This entry provides the scan output of that channel and reports the scan chain
number.
Use this information to find the scan chain and bit position of the failing FF within
the Modus schematic.
If the debug variable “-includelatchnames yes” has not been used, the internal net
will not be printed as part of the message. When this happens, there are several ways
to identify the FF scan chain instance. Here are three methods (more details given
below):
• Look at the log file for “report_test_structures reportscanchain=all”.

The “CYCLE” entry in the mis-compare message is the “ObserveBit” column
within the report.
• Bring up the Modus schematic via “WINDOWS > ANALYSIS CONTEXT”. From
the SCHEMATIC window, you can select “VIEW > SCAN BIT” to bring up the FF
instance. In the schematic, you can find the FF instance name.
• If you are running parallel Verilog simulation, the instance name is within the
mainsim.v file. You can find it manually based on the CYCLE entry or add a
“write_vectors” parameter to report the instance name.

Using the Modus Diagnostic Tool (Serial Simulation

Failures Only)
Figure 4: Serial simulation CPP failure format produced via +FAILSET parameter
Chip dtmf_chip pad port_pad_data_out[0] pattern 1.2.1.11.9.9 position 15 value 0
Chip dtmf_chip pad port_pad_data_out[1] pattern 1.2.1.11.9.9 position 15 value 1
Chip dtmf_chip pad port_pad_data_in[3] pattern 1.2.1.11.9.9 position 15 value 0
Each mis-compare in your simulation run will produce a CPP (Chip-Pad-Pattern) failure
entry. The above figure shows only 3 of the 29 from your serial simulation example. Use
the +FAILSET failure file as an input to the Modus diagnostic tool set.
The CPP “position” keyword is the FF bit position on the scan chain. This goes from
1-to-n. The FF that directly drives the scan output pin is position 1. The “position”
keyword matches the Modus scan chain report.
If the CPP has the “offset” keyword instead of “position”, the bit position relative to
the scan out pin is 0 to n-1. The scan chain FF next to the scan out is bit position 0.
When the “offset” keyword is used, you will need to account for this if you reference
the Modus scan chain report. The scan chain structure “Observe Bit” entry is reported
from 1 to n relative to the scan output pin.
If the entry is “-1”, the failure is observed on a primary output pin and is NOT part of a
scan chain shift (Scan_Unload) operation. This operation is called a “Measure_PO”
event.

Import Failures into Modus Diagnostics

Note that the failure data from Xcelium +FAILSET is no different from the failure data
you get from a hardware tester.
• Hardware tester failure data may report each failure at a CYCLE number. For
this, write_vectors creates a “cyclemap.*” file, which is used to map the
tester cycle from each failure back to the ATPG pattern number.
• Modus provides a function called convert_failures_to_cpp.pl to do this

mapping.
o You can find this in the Modus installation.
o You can learn more about using this script in the Modus Diagnostics RAK.
read_failures -testmode COMPRESSION_DECOMP_OPCG \

-failset atpg_rak_fails \
-importfile
testresults/verilog/COMPRESSION_DECOMP_OPCG_SERIAL/VER.COMPRESSION_DEC
OMP_OPCG.data.logic.ex1.ts2.verilog_FAILSET
INFO (TFL-055): Failset atpg_rak_fails created containing 29

failures on 1 device.
29 specifications read 0 failed 0 ignored [end TFL_055]
In the TFL-055 message above, expect no ‘failed’ imports. Analyzing ‘failed’ imports is
discussed in the Modus Diagnostics RAK.

Diagnose Failures Using Modus Diagnostics

diagnose_failset_logic -testmode COMPRESSION_DECOMP_OPCG \
-failset atpg_rak_fails \
-testrange all \
-reportconfidence yes
Modus reads in the fail set from ‘read_failures’ and simulates the failure results
against possible faults in the design. The diagnostic results are reported. It is literally
that easy.
The log file entry below has been edited to fit the page.
Candidates for defect 1, explaining as many as 15 out of 15 unexplained

cycles (29 out of 29 failure(s)):
first first
fault contributing conflicting
index score TFSF TFSP TPSF sequence sequence
134366 100 15 0 0 1.2.1.11.9 ISA1
Net name: DTMF_INST3.RESULTS_CONV_INST.out_p1[5]

Cell Instance: dtmf_chip.dtmf_large_recvr_core_3.results_conv_602.XNOR2X1
Summary of Top Scoring Fault Candidates for the defect(s) identified.
---------------------------------------------------------------------
Found 1 defect(s) that explain 15 out of 15 cycle(s). (29 out of 29 failure(s))
Defect Top Explain Percentage Cumulative Percentage Total Top

Number Score Cycles Explain Cycles Explain Cycles Eq Faults Scoring Flt
------ ----- ------ ---------------- --------------------- --------- ----------
1 100 15 100.00 100.00 1 {ISA1: 13436}

Diagnostic Analysis Success

For this example, diagnostic analysis has reported a 100% score.
• TFSF = Tester Failure, Simulator Failure. Every tester failure (in this example,
the Xcelium mis-compare) is predicted by the Modus diagnostic simulation of the
fault location identified.
• TFSP = Tester Fail, Simulator Passed. For the given fault, anything other than 0
says there were reported tester or simulation failures that are not predicted by
the given fault.
• TPSF = Test Passed, Simulator Failed. For the given fault, diagnostics predicted
there would be a test pattern mis-compare (SF); yet the tester reported no mis-
compares (TP).
• Any TFSP and TPSF entries tell you that the fault identified does not completely
explain all failures that are reported in the fail set. This reduces your SCORE.
• “Cell Instance” points exactly to the bug you placed into the netlist for Xcelium.
See the section “Fault/Failure Introduced into the Xcelium Netlist”.
• ISA1: 13436 = Input Stuck-at-1 and the fault index number. That is the bug you
placed into the netlist.
o You can use the fault index number “13436” in the Modus schematic to
view the fault location.

Understanding the Test Pattern Event Order

Modus applies a default event order and timing set to the patterns. The order of events
will vary based on the scan logic you are using and the type of test patterns being
applied. You should know and understand the order of events. Keying off major events
in the waveform display, such as the capture clock and when the SE rises and falls, will
help with your analysis.
Hint: Look at the comments at the top of your Verilog mainsim.v file. You will see the
two timing sets, one for “TEST” and one for “SCAN”. The event sequence and timing for
static patterns is provided along with the names of all your important control and clock
pins. An example from the Advanced ATPG RAK is given below:
// TEST PERIOD...............20.000 TEST TIME UNITS...........ns
// TEST PULSE WIDTH.........2.000
// TEST STROBE OFFSET..18.000 TEST STROBE TYPE........edge
// TEST BIDI OFFSET............0.000
// TEST PI OFFSET...............0.000 X VALUE...................X
//
// "DFT_mask_clk" (PI # 2)
// TEST OFFSET................2.000
// SCAN OFFSET...............4.000 PULSE WIDTH.............2.000
//
// "OPCG_LOADCLK" (PI # 5)
// TEST OFFSET................2.000
// SCAN OFFSET...............4.000 PULSE WIDTH.............2.000
Hint: write_vectors ‘scanXXX’ and ‘testXXX’ parameters allow you to adjust the
timings of when pins are stimmed, clocks are pulsed, and outputs are measured. You
cannot change the event order.

Important Notes for Parallel Verilog

Parallel Verilog simulation applies the following event sequence:
1. Measure the expected (you observe an internal net for every bit of every scan
chain).
2. Issue a #0.0 delay to advance the event wheel within the simulator.
3. Apply the Stim values for the next pattern. (This is applied to the net that drives
the SI port of every scan chain bit.)
WHEN YOU LOOK AT THE NCSIM WAVEFORM, you may see that the measure net
immediately transitions the value right at the time when it is being measured. This is
okay. The measure always takes place before you apply the Stim for the next pattern.
Also note whether there are different libraries for ATPG (Modus) and the Verilog
simulator. Sometimes, the library cell net identified for parallel stimulus/observe is not
the correct net within the simulation model. If the net identified by ATPG does not exist
in the simulation model, you will fail with an elaboration error.
1. If you suspect this to be true, one option is to ask for port names.
2. Another option is to ask write_vectors to offset the parallel stimulus by two or

more bits.

FULLSCAN Event Order

This section presents the event order for FULLSCAN and Compression logic when you
are applying static ATPG patterns. The basic FULLSCAN event order is as follows:
1. Set scan mode (Look for the scan enable pin to toggle).
2. Scan load.
3. Apply new PI state (Turn off scan enable, Set any other pins desired).
4. Apply functional capture clocks (perhaps multiple).
5. Measure POs (optional).
6. Set scan mode.
7. Scan unload and measure the SO pins.
o During scan unload, you also Scan_Load in the next pattern. This is called
‘scan overlap’. It saves time on the tester.
Steps 1-2 and 6-7 are applied via “scan_cycle”. Steps 3-5 are applied via
“test_cycle”.
scan_cycle and test_cycle are timing templates that define an orderly event
sequence. These templates map nicely to hardware testers (ATE). The timing in these
templates are described within comments at the top of the Verilog mainsim.v file as
shown in the event order section above.

XOR or OPMISR Compression Conditional Pattern Sequence

Each test pattern that is applied may or may not require “X” state masking. In addition,
the OPMISR logic requires the output values to be captured into a MISR while the XOR
Compression logic does not. Thus, the explanation of how the patterns are applied
contains conditional “IF” statements.
Set scan state (apply SE pins)
IF masking is required
Set mask load state (apply CMLE pins)
Scan load the mask register data
Go back to scan state (reset any SE pins, as needed)
ENDIF
Scan unload
Measure at SOs for XOR Compression
Scan chain values into MISRs for OPMISR
Apply values to CME pins (Mask the scan chain pin), as needed. Masking
is done or not done for every scan shift.
IF OPMISR
IF MISR is to be observed
Set MISR observe state (apply MRD pins)
Observe MISR bits at MO pins in one cycle
Return to scan state (reset any SE pins, as needed)
ENDIF

IF MISR is to be reset then DO
Set the MISR reset state (apply MRE pins)
Apply the MISR reset clock (MRST)
Return to the scan state (reset any SE pins, as needed)
ENDIF
END
Return to TG state (if there are any TC pins, apply them in the scan exit
sequence)

Logic Timing for OPMISR with Masking

Again, it is important to know the event order within the test patterns. This will help you
navigate the waveform display and identify critical operations such as masking, scan
shift, etc.

Debugging SO (Scan Output) FULLSCAN Logic

Failures
High-Level Debug Scenario
1. A TVE-660 simulation mis-compare message identifies a failing FF.
2. Display the failing FF and surrounding logic on the Modus schematic and apply
the failing pattern.
a. The TVE-660 message gives you the observe scan chain and bit position.
Use this in the Modus schematic to pull up the failing scan FF.
b. Set the failing pattern number from TVE-660 to see the logic values that
Modus ATPG is predicting.
3. Via the Modus schematic capture, create a “watchlist” of signals within the failing
FF cone of logic. This list will be imported into the NC simulator.
4. Invoke Xcelium simulation, add in the watchlist, and simulate to produce a

waveform dump. Compare the logic values that Modus is predicting for the FF
and its surrounding logic with the values obtained via the simulation.
a. The point in time at which you want to do this initial comparison is when
the functional capture clock is issued. (The scan enable signal is NOT
active.)
Note: To translate the Modus “watchlist” into a set of probe points, you will use a
Tcl program called “watch2probe.tcl”. This TCL program is in the installation
“scripts” directory.
5. Identify where the predicted versus simulated logic values differ and trace that
difference through the logic and possibly across time.
a. Keep in mind that if you find nothing that mis-compares at or around the
FF at the functional clock capture time, the failure may be occurring during
scan shift. This means you would have to trace the scan chain and
advance through time to show the captured FF value, as it is shifted
toward the scan output pin.
b. When you find a difference and trace that logic path, you will want to add
this new logic to your “watchlist” and rerun the simulation with this updated
list.
Example Scan Output Failure Message

WARNING (TVE-660): SO mis-compare at pattern: 2.1.1.2.1.6
at Time: 16025600000
Expected: 1 Simulated: 0 SO: scan_out[0]
On net: DTMF_INST.RESULTS_CONV_INST.lower770.n_22
During Scan Cycle/Bit #: 271 Measure Register: 1
Within the Modus Schematic request SCAN BIT observe

register 1 bit 271.
Detail Information from the TVE-660 Failure

− The “SO” entry tells you that the failure was during a scan output operation.
− The scan output pin is scan_out[0].
− Cycle/Bit #: 271 tells you that the 271st FF from the scan output pin is the state
device that captured the bad logic value during the functional capture portion of
the test.
o The FF that directly drives the SO pin is reported as “Cycle 1”; therefore,
your failing FF is 271st from the scan output.
 With “write_vectors includenetnames=yes”, the mis-

compare message will contain the name of the net being driven by
the FF at bit position 271. This is for parallel Verilog output only.
 If you do not have a net name from the mis-compare message but
are running parallel Verilog simulation, you can look at the TVE-
660 message within your Verilog mainsim.v file to identify the
appropriate “part_MLs” variable entry. “part_MLs” is a vector
variable where each bit is mapped to an internal signal.

Here is an example of a part_MLs (Measure latch instance being

observed within mainsim.v). In this example, notice that there can be “!”
inversion. Do NOT count on the part_MLs index (in this example, ‘271’)
being the scan chain bit position.
part_MLs_1[271] =
!dtmf_chip_inst.DTMF_INST.RESULTS_CONV_INST.lower770.n_22
 If you have serial Verilog, you will not have an internal net or FF
name within the mainsim.v file. You will map the mis-compare
message information to the output from
report_test_structures.
Figure 5: report_test_structures log file data
report_test_structures testmode=FULLSCAN reportscanchain=all
Position LTYPE Blk Index/IO ObserveReg ObserveBit Block Name
------- ------ ------------ ---------- ---------- ----------
1 rDFF_Cs 9577 +- 1 272
DTMF_INST.RESULTS_CONV_INST.lower770.\dout_reg[0]. i3.dff_primitive
2 rDFF_Cs 9622 -+ 1 271
DTMF_INST.RESULTS_CONV_INST.lower770.\dout_reg[1]. i3.dff_primitive
Figure 5 shows failing bit 271 for your failing scan chain in the “ObserveBit” column.
The header information in the report names the scan output pin. Note that this report will
provide the FF instance name, and not a net instance driven by the FF.
Note that in the Modus schematic, you can request Observe Register 1 scan bit 271,
and it will display this FF instance.

Modus Simulation Mis-Compare Analysis: A Detailed

Example
This section walks you through the process of using Modus schematic and Xcelium
waveform dumps to find the root cause of a simulation mis-compare. You will use the
parallel simulation Compression_Decomp failure data from Figure 2.
o This example is from the DELAY_SDF_TIMED lab within the Advanced ATPG
RAK.
A. The first mis-compare failure from Figure 2:

(OR) = 48;
B. Use the Modus GUI and schematic to find the failing FF instance:
modus -gui
In the Main window: WINDOW – ANALYSIS CONTEXT
In the Analysis Context Window select the test mode:

COMPRESSION_DECOMP_OPCG
Figure 6: Modus Analysis window
Dock the Analysis window into the main GUI by selecting the green arrow on the
right.

C. Open the Modus schematic.
Select the failing scan FF from the TVE-660 mis-compare message.
o Select VIEW > SCAN BIT, and then select Observe and enter Register
48, Bit Position 15.
Figure 7: Modus Schematic window with View Scan Bit

In Figure 8 below, note that the Information window Scan Path Data confirms
Observe Register 48 and Bit Position 15.
Also note that the Information window provides the scan FF instance name.
Figure 8: Modus Schematic window with the failing scan FF

Hint: Within the schematic, you can select the enclosing block and with a right-
click, implode to collapse. Find the technology cell for the ATPG RAK. This is cell
name SDFFRHQX1 and instance:
DTMF_INST3.RESULTS_CONV_INST.high_reg_2_.
D. Within the Modus schematic window, bring up the failing pattern:
VIEW > TEST DATA > TEST VECTORS
In the TEST VECTORS window, expand the patterns to 1.2.1.11.9.9 (from

message TVE-660).
o Highlight the clock pulse. The Information window will place brackets
around this clock pulse event.
Select VIEW > CIRCUIT VALUES.
o When you place the mouse over the FF ports the Information window, it
will show the ATPG values.
o The value within the brackets is the pattern you highlighted. If this is a
clock pulse pattern, the value is after the clock pulse has been simulated.
The TVE-660 failure message says “Expected: 0 Simulated: 1”.
o Place the mouse over the FF output port and verify that ATPG expects 0.

E. Simulate the logic patterns and dump the waveforms.
Figure 9: xrun compile and simulate with GUI for waveform debug
xrun -log xrun_bad_netlist_debug.log \
-delay_mode zero -seq_udp_delay 50ps -nospecify \
-timescale 1ns/1ps -override_timescale \
-access +rwc \
VER.COMPRESSION_DECOMP_OPCG.mainsim.v \
../../../dtmf_chip.test_netlist_bad.v \
-v ../../../LIBS/verilog/include_libraries_sim.v \
-incdir ../../../ \
+TESTFILE1=VER.COMPRESSION_DECOMP_OPCG.data.logic.ex1.ts2.verilog -gui
This is the same script as Figure 1 with minor changes.
o Add “-gui” - You want to interactively request probe points for waveform
debug.
o Only include the failing ‘logic’ pattern file.
“-access +rwc” is important. This allows you to probe internal to the chip.
In the Design Browser, select the “pattern” variable and dump it to the
waveform.
o This is the ATPG pattern number from the TVE-660 or TVE-650

message.

As shown in Figure 10, expand the Design Browser hierarchy to find the SDFF
technology cell instance obtained from the Modus schematic
DTMF_INST3.RESULTS_CONV_INST.high_reg_2_.
Highlight the SDFF port “Objects” (Highlighted in the right pane).
Dump these signals to the Waveform viewer (The Waveform icon at the top
right).
Hint: At the bottom right, you will see that you asked to NOT display internal
signals. You get port “Objects” only.
Figure 10: Find the failing SDFF in the Xcelium Design Browser

When you re-simulate the patterns with only the logic pattern set, the failing time
changes but all other information remains the same.
WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9 at

Time: 185820000.00 ps
Expected: 0 Simulated: 1 During Scan Cycle #: 15
Internal Unload = COMPACTOR.compressor.g_6.g44.__iNsT1.01;
Observe Register (OR) = 48;
Figure 11: Waveform dump and Modus schematic

In the SimVision CONSOLE window (not shown), you must type “run” after selecting
items for the waveform display. This will simulate the logic patterns and dump values
into the Waveform viewer as shown above.
In the Waveform viewer, you can expand the names to Path.Name (Look for the down
arrow in the left pane, to the right of the Path.Name column heading and just to the left
of the Curser column heading).
In the waveform display, highlight the SDFF Q output port and drop the TimeA flag to
the failing time 185820000.00 ps.
o Verify that the Q logic value differs from the Modus schematic expect value.
Look earlier in time to find the functional capture clock (Hint: The SE signal is inactive =
0)
Notice that the Xcelium waveform shows the Q output going 0-1 at the functional
capture clock.
o This is the TimeA flag drop shown above.
o When you look at the Q output in Modus, it stays = 0 (This confirms your mis-
compare).

Finding the Root Cause of the Mis-Compare

Modus schematic: ATPG does NOT expect a functional clock pulse. The waveform
above shows a capture clock at TimeA.
o This clock input port is highlighted above in the Modus schematic.
o Trace this difference. Why does ATPG think there is no capture clock?
The failing scan FF clock input port is driven by 2-input AND cell
DTMF_INST3.RESULTS_CONV_INST.RC_CG_HIER_INST126.g12.
In Modus:
• The "A" input port is receiving a clock pulse.
• The "B" input is 0.
• You know that Xcelium sees a clock; thus, trace "B".
A. Trace the “B” input of AND cell

DTMF_INST3.RESULTS_CONV_INST.RC_CG_HIER_INST126.g12.
This input is driven by TLATNXL:
DTMF_INST3.RESULTS_CONV_INST.RC_CG_HIER_INST126.enl_reg
The clock input to TLATNXL is receiving a clock pulse.
The "D" input to TLATNXL is 0: Logic: X XX00 000[0] 0000.
You know that Xcelium sees a clock; thus, trace "D".
B. Trace the “D” input of TLATNXL. It is driven by OR2X1:
DTMF_INST3.RESULTS_CONV_INST.RC_CG_HIER_INST126.g7
Modus has both inputs = 0.
You are going to have to dump these values in the SimVision waveform to see
which input differs.

C. Bring up OR cell
DTMF_INST3.RESULTS_CONV_INST.RC_CG_HIER_INST126.g7 onto the
Xcelium display.
Dump the "A", "B", and "Y" ports to the waveform.
From the SimVision CONSOLE: reset, run 186 us
D. At the rising edge of the capture clock, the "B" input = 1. Trace the "B" input of
the OR in Modus.
In step B above, Modus expects the “B” input port = 0.
Hint: In Modus, if you highlight a NET and right-click, you can PROBE. This will
place a color highlight on the net so that it is easier to trace.
OR2X1 input port "B" is driven by another OR2X1:
DTMF_INST3.RESULTS_CONV_INST.g5965
Modus has both “A” and “B” inputs = 0.
You are going to have to dump the waveform for this cell to see which input
differs.
E. In the SimVision schematic, trace the "B" input of the first OR cell.
Dump the "A", "B", and "Y" ports to the waveform of g5965.

Figure 12 below shows this waveform because with 0-delay, it looks like both “A”
and “B” inputs = 1 at the leading clock edge. Actually, as shown, only the “A”
input = 1.
Hint: By highlighting the signals as shown and repeatedly using the big BLUE
arrow EDGE search icon at top-left side, you can see the event order.
This figure shows the clock has gone 0-1 and only the “A” input = 1.
Figure 12: SimVision waveform for OR cell DTMF_INST3.RESULTS_CONV_INST.g5965
F. Trace the "A" input of g5965.
You find cell NOR2BX1, instance DTMF_INST3.RESULTS_CONV_INST.g5992.
Dump the ports for g5992 into the SimVision waveform.
In the SimVision waveform, at the rising edge of the capture clock:
Inputs "AN" = 1, "B"= 1
The Modus schematic has:
Inputs "AN" = 0, "B"= 1

G. Trace the "AN" input of g5992.
You find cell NOR2XL, instance DTMF_INST3.RESULTS_CONV_INST.g6007.
Dump the ports for g6007 to the SimVision waveform.
H. From the SimVision CONSOLE: reset, run 186 us
In the SimVision waveform, at the rising edge of the capture clock:
Inputs "A" = 0, "B"= 0
The Modus schematic has:
Inputs "A" = 0, "B"= 1
I. Trace the "B" input of NOR cell g6007.
This gets interesting. You have reached another scan FF:
DTMF_INST3.RESULTS_CONV_INST.state_reg_2_ Cell Name: SDFFRHQX4
A waveform display of cell SDFFRHQX4 shows the clock input has TWO pulses.
- Modus also expects two functional clock pulses.
The waveform display of cell SDFFRHQX4 shows DATA input=0 for both pulses.
- Modus expects DATA input=1.
J. Trace the DATA input of SDFFRHQX4 cell state_reg_2_.
The DATA input is driven by DTMF_INST3.RESULTS_CONV_INST.g17698.
- Cell type NAND3BXL
Modus has inputs "AN"=0, "B"=0, "C"=1 at the clock edge.
SimVision has inputs "AN"=0, "B"=1, "C"=1 at the clock edge.

K. Trace the "B" input of NAND3BXL cell g17698.
You find cell NAND3BXL, instance

DTMF_INST3.RESULTS_CONV_INST.g18237.
Modus has inputs "AN"=0, "B"=1, "C"=1 at the clock edge.
SimVision has inputs "AN"=0, "B"=0, "C"=0 at the clock edge.
Since you have been highlighting the nets as you trace back, you see that the "B"
input is driven from the SDFF you just traced through.
L. Trace back the "C" input port of g18237.
Hint: Change the highlight color for this net to visually keep it separate from
where you have already traced.
You encounter another scan FF:
DTMF_INST3.RESULTS_CONV_INST.state_reg_3_
Modus expects DATA=1 at the capture clock.
SimVision shows DATA=0.
M. Trace the SDFF DATA input to DTMF_INST3.RESULTS_CONV_INST.g17707.
Cell type: OAI211X1
Modus expects A0=1, A1=1, B0=1, B1=1 at the capture clock.
SimVision shows A0=1, A1=0, B0=0, B1=0.
Another interesting decision point. Which mis-matching input do you trace?
Hint: Try tracing back two or three levels on each input to see if there is logic
driven by any of the SDFF that you have already traced. If you find feedback, do
NOT trace that input.
Following the above Hint, you see that B0 and B1 have the SDFF instance
DTMF_INST3.RESULTS_CONV_INST.state_reg_3_ as part of their logic
cone.
This looks like feedback from logic that you have already traced; so, your guess
is to NOT trace these inputs.
N. Trace input A1 of DTMF_INST3.RESULTS_CONV_INST.g17707.
You find instance DTMF_INST3.RESULTS_CONV_INST.g17732, cell AND2X1.
Modus expects A=1, B=1 at the capture clock.
Modus shows A=0, B=1 at the capture clock.
O. Trace input "A" of DTMF_INST3.RESULTS_CONV_INST.g17732, cell: AND2X1.
You find instance DTMF_INST3.RESULTS_CONV_INST.g18241, cell XNOR2X1.
Modus expects the inputs A=0, B=0 at the capture clock.
You can see that the “B” input has logic driving it in Modus.
The SimVision schematic shows input "A" is driven by a fixed value: "1'b1".
You have found the fault inserted into the Xcelium netlist.
See the “Fault/Failure Introduced into the Xcelium Netlist” section at the top of
this application note.

Failure Analysis Summary
Because this was OPCG, there were two clocks: a launch clock and a capture clock.
This resulted in the fault propagating through scan FF before being captured. By
following the path that differs between SimVision and Modus, you found the root cause.
In Figure 13, you will see instances g17732 and g17707 that you traced through
above.
Not mentioned in the tracing detail is the simple inverted g17706.
Figure 13: SimVision schematic showing the inserted fault

Summary of Analysis Actions and Hints

• Find the failing scan FF from TVE-660 via the Modus schematic by using “VIEW
> SCAN BIT”.
• When tracing in the Modus schematic, highlight the nets so that you can keep
track of where you have been.
• In the Modus schematic, you can collapse/implode the hierarchical boxes to see
the technology cell level.
• If you trace through FF instances or if you have an ambiguous choice of which

inputs to trace, change the net highlight colors.
o In the Modus schematic, left-click to highlight a net, then right-click, and

then select PROBE.
o There is a PROBE button at the top that allows you to pick a specific
color.
o PROBE > AUTO tells the tool to use a new color every time you highlight
a net. It is recommended that you pick a bold color and only change it
when necessary.
• Import (+TESTFILE) only the failing pattern set.
• In the Waveform viewer, drop the “TimeA” flag at the leading edge of the
functional capture clock.
o Key-off the SE signal to find the capture clock.
• Once you have used the Modus schematic to find the failing scan FF instance,
look that instance up in the SimVision Design Browser.
o Dump the "pattern" variable from the top of the Design Browser
hierarchy into the Waveform viewer. This is the ATPG pattern number.
o Expand the left-hand-side hierarchy to find the scan FF instance, highlight

it, and dump its ports into the Waveform viewer.
o Hint: At the bottom right of the Design Browser, you can de-select the
internal net names. You then get only the port names on the right-hand
side.

• Once you have the initial failing FF in the SimVision schematic, use its schematic
trace feature to trace the mis-matching input.
o Highlight a port in the waveform or in the Design Browser, and then select
the Schematic icon to open the SimVision schematic.
• Once you have both the Modus schematic and SimVision waveform viewers
open:
o Verify that the instance names in the both tools match. Perform sanity
checks as you trace.
o Verify that the Modus schematic pattern (See Figure 11) matches the
“pattern” variable that you dumped in the SimVision waveform.
• Once you have traced backwards in the SimVision schematic, highlight the port
names on the inside of the bubble by holding the CTRL key down as you left-
click. This highlights all ports you have selected. Then, click on the Waveform
icon to dump the ports into the Waveform viewer.
• In the Waveform viewer, highlight the capture clock on the failing scan FF and
the ports on the instance you have traced to.
o User the BLUE edge search icon (top left ) to align TimeA flag to the
leading edge of the capture clock.
o This aligns all events to determine which signal differs from what Modus
ATPG expects.
• In the SimVision CONSOLE, enter “reset” (to return to time 0) and “run XXX
ns or us” to rerun the simulation just past the point of mis-compare. This
dumps your new probe data.
o Only run XXX to just past the failure. No need to run any farther.
• When you execute “xrun” or “xmsim” for debug, use “-gui” only to import the
failing “+TESTFILE”. There is no need to run any other pattern sets.

XOR and Smartscan Serial Pattern Failure Analysis Scenario

For Smartscan serial pattern failures, the first step is to migrate the CPP failure data to
XOR.
Here is the tool to map the Smartscan failing cycle (scan chain bit) to XOR. Debug is
then done using XOR. The tool is convert_smartscan_failures.
Once converted to XOR, you can debug the problem using the example above or the
diagnostics read_failures example.
A Few Checks Before Analysis

1. Ensure that the scan chain confidence patterns have been run and passed.
2. Try running parallel Verilog patterns. Debugging these failures is easier.
o Modus “write_vectors” has a parallel-pattern output feature. Use

“write_vectors includenetnames=yes”. With this parameter, the
mis-compare message will contain the name of the net being driven by the
FF.
o This will eliminate the actual functional pattern values and the functional
clock capture sequence as the root cause for your failures. You can now
focus on the XOR spreader logic from the SDI pins, any masking logic, or
the XOR Compression logic that drives the SDO pins.
At this point, you may want to export the single failing pattern.

3. Create CPP failure data to try running diagnostics.
o As of ET 12.1.101, Modus Diagnostics will analyze XOR and OPMISR

scan structure failures.
o Use the Modus Verilog testbench +FAILSET and Modus Diagnostics

tools.
 “read_failures” – For the failing serial scan simulation, you can

import the CPP data created by +FAILSET.
 After running read_failures, you can execute

diagnose_failset_logic.
o You can do a write_failures in tbfail format to get a list of failing FF

instances for schematic analysis. An example is given below:
write_failures exportfile=<any file name> \

testmode=<same test mode as on read_failures> \
failset=<failset from read_failures> \
experiment=<experiment name>

Logic Pattern Timing for XOR- with Masking

The diagram below is intended as a reference for anyone who is attempting to debug
XOR simulation failures. Having this higher level overview of the event sequences will
allow you to better isolate and diagnose the mis-compares.
• Note the Modus “pattern” number at the top. This is very useful for ensuring you
are doing analysis on the correct ATPG pattern.
• The diagram begins with a functional capture. Scan enable (scan_en) is

inactive.
• Channel Mask Load Enable (CMLE) is activated, and the channel mask scan
chain is loaded.
• Scan unload is executed. Twice during scan unload, you make active the
Channel Mask Enable (CME) input and mask the scan output data.
o Remember that you load in the next pattern, as you are scanning out and
observing the current pattern.
• You reach the next functional capture. Scan enable is again inactive.
• No channel masking is necessary for this pattern; so, you skip loading the
channel mask scan chain (no CMLE) and exercise scan unload (no CME signals
to mask-specific bits in the scan chains).

Figure 14: Waveform diagram of XOR patterns with MASKING
XOR MASK OPERATION

Pattern 1 Unload Pattern 2 Unload
Capture State
No MASK in this Pattern
Scan Unload
Scan CLK is OFF
SCANOUT is MASKED
MASK Registers Loaded

Bonus Debug Information

A. 0-delay simulation may hide glitches. You can ask the Waveform viewer to show
you these glitches.
database –open <dbname> -into <db-loc> -default –event –shm
The select items to probe and run simulation are as shown above.
B. Within the Modus schematic, you can dump blocks and ports into a ‘watchlist’
file.
For large netlists, finding instances within the SimVision DESIGN CONSOLE can
be cumbersome. The Modus schematic may be easier to use for tracing the
logic.
You can dump any logic traced into a watchlist file. Highlight the block and then
with a right-click, select “Add To Watchlist”.
Use the watchlist file as import into Xcelium simulation by using the
“watch2probe.tcl” script provided in the Modus installation under
“./scripts”. (These are for user convenience but not supported.)
The script has a HELP to show how it is used.
Note that the “watch2probe.tcl” script opens the waveform database with “-
event”.

Summary
This document provided both general and scan-structure-specific information. The
reader should be able to utilize this information to systematically work through the
analysis of simulation mis-compares.
There is a lot of information within this document. Of all the information here, the
following are the most important items you should know when analyzing mis-compares:
• Understand the scan logic structure that you are dealing with.
• Know what your control and clock pins are and how they need to be manipulated.
• Know the event timings.
• Know what pins must be toggled in what order to scan in, issue a functional
capture clock, and scan out.
• Use the waveform “TimeA” flag judiciously to ensure that you line up the Xcelium
simulation events with the Modus schematic pattern values.
Support
Cadence Support Portal provides access to support resources, including an extensive
knowledge base, access to software updates for Cadence products, and the ability to
interact with Cadence Customer Support. Visit https://support.cadence.com.
Feedback
Email comments, questions, and suggestions to content_feedback@cadence.com.


Diagnosing Simulation Miscompares Modus

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diagnosing Simulation Miscompares Modus

Uploaded by

Copyright:

Available Formats

Diagnosing Simulation Mis-Compares in

Modus Test Patterns

Product Version: Modus Version 19.11, Xcelium Version 19.10

Learn more at Cadence Support Portal - https://support.cadence.com

Learn more at Cadence Support Portal - https://support.cadence.com

Fault/Failure Introduced into the Xcelium Netlist

// XNOR2X1 g18241(.A (out_p1[5]), .B (out_p2[5]), .Y (n_134));

// The hierarchical Port instance name with the stuck-at-1 failure:

Learn more at Cadence Support Portal - https://support.cadence.com

• How to compile the Modus Verilog testbench

• How to elaborate the Modus testbench

• How to reference a specific test pattern file

• Information about useful NC simulation parameters

Learn more at Cadence Support Portal - https://support.cadence.com

Items to Review before Starting Mis-Compare Analysis

Before diagnosing any simulation mis-compares, review the Modus

• TSV-332: A channel mask shift register element <name> was

• TSV-331: An observable latch or flop <name> was corrupted

• TSV-310: One or more clock inputs are at “X” in the Test

• TSV-059: Potential Race condition in clock gating logic.

• Unit-delay simulation is not recommended.

o SDF-annotated timing and negative timing checks are addressed in the

Learn more at Cadence Support Portal - https://support.cadence.com

• Ensure that you are using the xmelab/ncelab parameter “-

An Example is shown in Figure 1.

Bidirectional pin failures (mis-compare)

OPCG and SDF-Annotated Timing Items to Check

• Check the failing scan chain FF clock input.

Learn more at Cadence Support Portal - https://support.cadence.com

• When a timing violation occurs, the Register/FF output is set to X.

• That X-source FF should have a timing violation message on it within the

Modus Verilog Patterns

Learn more at Cadence Support Portal - https://support.cadence.com

Compile and Simulate

Figure 1: xrun compile and simulate

xrun -log xrun_bad_netlist.log \

Learn more at Cadence Support Portal - https://support.cadence.com

Figure 2: Sample of the parallel simulation log output

INFO (TVE-201): Simulation complete on vector file:

INFO (TVE-206): The number of good comparing vectors for

INFO (TVE-205): The number of miscomparing vectors for the

INFO (TVE-200): Reading vector file:

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

INFO (TVE-201): Simulation complete on vector file:

INFO (TVE-206): The number of good comparing vectors for

INFO (TVE-205): The number of miscomparing vectors for the

Learn more at Cadence Support Portal - https://support.cadence.com

Figure 3: Sample of the serial simulation log output

INFO (TVE-201): Simulation complete on vector file:

INFO (TVE-206): The number of good comparing vectors for

INFO (TVE-205): The number of miscomparing vectors for the

INFO (TVE-200): Reading vector file:

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

WARNING (TVE-660): SO miscompare at pattern: 1.2.1.11.9.9

INFO (TVE-201): Simulation complete on vector file:

INFO (TVE-206): The number of good comparing vectors just

INFO (TVE-205): The number of miscomparing vectors just

Learn more at Cadence Support Portal - https://support.cadence.com

Notes for figures 2 and 3:

• The SCAN patterns pass. This is good.

o The different failure count is okay.

• TVE-650 mis-compare message: