https://support.cadence.com/apex/Display_Articl...

How to debug Simulation Miscompares, why patterns are failing, serial passes but parallel fails

How To...
This article explains in detail about how to debug Modus Verilog patterns miscompares. It also explain about difference between serial and
parallel scanformat and scenarios like serial passing and parallel failing

Answer
This article has following sections:
1. Why we need verilog patterns.
2. What to look for before we start debugging simulation miscompares.
3. Zero delay patterns debug.
4. Different format of patterns Serial Vs Parallel.
5. Steps to debug the Miscompares.
6. Getting failing register using Diagnose failset flow.
7. Serial Passes and Parallel failed.
8. Using Diagnostic to debug miscomapres.

1. Why we need verilog patterns:

Modus produces WGL, STIL and Verilog output formats for the test patterns with write_vectors command. Before releasing the WGL or
STIL formats to a hardware, We should simulate those patterns via a Verilog simulator. Sometimes simulation of the Verilog patterns results
in miscompare messages. When this happens we must identify the cause of these miscompares and fix the problem.

2. What to look for before we start debugging simulation miscompares:

Before debugging any simulation miscompares we should review verify_test_structures log file. Look for “Severe” level messages,
especially those messages that identify problems with the clock, scan operations or explicitly mentioning any type of corruption of data.
Following are some of the 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.

3. Zero delay patterns debug

In case we don’t get any obvious reasons for simulation miscompares with the MODUS warnings , we need to debug the reason for
miscompares and start it with the Zero Delay simulation. We need to check whether Zero Delay simulation is passing in case when SDF
annotated simulation is failing. This would ensure that patterns generated are fine.
But Zero Delay simulation may result in race around condition, so we need to always use the keyword NCSEQ_UDP_DELAY with
ncverilog or irun command or use keyword SEQ_UDP_DELAY during elaboration i.e., ncelab -seq_udp_delay <int> ps . This parameter
ensure that there is no zero delay (delta simulation time) event order problem.
In case of SDF annotated simulation miscompares and we are getting, Expected : <Value> Simulated : “X”, then there must be timing
violation. Check the simulation log and fix the violation to avoid Miscomares.

4. Different format of patterns Serial Vs Parallel

We can have the vectors written in either serial or parallel scanformat.
In case of serial scan format (default), the values to be loaded into the latches/flops are applied at the primary input scan_in’s and then the
clocks are applied to get the right values into the latches/flops (scan operation as defined in the mainsim).
In case of parallel Verilog ("scanformat" set to "parallel"), Modus finds a net that feeds each latch/flop and then we stim the values directly
on those nets and pulse the clock to get the value into each latch/flop. The same values that would be shifted in for serial testing are
applied to all the latches/flops in a parallel fashion. Instead of a serial scan out, the clock is pulsed and the latch/flop outputs are then
compared to expected values. The same values that are used in the serial simulation are applied in the parallel sim.

5. Steps to debug the Miscompares :

1. For debugging the scan based designs, the first step is to identify the failing/faulty flop.
Following are the ways to get this information :
A. In case of scanformat parallel, we can use the keyword “-includelatchnames” and MODUS will directly provide the information about the
failing flop. For example, we will get the miscompares message as shown below :
WARNING (TVE-660): SO miscompare at pattern: 3.2.1.6.1.6 at Time: 3690000.00 ps
Expected: 0 Simulated: 1 On Latch/Flop: DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_28 .__iNsT1.dff_primitive During
Scan Cycle/Bit #: 31 Scan Out = DLX_CHIPTOP_DATA[12]; Observe Register (OR) = 7;

Here, the “SO” entry tells you that the failure was during a Scan Output operation.
The Scan Output pin is DLX_CHIPTOP_DATA[12]
Scan Cycle/Bit #: 31 tells that the 31st FF from the Scan Output pin is the state device that captured the bad logic value during the
functional capture portion of the test.
B. In case of serial Verilog pattern we will not have the register name explicitly mentioned in the log file, in that case we can map the
miscompare message information to the output from report_test_structures.
Following is the example of report_test_structures command and snippet from the section where we can map the failing register :
report_test_structures -testmode {testmode_name} -reportscanchain all

Position LTYPE Blk Index/IO ObserveReg ObserveBit Block Name

1 of 6 10/4/19, 3:36 PM
 https://support.cadence.com/apex/Display_Articl...

-------- ------- ------------ ---------- ---------- ----------

1 rDFF_Cs 9577 +- 7 31 DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_28

.__iNsT1.dff_primitive
Above snippet shows the failing bit 31 for our failing scan chain in the “ObserveBit” column. Header information in the report names the
scan output pin.
C. We can also use the MODUS GUI to get the failing register.
For example , if we get following message in miscompare :
WARNING (TVE-660): SO miscompare at pattern: 3.2.1.6.1.6 at Time: 3690000.00 ps
Expected: 0 Simulated: 1 On Latch/Flop: DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_0 .__iNsT1.dff_primitive During
Scan Cycle/Bit #: 31 Scan Out = DLX_CHIPTOP_DATA[12]; Observe Register (OR) = 3;
We need to open MODUS Schematic window -> Click on View -> Click in Scan Bit as shown below :

This will open a window that will ask the Register Number and Bit position which is given in the TVE-660. We have options to Replace
Circuit Display or Add to Circuit Display as well.
Following is the example :

6. Getting failing register using Diagnose failset flow

We can also use Diagnostics run to get the information about failing register.
When we run the Verilog testbench with the “+FAILSET” SWITCH, tool will write out a file “$workdir/testresults/Verilog/
VER.[TETSMODE].logic.data.logic.ex1.ts2.verilog_FAILSET” in CPP format which we use for diagnostics.
Following is the snippet from the generate file :
Chip DLX_TOP pad DLX_CHIPTOP_DATA[18] pattern 1.2.1.3.1.6 position 31 value 1
Chip DLX_TOP pad DLX_CHIPTOP_DATA[18] pattern 1.2.1.3.10.6 position 31 value 1
Chip DLX_TOP pad DLX_CHIPTOP_DATA[18] pattern 1.2.1.6.4.6 position 31 value 1

Following is the set of commands that can be used for Diagnostics run :
read_failures -testmode {tetsmode_name} -experiment {experiment_name} -workdir . -failset logic -importfile ./testresults/verilog
/VER.[testmode].logic.data.logic.ex1.ts2.verilog_FAILSET
analyze_failset -testmode {testmode_name} -experiment {experiment_name} -workdir . -failset logic
Following is the snippet from the log file of analyze_failset in which tool is reporting the failing register and its corresponding scanout pin :

2 of 6 10/4/19, 3:36 PM
 https://support.cadence.com/apex/Display_Articl...

2. Now since the Failing register is identified we need to compare the values MODUS believed should exist (Good Machine Simulation) with
the values simulated by Xcelium/Simulator.
Following are the steps to run the Good machine simulation :
A. From the MODUS main window/Shell set the context for the analysis and enter the testmode.
B. Open the failing Register in MODUS Schematic Window.
C. View -> Test Data -> Test Vectors (TBDbin) -> Sequence -> View Circuit Value
From Sequence section, we need to find the failed vector from the Xcelium log file. For example, if we are getting failure at : 1.2.1.3.1.6
then following is the snippet :

Values will be displayed on the schematic. We can trace the logic backward to check the values propagation as well.
Modus can also create Simvision file to allow pattern tracing and debug. These will be good machine values from what Modus is expecting
from the circuit.
We need to create a list to watch particular nets within design. This watch list can be created from the GUI or by a script. Following are the
steps :
1. Open Schematic Viewer
2. Open the failing Registers/ Logic you want to trace
3. Right Click on the net to bring up the Display Actions menu
4. Click on Add to Watch List
Following is the snippet from the Add to Watch List window :

3 of 6 10/4/19, 3:36 PM
 https://support.cadence.com/apex/Display_Articl...

5. Click Ok to have tool save list to a file

Now we can use analyze_vectors command to generate the waveforms for these nets and even control the range of vectors for which we
want to run simulation.
Following is the syntax of command :
Analyze_vectors –testmode <> -experiment <analyzed> -inexperiment <atpg experiment> -watchnetsfile <netfile.txt> -watchvectors
1.2.1.2.1:1.2.1.3.2
Now, open the MODUS GUI and click on the View Waveforms icon which is 7th Icon from the left.
A popup window will comes up, we need to load the .trn file to open simvision.
Once the simvision is loaded with database, we can run simulation on the selected nets to have a Good Machine reference values.

3. The next step would be to bring the Simvision on the Bad machine simulation i.e., where we are getting simulation miscompares and
compare the waveforms with Good Machine Values.
In case the simulation GUI is not already opened, we need to add +gui to the irun command. Your command should look like :

On the waveform window change the radix of the waveform “pattern” by right clicking the waveform element under “cursor” to ASCII. This
should show the pattern odometer on X axis and will help you locate the failing ODOMETER.
We can go to Odometer and now we have the Good Machine and Bad Machine values, we need to Compare the two to point to the origin
of discrepancy between both.
In SimVision, we can also open the schematic of the failing register and back trace the logic cone. Right Click on the specific cell and
choose the option as required. Following is the snippet :

4 of 6 10/4/19, 3:36 PM
 https://support.cadence.com/apex/Display_Articl...

7. Serial Passes and Parallel failed:

It’s possible that in certain cases, Serial verilog simulation passes but we get miscompares in Parallel simulation.
In this case, most probable reason is presence of Scan Corrupted latches in design. These are non-scan latches that become corrupted
during the scan shift operation. IF these latches become corrupted to a known value and there is no gating on their clocks then MODUS
will allow ATPG to assume that these latches are at that known value.
The problem is that by default parallel Verilog does not execute the scan shift operation thus these non-scan latches remain at an "X" logic
state.

Following are the ways that can report if there are Scan Corrupted Latches in design.
A. build_testmode will give following information message :
INFO (TTM-350): There are 20 Permanently Scan Corrupted Latches. [end TTM_350]
B. verify_test_structure will give the following Warning message and mention the specific register name :
WARNING (TSV-315): Memory element block XYZ.dff_primitive is not in a scan chain and is corruptible during the scan operation. The
memory element may be clocked through pin ABC.CLK during the scan sequence. [end TSV_315]
C. report_test_structures -reportscancorrupt yes … will report if a known value is being loaded into scan corrupted latch.
Following is the snippet from the report_test_structures :
Blk Index Value Block Name
--------- ----- ----------
37738 X chip.xxx.dff_primitive
65756 + pad.xyz.I0.dff_primitive

Method for addressing this is to use write_vectors -explicitshifts <integer> or add patterns to your test mode init
sequence. The keyword explicitshifts offsets the parallel Verilog simulation from 1-to-n scan shifts. This parameter allows you to
force the "n" scan shifts necessary to get a known value into these non-scan scan corrupted latches. By default parallel Verilog does
not execute the scan shift operation thus these non-scan latches remain at an "X" logic state.

Another solution is to add patterns into test mode initialization sequence, so as to set these scan corrupted latches to a known value.
This method requires rebuilding the test mode and rerunning create_logic_tests.

Both methods have very little or no impact on your tester run times or tester data volume.

8. Using Diagnostic to debug miscomapres.

We can also use Diagnostics Engine to debug simulation miscompare.
Diagnostic run will provide the information about the net/cell name of the failure and the defect/root cause of the failure as well (in case it is
giving a score of 100).
Following is the command that needs to be run :
Diagnose_failures –failset <> -importfile CPP_FILE –testmode <> -experiment <>
Following is the snippet from the log file of above command :

5 of 6 10/4/19, 3:36 PM
 https://support.cadence.com/apex/Display_Articl...

In the above report. We can see tool has pin pointed the defect that explain all the miscompares.
We can open the location of fault ID : 37223 from the Modus Schematic window and in Simvision schematic browser and analyze the
reason for the origin of discrepancy between values.

Return to the top of the page

6 of 6 10/4/19, 3:36 PM