`BREAK` Command

Causes simulation to stop when user-specified conditions occur.

Command	`BREAK`
Abbreviation	`BR`
Category	Simulation Control

Function

The BREAK command causes simulation to stop when user-specified conditions occur. At a breakpoint, the state of the simulated circuit is "frozen", allowing the user to perform interactive debugging (probe signals, change delays, resimulate, etc.) or to control the course of future simulation.

Previously-set BREAK conditions are cancelled using the NO prefix. Unless explicitly indicated, keyword options that support the keyword=value field format also support this format with the NO prefix. For example:

NO BREAK RISE=sig1

cancels the specific break when a rise transition occurs at signal sig1. All keyword options support the keyword: field format with the NO prefix. For example:

NO BREAK RISE:

cancels all previous breakpoints on rise transitions.

Usage

See the Section Setting Simulation Breakpoints in Simulation Options for a complete description of the BREAK command.

The BREAK command can be restricted to a specified interval of tests, for patterns, or time, for waveforms, with the PRANGE keyword option:

BREAK PRANGE=<prange spec>

Break On The Occurrence Of Signal Transitions

The CHANGE keyword specifies any level transition; either a rise, 0→X, 0→1, X→1, or a fall, 1→X, 1→0, X→0:

BREAK CHANGE=<signals>

sets a breakpoint when any of the specified signals changes state, while:

BREAK CHANGE:

sets a breakpoint when any transition occurs (for single-stepping through the simulation).

The DECAY keyword specifies a decay to Z (floating unknown):

BREAK DECAY=<signals>

sets a breakpoint when any of the specified signals decays, while:

BREAK DECAY:

sets a breakpoint when any signal decays.

The RISE, FALL, CHANGE, X, and DECAY keywords accept the same type of signal specification as the LIST keyword.

The FALL keyword specifies a fall transition; 1→X, 1→0, X→0:

BREAK FALL=<signals>

sets a breakpoint when any of the specified signals executes a fall transition, while:

BREAK FALL:

sets a breakpoint when any signal executes a fall transition.

The MEMLATCH keyword specifies a transition from a known state to an unknown state at a SIMIC primitive D-latch or edge-triggered flip-flop due to a sensitized unknown input (e.g., unknown clock):

BREAK MEMLATCH=<signals_ff>

sets a breakpoint when an unknown input value is sensitized at a built-in memory element whose output is one of the specified signals, while:

BREAK MEMLATCH:

sets a breakpoint when the state of any built-in memory element becomes unknown due to a sensitized unknown input.

The RISE keyword specifies a rise transition; 0→X, 0→1, X→1:

BREAK RISE=<signals>

sets a breakpoint when any of the specified signals executes a rise transition.

For example:

BREAK RISE=sig1,sig2

will cause a break from simulation any time signals sig1 or sig2 execute a transition to logic-1. The command:

BREAK RISE:

sets a breakpoint when any signal executes a rise transition.

The X keyword specifies a level transition from a known state to an unknown state, 1→X, 0→X:

BREAK X=<signals>

sets a breakpoint when any of the specified signals becomes unknown, while:

BREAK X:

sets a breakpoint when any signal becomes unknown.

Break On Multi-Signal Pattern Matching

The PATTERN keyword enables breakpoints that trigger when multiple signals simultaneously match a specified pattern. This is useful for detecting specific circuit states involving combinations of signals.

Basic Syntax

BREAK PATTERN=<pattern> LIST=<signals>

Sets a breakpoint when the specified signals collectively match the given pattern. Both PATTERN and LIST keywords are required.

Pattern Symbols

Pattern strings consist of the following symbols:

0 - Matches logic 0 (LEVEL_ZERO)
1 - Matches logic 1 (LEVEL_ONE)
X - Matches unknown level (LEVEL_X)
Z - Matches high-impedance with floating strength only
? - Don't care wildcard, matches any value

Pattern Radix Formats

Patterns can be specified in multiple radix formats using prefix symbols. All prefixes work without quotes.

Binary (Default)

BREAK PATTERN=0101 LIST=A,B,C,D
BREAK PATTERN=^0101 LIST=A,B,C,D  ; Explicit binary prefix

One character per signal. This is the default format when no prefix is specified.

Hexadecimal

BREAK PATTERN=#A5 LIST=DATA[7:0]

Prefix: #. One hex digit represents 4 signals. Signal count must be divisible by 4. Value A5 hex = 10100101 binary.

Octal

BREAK PATTERN=*752 LIST=ADDR[8:0]

Prefix: *. One octal digit represents 3 signals. Signal count must be divisible by 3. Value 752 octal = 111101010 binary.

Integer Formats

BREAK PATTERN=%42 LIST=COUNT[5:0]      ; 2's complement (default)
BREAK PATTERN=2%42 LIST=COUNT[5:0]    ; 2's complement (explicit)
BREAK PATTERN=1%-5 LIST=COUNT[5:0]    ; 1's complement
BREAK PATTERN=u%100 LIST=COUNT[7:0]   ; Unsigned

Integer formats use all signals in the list (maximum 64 bits) and convert the integer to binary representation:

% or 2% - 2's complement signed integer (default)
1% - 1's complement signed integer
u% - Unsigned integer

Examples

Binary Pattern with Wildcards

BREAK PATTERN=1?00 LIST=CLK,DATA,STATUS,ENABLE

Breaks when CLK=1, STATUS=0, ENABLE=0, regardless of DATA value.

Hex Pattern on Bus

BREAK PATTERN=#FF LIST=DATA[7:0]

Breaks when 8-bit DATA bus equals 11111111 (all ones).

Integer Value Match

BREAK PATTERN=%42 LIST=COUNTER[7:0]

Breaks when 8-bit COUNTER equals decimal 42 (00101010 binary).

Vector Expansion

DEFINE CONTROL.HEX=CLK,RESET,ENABLE,MODE
BREAK PATTERN=1010 LIST=CONTROL

Vectors defined with DEFINE are expanded when used in the LIST keyword.

Pattern Match Detection

Pattern breakpoints trigger when signals transition to states that match the specified pattern. The match check occurs during signal propagation, not during pattern application. When a match occurs, a compact message is displayed:

        0 B     3> PATTERN MATCHED: 1010

The message shows the actual values that matched in compact binary format. This format scales efficiently for large signal counts—a 32-signal pattern generates approximately 65 characters versus 170+ if signal names were included.

Clearing Pattern Breakpoints

NO BREAK PATTERN:

Clears the current pattern breakpoint. Note that the LIST keyword is not used with NO BREAK.

Error Conditions

Pattern breakpoints will generate errors for:

Pattern size mismatch - Pattern length doesn't match signal count (e.g., 3-char pattern for 4 signals)
Radix size mismatch - Signal count not divisible by radix (e.g., hex pattern with 5 signals)
Invalid characters - Characters other than 0, 1, X, Z, ? in pattern
No signal list - PATTERN specified without LIST keyword
Duplicate signals - Same signal appears multiple times in list (creates conflicting requirements)
Pattern too large - Integer patterns limited to 64 bits

Notes

Pattern matching checks all signals simultaneously—all must match for the breakpoint to trigger
The ? wildcard allows monitoring subset conditions (e.g., "break when A=1 and C=0, regardless of B and D")
For DEPTH-format signals, values are automatically converted to MIMIC format for matching
Duplicate signals in the list are not allowed as they create impossible matching conditions (e.g., requiring signal A to be both 0 and 1)
Pattern breakpoints respect PRANGE restrictions like other breakpoint types

Break On The Occurrence Of Timing Hazards

The timing hazards described in this section are primarily due to the distribution of propagation delays within the circuit.

The HAZARD keyword is a shorthand designation of all switching hazards— pulse, spike, or near. The command:

BREAK HAZARD=<signals>

sets a breakpoint when a pulse, spike, or near hazard occurs at any of the specified signals. For example, the command:

BREAK HAZARD=sig1

is equivalent to:

BREAK PULSE=sig1 SPIKE=sig1 NEAR=sig1

The command:

BREAK HAZARD:

sets a breakpoint when a pulse, spike, or near hazard occurs at any signal.

The MEMSPIKE keyword specifies the occurrence of a spike hazard at a flip-flop primitive, and is therefore a subset of SPIKE. It narrows focus to spikes that could cause steady-state errors. The command:

BREAK MEMSPIKE=<signals_ff>

sets a breakpoint when a spike hazard occurs at any of the specified flip-flop output signals, while:

BREAK MEMSPIKE:

sets a breakpoint when a spike hazard occurs at any flip-flop. When a spike occurs at a flip-flop for which the MEMSPIKE keyword option has been specified, the break message will contain memspike as the cause of the break, rather than spike.

The NEAR keyword specifies the occurrence of a near hazard (see also DEFINE NEAR). The command:

BREAK NEAR=<signals>

sets a breakpoint when a near hazard occurs at any of the specified signals, while:

BREAK NEAR:

sets a breakpoint when a near hazard occurs at any signal.

The PULSE keyword specifies the occurrence of a pulse hazard (see also DEFINE PULSE). The command:

BREAK PULSE=<signals>

sets a breakpoint when a pulse hazard occurs at any of the specified signals, while:

BREAK PULSE:

sets a breakpoint when a pulse hazard occurs at any signal.

The SPIKE keyword specifies the occurrence of a spike hazard. The command:

BREAK SPIKE=<signals>

sets a breakpoint when a spike hazard occurs at any of the specified signals, while:

BREAK SPIKE:

sets a breakpoint when a spike hazard occurs at any signal.

The STROBE keyword specifies the condition that a strobe error occurs at any primary output or bus. This is only defined for tester emulation mode. The command:

BREAK STROBE:

sets a breakpoint for this situation.

The UNSTABLE keyword designates the condition that a change of primary input state has occurred while the circuit was still in an unstable state (loss of fundamental mode of operation for waveform and tester emulation modes). The command:

BREAK UNSTABLE:

sets a breakpoint for this situation.

Break On The Occurrence Of Timing Check Violations

Breakpoints can be set for timing check violations at SIMIC latches and flip-flops. The PARTS keyword is used to specify which memory elements to monitor for the selected timing check(s). The command:

BREAK PARTS=<parts_ff> <timing-check>: ...

selects specific memory elements to monitor. For example,

BREAK PARTS=ff1,ff2 SETUP.D: PW:

sets breakpoints for data setup-time and all pulse-width check violations at the memory elements named ff1 and ff2.

The command:

BREAK PARTS: <timing-check>: ...

sets breakpoints when a violation of the specified timing checks occurs at any memory element. For example,

BREAK PARTS: SETUP: HOLD: PW:

will cause any timing check violation at any memory element to trigger a break from simulation.

Break On The Occurrence Of Wire-tie Conflicts

The CONFLICT keyword specifies a wire-tie conflict. The command:

BREAK CONFLICT=<signals>

sets a breakpoint when a wire-tie conflict occurs at any of the specified signals, while the command:

BREAK CONFLICT:

sets a breakpoint when any wire-tie conflict occurs.

The CONFLICT keyword accepts the same type of signal specification as the LIST keyword.

Break On Oscillation

The OSCILLATION keyword specifies excessive activity in response to a single change of input state (see also DEFINE OSCILLATION). The command:

BREAK OSCILLATION:

sets a breakpoint when any signal exhibits excessive activity.

Break Periodically

The PSTEP keyword specifies a stable-state count. The command:

BREAK PSTEP=<integer>

causes a break from simulation whenever the circuit state has become stable the specified number of times. For example,

BREAK PSTEP=5

sets a breakpoint every fifth stable state. If the stimulus mode is patterns, the break would occur every fifth test. If, however, the stimulus mode is waveform (time-based) or tester emulation, the break interval could exceed five tests, since the circuit state may not stabilize by the end of each test.

The colon form must be used to cancel breakpoints based on stable states:

BREAK PSTEP:

The TSTEP keyword specifies a time interval. The command:

BREAK TSTEP=<integer>

causes periodic breaks from simulation with the specified interval (number of time-units). For example,

BREAK TSTEP=50

sets a breakpoint every fifty time-units.

The colon form must be used to cancel breakpoints based on elapsed time:

BREAK TSTEP:

Directing Break Messages

Whenever a break occurs, SIMIC issues one or more messages describing the cause or causes. By default, these messages are directed to the terminal. The command:

NO BREAK TERM:

disables break messages at the terminal. These messages can be re-enabled at the terminal with the command:

BREAK TERM:

Break messages can also be directed a file with the FILE keyword. The form:

BREAK FILE=<file name>

explicitly specifies a file name, and possibly its extension. The command:

BREAK FILE:

specifies a file with the default file name (see DEFINE FILE). If the second form is used, or if no file extension is specified in the first form, the file's default extension is brk.

Regardless of how they were enabled, break messages to a file are disabled with the command:

NO BREAK FILE:

← Back to Run Commands Catalog