 |
|
The rules file is used to describe how a compare will be performed. The rules file can be omitted, in which case a default set of rules will be applied to the entire simulation.
A rules file can be used to limit the scope of the compare, either to limit the number of variables or to limit the time period of the compare.
A rules file can also be used to define more complicated checks.
Commands take the form:
command <required arguments> [options]
Required arguments are usually things like file names or signal names to compare.
Options are used to change the default values for comparison parameters. For example to change the setup time from default 0 to 20ns, use the option -setup 20ns.
The following command from a rule file will compare two signals, with a tolerance window of 35ns. The signal names are required arguments, and the tolerance setting is an option.
compare top.signal1 top.signal2 -tol 35ns
Required arguments and options are processed from left-to-right and can be mixed together in any order. Options appearing later on the command line will override earlier options on that command. Setting options once per command is recommended.
Required arguments can sometimes be omitted in the rule file. The rule file parser will fill in the omitted arguments as if they had been typed by the user. Omitting arguments is an easy way to specify default behavior.
A compare command:
compare top.signal1 top.signal1
can be shortened to
compare top.signal1
Clock compares can also be shortened:
clkcompare top.clk top.signal1 top.clk top.signal1
can be shortened to
clkcompare top.clk top.signal1
The basic options available to all commands in the rules file are listing below. Command specific options are listed with the description of those commands.
| Commands | What it does |
|---|---|
| datafile1 | Specifies the golden simulation file. Is usually an SST file, but can be any supported file format. |
| datafile2 | Specifies the test simulation file. Is usually an SST file, but can be any supported file format. This command can be omitted. |
| compare | Performs an event matching type comparison. Every event in the golden simulation must match an event in the test simulation. A tolerance window can be specified to facilitate matching. |
| clkdef | Defines a clock name to be used in a clkcompare. |
| clkcompare | Performs a clock edge sample comparison and stability check. Clock compare is very useful for comparing signals that have many uninteresting transitions before settling. |
| stability | Performs a clock edge stability check, just like clkcompare. |
| sequencetime | Includes sequence time in event stream. |
| nosequencetime | Ignores sequence time events. |
| translate | Translates a simulation result file to an SST file. |
| report | Generates ASCII reports |
| savedata | Saves the error database into a file for viewing later. |
| statemapping | Defines a mapping between logic states. |
| threshold | Defines a mapping from analog values to logic states. |
# or //.
# This is a comment.
// This is also a comment.
Comments are parsed and ignored.
Comments can also be placed within a line. In this case, everything from the comment character to the end of the line is ignored.
datafile1 cpu.sst // This is a comment at
// the end of a line.
compare . // Another comment.
Some commands change parameters or settings for commands to follow. Other commands define two modules or variables to be compared. In either case the command is executed immediately.
The rules file is parsed using a very simple white space parser. White space is any of the following characters: blank, tab, carriage return or newline.
A command in the rules file is made up of tokens separated by white space. As a rule is parsed, the command is turned into tokens that can be executed by the rule interpreter. Once a command is executed, its effects are immediate.
Commands can be listed in any order in the rules file, with a few exceptions:
datafile1 and datafile2 rules must come before any compare, clkdef, clkcompare or stability commands.
clkcompare or stability command that uses a clkdef must come after the clkdef command.
compare, clkcompare and stability commands can be intermixed at will.
It is recommended that a signal or variable only be compared once in a rules file. If a signal or variable is compared more than once, the error reports can sometimes be confusing. For instance, comparing top.a to top.b, then comparing top.a to top.c may produce error messages that are hard to understand, since top.a is compared twice.
datafile1 /usr/local/designs/cpu1/sim/full.sst \
-pos 10 -neg 10 \
-posedge
The backslash must be the last character on the line.
compare and clkcompare allow a when option. This option is used to describe a Verilog expression that is used to selectively turn off or filter certain error messages.
Parsing the when option is a special case of white space parsing. White space parsing is turned off, and a double-quote delimited string is parsed. This allows the complete Verilog expression language to be used in a when option while keeping the parser simple. During a later phase of rule building, the Verilog expression will be parsed using a Verilog parser.
Examples:
compare . when "!top.reset"
clkcompare top.clk top when \
"!top.reset && (top.data != 0)"
When expressions can be any legal Verilog expression. Function calls are not supported.
The when expression is evaluated when an error is discovered. If the when expression evaluates to "true", the error will be reported. If the when expression evaluates to "false", the error will not be reported.
Examples:
compare . when "#-20(!top.reset)"
clkcompare top.clk top when \
"#30(!top.reset && (top.data != 0))"
compare . when \
"#-20(!top.reset) && #40(top.data)"
Files to compare are specified using the datafile1 and datafile2 commands in the rules file, or by specifying a golden and test simulation results file in the Command Options.
Different file formats may be compared with each other.
If a non-SST file is specified to compare, then it will automatically be translated to an SST file, and the SST file will be used to compare. The generated SST file will be located in the same directory as the input file, and have the same name as the input file. The generated SST file will have a .sst suffix.
If some other naming rules should be used, you can use the translate command to put the file anywhere you like, and to name it anything you like:
translate /tmp/xyz.vcd ~/designs/cpu1/sst/xyz.dump
See the translate command below for more details. Using the translate command is not recommeded, unless you just want to translate once and then compare SST files directly.
The two variables may be in the same SST file, or in different SST files.
The variables to be compared are specified as parameters of the rule. For example:
compare top.adder0.sum top.adder1.sum
The variable or module names must be specified as fully qualified hierarchical paths from the top level in the design. For example, use top.clk instead of clk; use top.adder0.reg1 instead of adder0.reg1 or reg1.
Any legal Verilog name can be used in the rules file. This includes escaped names, part selects and bit selects. Concatenations are not legal.
Legal names include:
\top.$i3\.i2
top.databus[1:0]
top.databus[7:0]
top.databus
top.databus[1]
cpu.mult.reg1
-internal, -boundary and -depth.If a name is specified it is first searched for as a variable name. If no variable name can be found, it is searched for as a module name. If no module name can be found, an error message will be reported, and rule file processing will continue with the next rule.
Comparing modules is a very effective way to do comparisons without having to write many rules. It is also an easy way to generate many error messages about unimportant variables. Module compares can be controlled using the -depth, -internal and -boundary options.
A Verilog escaped name:
\top.$i1$i2
The delimiting white space is not part of the module or variable name, but is required to terminate the escape. This means that when an escaped name is used it should always end with more than one white space character. (The first white space will be part of the variable name, the second will separate the next item on the command.)
The following command does not work. There is only one space after top.\$i3.ib2.
compare top.\$i3.ib2 -pos 10ns
A correct version is
compare top.\$i3.ib2 -pos 10ns
compare, clkcompare and stability commands take a variable number of arguments. There is either one or two names to compare. Generally, if there is one name, that name must exist in both the golden and the test files. If there are two names, the first name must exist in the golden file, the second one must exist in the test file.
Variable and module names can be referenced from different files by using the "::" notation. The golden file is always file "1", the test file is always file "2" (see datafile1 and datafile2 commands). To reference a variable in a particular file, use the file number and the "::".
This line behaves exactly like the default. The "1::" and "2::" are redundant and not needed:
compare 1::top.bus 2::top.bus
This line compares two signals, both from the test file:
compare 2::top.data1 2::top.data2
This line compares a signal from the test file with a signal from the golden file (reverses the default order):
compare 2::top.bit1 1::top.bit2
Default behavior, compare top.bus from two different files:
compare top.bus
The signal top.bus must exist in both the golden and the test files.
Default behavior, compare top.data1 from the golden simulation with top.data2 from the test simulation:
compare top.data1 top.data2
nosequencetime
compare . -depth 1 -internal -maxerrors 50
These two rules turns sequencetime off, and then compare all the internal signals at depth 1. If there are more than 50 errors on a signal, skip to the next signal.
Using the Options Setup Menu allows complete flexibility in creating global option settings that apply to the all the rules in the rules file.
Rules that are specified in the rules file have a hierarchical lookup mechanism. Some options will be taken in "first-come" order, some options are taken as the max or min of all the values found.
For example, if a compare command does not have a tolerance window defined, the tolerance setting on the datafile1 command will be checked. If the datafile1 command has no tolerance defined, the tolerance setting in the Options Setup Menu will be checked. If there is no tolerance set in the Options Setup Menu, then the program default will be used.
compare rule options are searched for in the following order:
Compare rule.
Datafile statement.
GUI Settings.
Program Defaults.
clkcompare rule options are search for in the following order:
Clkcompare rule.
Clkdef statement.
Datafile statement.
GUI Settings.
Program Defaults.
To define two clocks with setups of 20ns and 10ns, and holds of 10ns:
clkdef clk10 top.clk -setup 10ns -hold 10ns
clkdef clk20 top.clk -setup 20ns -hold 10ns
Now these clocks can be used in clkcompare statements:
clkcompare clk10 top.module1
clkcompare clk20 top.module2
clkcompare clk20 top.module3
clkcompare clk20 top.module4
To use the clocks and override the hold time:
clkcompare clk10 top.module5 -hold 5ns
clkcompare clk20 top.module6 -hold 0
Using time units:
compare top.signal -tol 20ns
clkdef clk top.clk -sample 15ns
clkcompare top.clk top -pos 1us -neg 100ns
Time Time Unit Power of Ten
as -18
femtoseconds fs -15
picoseconds ps -12
nanoseconds ns -9
microseconds us -6
milliseconds ms -3
cs -2
ds -1
seconds s 0
Ds 1
hs 2
kiloseconds ks 3
Megaseconds Ms 6
Gigaseconds Gs 9
Ts 12
Ps 15
Es 18
Warning: If the timescale of the simulation is larger than the result of a timescale option, the time will be zero. For example, if the simulation is in "seconds", and a time of "-pos 10ms" is specified, the actual time used will be 0.
In normal operation, DAI Comparescan ignores the strength value.
If the -checkstrength option is used in the rules file on a compare command then DAI Comparescan will guarantee that the strengths match exactly when a comparison is performed.
In Verilog, the strengths are defined as in the table below.
| Strength Name | Abbreviation |
|---|---|
| Supply | Su |
| Strong | St |
| Pull | Pu |
| Large | La |
| Weak | We |
| Medium | Me |
| Small | Sm |
| highz | HiZ |
Verilog signals can also have ranges of strengths. DAI Comparescan does not support ranges of strengths.
In VHDL, many different values and strengths can be used.
| Signal Value | Abbreviation |
|---|---|
| Uninitialized | U |
| Forcing unknown | X |
| Forcing 0 | 0 |
| Forcing 1 | 1 |
| High Imepdance | Z |
| Weak unknown | W |
| Weak 0 | L |
| Weak 1 | H |
| Don't care | - |
datafile1 filename [options]The datafile command is used to specify a SST or other simulation result file.
This command should appear only once in a rules file and should appear before any comparison commands.
datafile1 is used to define the golden simulation results file.
In any rules file, only one datafile1 command and only one datafile2 command may be given.
If a datafile command is not provided in the rules file, then the datafiles specified in the GUI will be used. If a datafile command is given in the rules file, it will override any specified in the GUI.
Examples
datafile1 golden.sst
datafile2 filename [options]The datafile command is used to specify a SST or other simulation result file.
This command should appear only once in a rules file and should appear before any comparison commands.
datafile2 is used to define the test or secondary simulation results file.
In any rules file, only one datafile1 command and only one datafile2 command may be given.
If a datafile command is not provided in the rules file, then the datafiles specified in the GUI will be used. If a datafile command is given in the rules file, it will override any specified in the GUI.
Examples
datafile2 test.sst
To compare all signals from two different files:
compare . [options]
To compare "name1" from two different files:
compare name1 [options]
To compare "name1" from the golden simulation with "name2" from the test simulation:
compare name1 name2 [options]
Note that name1 and name2 above can be fully specified hierarchical signal names or module names.
When two signals are compared using compare, each event on the golden signal must match an event on the test signal. If a golden event is missed, or if extra test events occur an error will be flagged.
A tolerance window can be used to allow events within the window to match. Using a tolerance window allows events within the tolerance window to be considered "equal". If no tolerance window is specified, each golden event must be matched by a test event at exactly the same time. The tolerance window is always measured relative to the golden event.
If miscompares due to timing differences exist in a comparison report, they can often be eliminated by using a larger tolerance window. Changing the tolerance window will not eliminate errors caused by extra events or missing events.
If a tolerance window is specified, the golden event will be matched with the test event that is the "best" match. The best match is the match closest to the golden event.
The example above was generated with:
datafile1 golden.sst
datafile2 test.sst
compare -neg 50ns -pos 30ns top.s1
The options, -neg 50ns and -pos 30ns specify a tolerance window that starts 50 nanoseconds before the golden event and ends 30 nanoseconds after the golden event. A matching test event must exist within this window. Tolerance windows are always measured relative to the golden event.
The option top.s1 is the name of the signal to compare. If a single name is specified to compare, then both the golden and the secondary SST files are searched for the name. The compare will be performed on the signal from two different SST files.
To compare all signals in all modules:
compare .
compare top.sig1
To compare two signals from the golden sst file:
datafile1 golden.sst
datafile2 test.sst
compare 1::top.sig1 1::top.sig2
or
datafile1 golden.sst
compare top.sig1 top.sig2
To compare two signals, allowing a 20ns tolerance window:
compare top.sig1 top.sig2 -tol 20ns
To compare two signals, allowing for a 10 ns tolerance window before the golden event and a 15 ns tolerance window after the golden event:
compare top.sig1 top.sig2 -neg 10ns -pos 15ns
compare top.module1
To compare two signals in two modules from the golden sst file:
datafile1 golden.sst
datafile2 test.sst
compare 1::top.module1 1::top.module2
or
datafile1 golden.sst
compare top.module2 top.module2
To compare the signals in two modules, allowing a 20ns tolerance window:
compare top.module1 top.module2 -tol 20ns
To compare the signals in two modules, allowing for a 10 ns tolerance window before the golden event and a 15 ns tolerance window after the golden event:
compare top.sig1 top.sig2 -neg 10ns -pos 15ns
compare command.
clkdef clockDefinitionName clockSignal [options]
Clock Definition statements are used to define a clock that can be used later in a clkcompare. A clock definition is a simple name that refers to a signal from the design with a combination of specific options.
clkdef clk1 top.cpu.clk1
clkdef clk_check1 top.cpu.clk1 -setup 20ns -hold 20ns
clkdef clk_check2 top.cpu.clk1 -setup 10ns -hold 10ns
Above, clk1 is defined as a reference to top.cpu.clk1. clk_check1 is defined as a reference to the same clock, but with a setup and hold time of 20ns. clk_check2 is defined as a reference to the same clock again, but with a setup and hold of 10ns.
If no options are desired on a clock, the clkdef statement can be eliminated, and the actual signal name used in the clkcompare statement:
clkdef clk1 top.clk
clkcompare clk1 top.signal
becomes
clkcompare top.clk top.signal
This short-cut is useful when no special clkdef options are required.
clkcompare commands are used to sample and compare signals within a clock cycle. The signals are sampled on an edge of a clock signal. The actual sampling time can be moved relative to the clock edge using the -sample option.
Once the signals are sampled, their levels are compared. If the levels don't match, an error is reported.
A fully specified clkcompare statement has four arguments although only two are required. The required arguments are the clock signal and the signal or module to compare. Any argument not specified will be filled in by the parser before the rule is executed.
The four arguments for a fully specified clkcompare are:
clock1 for signal1
signal1
clock2 for signal2
signal2
If only two arguments are specified, they are assumed to be the clock name and the signal or module name, respectively. The clock name and signal name are re-used for the unspecified arguments.
If only three arguments are specified, they are assumed to be the clock name and the two signal or module names, respectively. The clock name is re-used.
// Compare all signals from two different files
// using clockDefinitionName.
clkcompare clockDefinitionName . [options]
// Compare name from two different files using
// clockDefinitionName.
clkcompare clockDefinitionName name [options]
// Compare name1 and name2 using clockDefinitionName.
clkcompare clockDefinitionName name1 name2 [options]
// Compare name1 using clockDefinitionName from the
// golden file with name2 using clockDefinitionName from
// the test file..
clkcompare clockDefinitionName name1 \
clockDefinitionName name2 [options]
// Compare name1 and name2 using a separate clock for each.
clkcompare clockDefinitionName1 name1 \
clockDefinitionName2 name2 [options]
datafile1 golden.sst
datafile2 test.sst
clkdef clk1 top.clk
clkcompare clk1 top.s1 -setup 20 -hold 10
A stability check is performed at the clock edge.
datafile1 golden.sst
datafile2 test.sst
clkdef clk1 top.clk -sample 75ns
clkcompare clk1 top.s1 -setup 20ns -hold 10ns
At the sample point a "stability" check is also performed.
clkcompare and stability commands.
// Perform setup and hold checks on signal "name" using
// clock "clockDefinitionName".
stability clockDefinitionName name [options]
A stability check is a setup and hold check at the sample point in a clock cycle. Use a stability check to guarantee that signals are not changing within some window around an event.
The signal specified in the clockDefinitionName does not have to be a true clock. It can be any single bit signal in either the golden or test simulations.
The same setup and hold check is performed as in a clkcompare, but level comparison between signals is performed.
The clkcompare example,
clkcompare clk1 top.s1 -setup 20ns -hold 10ns
without the level compare would be the following stability command:
stability clk top.s1 -setup 20ns -hold 10ns
All clkcompare options are available with the stability command.
If sequencetime is turned on there are more events to process and comparison will be slower.
nosequencetime command will ignore zero delay events on a signal. This is the default. statemapping command defines a mapping between states and allows the user to define how states are matched.For example:
We have a chip design with a signal named net12. We 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'.
We would like to allow 'X' in the golden simulation to match a '1' or a '0' in the test simulation.
datafile1 rtl-golden.sst
datafile2 gate-test.sst
statemapping goldenXok \
01xz \
0:1000 \
1:0100 \
x:1110 \
z:0001
compare top.net12 -statemapping goldenXok
By default, no statemapping is used. Values must match exactly, but strength is ignored.
See the general option called -checkstrength and -ignorestrength.
statemapping Normal \
01xz \
0:1000 \
1:0100 \
x:0010 \
z:0001
statemapping MatchesX \
01xz \
0:1000 \
1:0100 \
x:1111 \
z:0001
statemapping AllXsMatch \
01xz \
0:1010 \
1:0110 \
x:1111 \
z:0011
datafile1 sst/state1.sst
compare top.clk top.n_pull -statemapping XXX
compare top.clk top.n_pull -statemapping MatchesX
compare top.clk top.n_strong -statemapping Normal
compare top.clk top.n_supply -ignorestrength
compare top.clk top.n_weak -checkstrength
threshold command defines a mapping from an analog value to a single bit.
threshold HH \
0(0:2.0) \
St1(3.0:5.0) \
Sux(2.5)
threshold XXX \
0(0:2.0) \
St1(3.0:5.0) \
SuX(2.5)
// Repeated threshold table -> Error.
threshold XXX 0(0:2.0)
threshold YYY \
0(<2.5) \
St1(>3.0) \
Sux(2.5)
threshold ZZZ \
0(<=2.5) \
St1(>3.0)
datafile1 sst/state1.sst
// Width mismatch.
compare top.clk top.real_number -threshold HH
compare top.real_number top.real_number_5 \
-threshold XXX
compare top.real_number top.real_number_5 \
-threshold1 XXX \
-threshold2 YYY
report command will generate an error report into a file or to standard output. If no filename is specified, the report will be printed on standard output.To generate a short summary report on standard output:
report -r1
To generate a full report on standard output:
report -r2
To generate a summary report in a file:
report -r1 summary.rpt
To generate a full report in a file:
report -r2 full.rpt
To generate both the summary and the full report in a file:
report -r1 -r2 all.rpt
Multiple report commands are not allowed. You may only specify report once in the rules file.
A Summary report contains the number and type of errors, along with the first 10 errors, sorted by time.
A Full report contains the number and type of errors, with a complete listing of every error in the database, sorted by time.
savedata command will save the DAI Comparescan error database into a file for later viewing.
savedata test1.csd
savedata design1.csd
For example, when doing a comparison in batch mode that you may want to examine at a later time, use the following rules file:
datafile1 golden.sst
datafile2 test.sst
compare .
savedata c1.csd
Later, the database file can be viewed by using File-->Open or by using the command line:
% comparescan c1.csd
The savedata command should be used at the end of the rules file.
loaddata command will read an error database previously saved using the rules file command named savedata, or the menu items File-->Save or File-->SaveAs.
loaddata test1.csd
This command should rarely be used. You are more likely to use File-->Open to load a previously saved database.
translate command will translate a simulation results file format into an SST file.
translate [-f] input-file-name \
[sst-output-file-name]
If the sst-output-file-name is not specified, a name will be generated automatically from the input-file-name. The generated sst-output-file-name will be the same as the input-file-name, after removing any extension, and adding the ".sst" extension.
For example:
translate /simresults/cpu1/test1.vcd
will generate a file named /simresults/cpu1/test1.sst and
translate /simresults/cpu1/test2
will generate a file named /simresults/cpu1/test2.sst.
If the sst-output-file-name is newer than the input-file-name, the file will not be generated.
If the sst-output-file-name already exists, it will not be overwritten unless the -f flag is also specified. The -f flag forces the output file to be written, even if it exists.
For example:
translate /simresults/cpu1/test1.vcd \
verilog.sst
translate -f /simresults/cpu1/test2.vcd \
verilog.sst
The file formats currently supported include:
Verilog VCD
Epic Simulation output files
HSPICE list (.lis) files
NutMeg files
Silos simulation history files (SunOS 4 platform only)
Zycad output (ASCII)
HSPICE .tr0
Qsim (Compass)
Generally, all formats supported by DAI Signalscan will be supported.
datafile1 or datafile2 commands; using the command line; or using the GUI options settings. If DAI Comparescan finds a non-SST file specified, that file will be automatically translated into an SST file . The comparison will then proceed using the generated SST file.For example:
datafile1 golden.vcd
datafile2 test.vcd
compare . -maxerrors 20
is equivalent to
translate golden.vcd
translate test.vcd
datafile1 golden.sst
datafile2 test.sst
compare . -maxerrors 20
Using two different rules files allows more flexibility with how translated files get generated.
Rules file for translation (xlat.rules):
translate xyz.vcd /tmp/bigspace/xyz.sst
translate abc.vcd /tmp/bigspace/abc.sst
Rules file for compare (comp.rules):
datafile1 /tmp/bigspace/xyz.sst
datafile2 /tmp/bigspace/abc.sst
compare .
Then run DAI Comparescan twice, once to translate the files and once to compare the files:
% comparescan -batch xlat.rules
% comparescan comp.rules
translate commandUsing a translate command is convenient because you have more flexibility about where the output file is located.
Letting datafile1 or datafile2 translate your simulation results has the following features:
datafile1 xyz.vcd
datafile2 abc.vcd
compare .
<RulesFile> = [<MiscCommands>] [<DatafileCommands>]
[<CompareCommands>]
<Datafile Commands> =
[<datafile1>] |
[<datafile1> <datafile2>] |
<empty>
<CompareCommands> =
[<AbsoluteCompareCommands> <CompareCommands>] |
[<ClockCompareCommands> <CompareCommands>] |
<empty>
<AbsoluteCompareCommands> =
<AbsoluteCommand> |
<AbsoluteCommand> <AbsoluteCompareCommands>
<ClockCompareCommands> =
<ClockCompareSequence> |
<ClockCompareSequence> <ClockCompareCommands>
<ClockCompareSequence> =
<ClockDefCommand> <ClockCompareCommand> |
<ClockDefCommand> <StabilityCommand>
<AbsoluteCompareCommand> =
"comare" <varOrModule> [<options>] |
"compare" <varOrModule> <varOrModule> [<options>]
<ClockDefCommand> =
"clkdef" <clkDefName> <singleBitVariable> [<options>]
<ClockCompareCommand> =
"clkcompare" <clkDefName> <varOrModule> [<options>] |
"clkcompare" <clkDefName> <varOrModule> <varOrModule> [<options>] |
"clkcompare" <clkDefName> <varOrModule> <clkDefName> <varOrModule> [<options>]
<StabilityCommand> =
"stability" <clkDefName> <varOrModule> [<options>]
<clkDefName> =
<ASCII ClockDef Name> |
<singleBitVariable>
<ASCII ClockDef Name> =
ASCII string. Does not have to be related to the design.
<singleBitVariable> = A variable defined in the design with width = 1.
<varOrModule> = The name of a variable or a module within the design. For example:
top
top.adder3
top.cpu.register.shifter.reg1
top.cpu.register.shifter.reg1.i
top.sum
top.sum[0:31]
top.sum[2:4]
top.adder3.i
Special case name - "."
<options> = Argc/Argv style options set for each "rule".
For example:
-start 10ns
-setup 10ps
-hold 130
when "databus == 32"
| |
|