Comparescan User Guide

Writing Comparescan Rules

stability

stability clockDefinitionName name [options]

The stability command directs Comparescan to perform setup and hold timing checks at the sample points in a clock cycle. The stability command performs the same setup and hold timing checks that the clkcompare command performs, but the stability command does not perform a comparison between two signals. You use a stability check to guarantee that signals do not change within a specific window of time around an event.

Note: The signal that you specify as the clockDefinitionName does not have to be a true clock. It can be any single-bit signal in either the golden or test simulation.

stability Command Examples

The following stability command:

stability clk top.s1 -setup 20ns -hold 10ns

performs the same setup and hold timing checks as this clkcompare command:

clkcompare clk1 top.s1 -setup 20ns -hold 10ns

but the clkcompare command performs a clocked compare between signal top.s1 in the golden file and signal top.s1 in the test file, whereas the stability command does not perform a level comparison at all.

stability Command Options

All of the clkcompare options that are listed in Table 6-8 on page 80 are also available with the stability command.

Comparescan User Guide

Writing Comparescan Rules

sequencetime

sequencetime [options]

The sequencetime command toggles sequence timing within a comparison. If you turn on sequence timing, Comparescan treats zero-delay events on a signal as regular events.

Therefore, if you use the sequencetime command within an absolute comparison,

Comparescan checks for all events that match.

Note: If you specify the sequencetime rule, there are more events to process and the comparison runs more slowly. The sequencetime command can cause Comparescan to report many unimportant mismatches. These mismatches are caused by event queue order-processing differences.

nosequencetime

nosequencetime [options]

The nosequencetime command directs Comparescan to ignore zero-delay events on a signal. This is the default state.

Comparescan User Guide

Writing Comparescan Rules

statemapping

statemapping stateMapName \

testState1 testState2 [testStateN] \

The statemapping command defines a mapping between signal states. You use this command to define the method by which Comparescan matches states. If you use this command, you must also use the -statemapping option to the compare command.

By default, no state mapping is used. Values must match exactly, but strength is ignored. For information on how to force Comparescan to consider strengths, see the options

-checkstrength and -ignorestrength, described in Table 6-2 on page 61.

statemapping Command Syntax

The syntax of the statemapping command forms a table that defines which pairs of values match. A 1 in the table body tells Comparescan to treat these two values as a match; a 0 in the table body tells Comparescan to treat these two values as a mismatch.

Each state map probably has at least one 1 in each row, since you probably want to define state1 to match state1, state2 to match state2, and so forth.

It is an error to redefine a state map, so it is an error to use the same stateMapName with more than one statemapping command in one Comparescan comparison.

statemapping Command Examples

In the following example, 0 matches 0 but no other states, 1 matches 1 but no other states, x matches only another x, and z matches only another z:

statemapping Default \

01xz \

0:1000 \

1:0100 \

x:0010 \

z:0001

Comparescan User Guide

Writing Comparescan Rules

The following three state maps are similar. In GoldXMatches01, an x state in the golden signal matches both 0 and 1 states in the test signal.

statemapping GoldXMatches01 \

01xz \

0:1000 \

1:0100 \

x:1110 \

z:0001

In GoldXMatchesAll, an x state in the golden signal matches any state in the test signal.

statemapping GoldXMatchesAll \

01xz \

0:1000 \

1:0100 \

x:1111 \

z:0001

In AllXsMatch, an x state in the golden signal matches any state in the test signal, and an x state in the test signal matches any state in the golden signal.

statemapping AllXsMatch \

01xz \

0:1010 \

1:0110 \

x:1111 \

z:0011

statemapping Example in a Rules File

A chip design that you want to use in a comparison contains a signal named net12. You have generated a golden RTL simulation output and a test gate-level simulation output. The problem is that in the RTL simulation, net12 is sometimes X, and in the gate-level simulation, net12 is always 1 or 0.

To allow an X value in the golden simulation to match a 1 or a 0 in the test simulation, use the statemapping command in your rules file, as follows:

datafile1 rtl-golden.trn

datafile2 gate-test.trn

statemapping goldenXok \

01xz \

0:1000 \

1:0100 \

Comparescan User Guide

Writing Comparescan Rules

x:1110 \

z:0001

compare top.net12 -statemapping goldenXok

compare top.n_weak -checkstrength