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=sig1cancels 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,sig2will 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 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=sig1is equivalent to:
BREAK PULSE=sig1 SPIKE=sig1 NEAR=sig1The 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=5sets 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=50sets 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: