Simulation Mismatch
Simulation Mismatch
: https://www.edaboard.com/showthread.php?343302-how-to-debug-pattern-mismatch-during-
simulation-of-ATPG-pattern
For debugging output mismatch error you need to read "TEST PATTERN VALIDATION" by Synopsis
user-guide.
In that you'll find there are six types of output miscompare messages can be present.i.e. Signal XYZ
expected to be 1 was X.You need to read this first to debug your simulation failure.
Step-1.Create a testbench file(.v file) by using ATPG tool. If you're using TetraMAX ,then write out
testbench using write_testbench command.
Step-2.Point the stil(pattern) file which you have already generated into the testbench file to help
understanding testbench file which patterns you want to simulate.
Step-4.For simulation tool there are many available,mostly i prefer vcs tool. whichever simulation
tool you want and start the simulation.
most possible reason for output miscompare could be due to the design constructs that are not
matching with application of STIL data.While doing simulation, I have faced this miscompare errors
many often, and it was because of the constraints on clock(In my case) which was mismatching with
the STIL data. For that i need to edit my spf file.
Step1. Try to debug which pin/port is having miscompare and which pattern causes the failure.
Step2. Use waveform viewer tools (i.e Verdi,etc) to easily debug the failure. Add clocks in waveform.
Try to find the root cause of having miscompare value (expected to be 1 was 0) on that particular
pin.
Step3. Check your constraints file. In waveform, see that the output at particular pin is according to
the constraints or not. Check why wrong value is coming at that pin.
Well from the waveform viewer you already know at what time instance and for what signal the
expect verses the actual values are failing. One way could be to open this signal/signals in the
schematic viewer and keep tracing it backwards to the point where its change occurs. In the path
you might detect an anomaly which you can then further investigate.
In serial simulation pattern is shifted in to FFs in scan chain through scan-ports. So, more the no. of
FFs more time it will take to shift in the pattern. Note that, here, simulator will apply patterns at
scan-ports.
In parallel simulation values that should have actually reached the D input of FFs in a scan-chain by
shifting through scan-inputs are directly forced at the D input of FFs by simulator. So here, simulator
will save time to load-unload the patterns as it is directly forcing patterns at D input of flops.
So, as parallel simulation reduces the time for shifting the pattern you can easily decide which mode
to use.
Use parallel simulation when you want to reduce the simulation time.
ATPG one bit Pattern Simulation Mismatch of one bi1 e-x a-0
If they are huge, then check whether clock is propagating to that cell or not ; check whether cell gets
initial reset or not. These are most possible reasons I have seen for getting X-mismatches.
1. dump the waveforms, load your design & waveforms into Verdi,etc tool.
If it's a single X-mismatch, then you may need to dive-in a bit deep to debug the issue. However,
solving a single X-mismatch (exp-0 got-x) is quite easier than solving single 0/1(exp-0 got-1)
mismatch.
Link: https://www.electronicdesign.com/test-amp-measurement/simulation-mismatches-can-foul-
test-pattern-verification
Design for testability (DFT) works to make a circuit more testable to ensure that it was manufactured
correctly. Alfred Crouch explains the purpose of DFT in his book, Design-For-Test for Digital ICs and
Embedded Core Systems: "To exhaustively test a combinational circuit with N inputs, a sequence of
2N test vectors must be applied and observed to fully exercise the circuit." With that goal in mind,
the primary purpose of DFT is to increase testability of a given netlist by increasing controllability
and observability.
A design can be considered testable if a satisfactory set of test patterns is generated, evaluated, and
applied to improve quality and minimize time-to-market. Therefore, a testable system implies better
fault coverage, a shorter testing time, a higher-quality product, and a shorter time-to-market. Two
tasks must be accomplished in DFT: generating efficient test patterns with maximum test coverage,
and then verifying test patterns. Afterward, these generated test patterns are applied to the real
design, and timing information is considered.
During test-pattern verification, problems occur when the results generated by the automatic test-
pattern generation (ATPG) tool don't match the simulated results-when timing information is
considered. This is known as simulation mismatch.
The ultimate goal of applying this methodology during a design's creation and implementation
phase is to ensure that hardware hooks in the final design will enable the tester to apply test vectors
that can achieve a high quality of test. This methodology is applied to the general design structures,
and it behaves as combinational logic during test mode.
In functional mode, the design comes in the form of sequential logic. Circuit operation involves many
clocks to get data through memory elements. In a sequential design, back tracing for vector
generation isn't possible. Therefore, these sequential elements are transformed to pseudo-
combinatorial elements using various scan architectures. Designers generally use three scan
architectures:
1. Mux-DFF: A mux-DFF cell contains a single D-type flip-flop with multiplexed input lines that allow
the selection of either normal system data or scan data (Fig. 1). In normal operation (SC_EN = 0),
system data passes through the multiplexer to the D input of the flip-flop, and then to the output
(Q). In scan mode (SC_EN = 1), scan input data passes to the flip-flop, and then to the scan output
(SC_OUT).
2. Clocked-Scan: The clocked-scan architecture is similar to the mux-DFF architecture, but it uses a
dedicated test clock instead of a multiplexer to shift in scan data (Fig. 2). It ensures data hold for
non-scan cells during scan loading. In normal operation, the system clock (SYS_CLK) clocks system
data into the circuit and to the output (Q). In scan mode, the scan clock (SC_CLK) clocks scan input
data (SC_IN) into the circuit and through to the output (SC_OUT).
3. Level-Sensitive Scan Design (LSSD): In normal mode, the master latch captures system data (DATA)
using the system clock (SYS_CLK) and sends it to the normal system output (Q) (Fig. 3). In test mode,
the two clocks (ACLK and BCLK) trigger the shifting of test data through both master and slave
latches to the scan output (SC_OUT).
Scan Operation
The scan chain is a set of cells in which one scan cell's output port is connected to the dedicated
scan input port of another scan cell (Fig. 4). In this way, a serial scan chain is constructed. If all
sequential elements in a design are converted to scannable elements, the architecture is known as
full scan. If some non-scanned sequential elements are left in the design, the architecture is known
as partial scan. The test procedure is based on the following sequences:
2. After loading the scan cells, hold the scan clocks off and then apply a stimulus to the primary
inputs.
4. Pulse the clock to capture new values into the scan cells.
5. Enable the scan operation to unload and measure the captured values.
In Figure 5, the scan cells are shifting the scan data (scan data1, scan data2, and scan data3) with
respect to the scan clock. After completion of the shift operation, the scan enable signal is disabled
and applied to the stimulus from the primary inputs. Finally, the outputs are measured through the
primary outputs.
Once the test circuitry is inserted and the test procedure is established, the ATPG tool can be used to
generate the test patterns. However, the ATPG tool will perform design rule checking (DRC) to
ensure the test circuitry and test procedure can allow the tool to generate the test patterns with
high fault coverage.
Test-pattern verification is based on the device timing information to ensure that the patterns can
be applied to the real circuits. If any mismatches occur between the timing-based simulation results
and the expected results, the test patterns must be corrected. If test patterns aren't corrected, good
devices would be rejected during the manufacturing test process. The most common simulation
mismatches are as follows:
Timing Issues: Timing-related issues generally occur because of clock skew between the successive
scan cells in the design. If the propagation delay at the data path between two successive scan cells
is less than the propagation delay at the clock path, clock skew occurs. Conceptually, it would be
ideal to have only one scan clock. But this actually creates more clock-skew problems, due to the
multiplexing together of asynchronous clocks.
When connecting flip-flops of different clocks onto the same scan chain, we try to buffer the path
from scan out of one clock domain to the scan in of the other to provide hold time during scan
shifting. This relaxes the clock-skew requirement between the flip-flops. Clock skew caused by the
delay through the multiplexer can introduce hold-time violations in the scan mode. These violations
occur when a non-inverted flip-flop Q output is connected to an inverted clock DI (scan) input.
In Figure 6, the second scan cell captures the updated data of the first cell instead of data at the
input of the second cell before asserting the clock. This problem can be resolved by increasing the
delay at the data path by adding a latch, called a lock-up latch. Another method involves setting an
ATPG function to both input cells, which ensures both cells capture the data at the same time. Fix all
hold-time violations in scan mode by adding buffers to delay the path (if two clocks are in the same
scan chain).
Design-Rule Violations: Non-scanned latches in the pad logic are flagged as violations. But since
these are bypassed in the scan mode, they won't affect the coverage. Even if all blocks in the design
pass DRC, violations still appear at the top level due to connectivity problems, bus contention, loops,
or clock interactions.
Clock-Rule Violations (C3 rule): Clock-rule violations (C3 rule) are handled by simulating multiple
events per test cycle. Figure 7 illustrates the single-cycle multiple events. Event 1 corresponds to
default simulation performed by the ATPG tools. State elements haven't yet changed, although all
combinational logic-including that connected to clocks-has been changed. Event 2 corresponds to a
time when level-sensitive and leading-edge state elements have updated as a result of the applied
clocks. This simulation correctly calculates values for trailing-edge and level-sensitive state elements.
D7 Design-Rule Violations: A negative flip-flop present in the design causes D7 design-rule violations
(Fig. 8a). The clock for this flip-flop is at logic level "1" during the off state. This happens because the
clock is inverted and connected to the clock pin of the flip-flops (Fig. 8b). The negative-edge-
triggered scan cell in a scan chain can capture data from the positive-edge-triggered scan cell in
another scan chain. Unfortunately, the positive-edge-triggered scan cell captures the data before the
clock cycle is completed. Therefore, the expected data generated from the tool for positive-edge-
triggered cell is old data.
In timing-based simulation, the new data is the updated data of the negative-edge-triggered cell.
This is because the negative-edge-triggered cell is capturing the data on the negative edge of the
defined clock cycle. Sometimes, we can ignore the D7 violations. Otherwise, we need to inform the
ATPG tool to update the scan-cell data.
Bus Contention During Scan Operation: The biggest problem in system-on-a-chip (SoC) designs with
respect to ATPG is resolving how to control the internal three-state bus structures. Two careful
considerations are necessary to avoid bus contention.
First, make sure there's no contention on the three-state buses during the scan-shifting operation. A
scan-insertion tool automatically performs this task. Second, ensure that there's no contention on
the internal three-state buses during the capture cycles while scan testing. The ATPG tool can't
generate the test pattern for the bus contention, and it uses those test patterns to test the device
that may be stressed to the production test. Therefore, avoiding the internal three-state bus
contention is most important during test-pattern verification.
The bus contention problem will occur at two levels. The first is within a block design that contains
multiple drivers for the three-state port. The second problem is at the chip level, where multiple
design blocks interface with the same bus.
Multiple Clock Domains: A clock domain is a grouping of sequential elements sharing a single clock in
the design block. If two design blocks share the same clock, then there must be clock skew between
the two blocks. Clock skew is important because although it's easy to meet the setup timing
requirement, it will create a problem with hold-time violations during scan testing. To avoid the
hold-time problems during scan testing, add buffers in the clock path.
Bidirectional I/Os: Handle bidirectional I/Os with care during test-pattern verification. The ATPG tool
can generate patterns when the bidirectional I/Os change direction as a result of the capture clock.
Testers generally don't support this function. So, you should force the ATPG tool to generate scan
patterns that don't change the direction of the bidirectional IOs during the capture cycle.
Finally, test-pattern verification is important prior to testing to ensure that the ATPG-tool-generated
test patterns can be applied to the real design and to prevent the rejecting good chips off the
manufacturing line. Simulation mismatches will reduce the fault coverage and yield. They should be
resolved by analyzing the circuits as described here.
Recommended Reading:
Abramovici, Miron, Breuer, Melvin A., and Friedman, Arthur D., Digital Systems Testing and Testable
Design, Wiley-IEEE Press, Sept. 1994.
Basto, Luis, Khan, Asif, and Hodakievic, Pete, Embedded X86 Testing Methodology, Advanced Micro
Devices, 1999.
Crouch, Alfred, Design-For-Test For Digital ICs and Embedded Core Systems, Prentice Hall, 1999.
If the two clocks have same phase and the frequency may or may not be the same then that clock is
called synchronous clock.
To decide it as a synchronous and asynchronous will not depend on the frequency (because of
frequency) , only speed varies. It will be decided by the phase of the 2 clocks.
If the source of the two clocks is same then the clock be synchronous. If the source of the two clocks
is different then there is a chance of asynchronous.
If the two clocks are with different phase and the frequency may or may not be same then the clock
is known as asynchronous signal.