.\"
.\" Copyright (c) 1990 by Synopsys, Inc.
.\"      ALL RIGHTS RESERVED
.\" This program is proprietary and confidential information of
.\" Synopsys, Inc. and may be used and disclosed only as authorized 
.\" in a license agreement controlling such use and disclosure.
.\"
.\" Use the .me macros with this file (please)
.\" I don't think it is -me macros but it is -ms macros -- SKN
.\"
.\" oscpages.mac
.\" Header and footer macros with e/o oscillating L/R
.de PT
.ll 6.5i	# line length
.lt 6.5i	# title line length
.if o .po 1i	# odd page left margin
.if e .po 1i	# even page left margin

.pc %
.nr PN \\n%
.if o .tl `\\*(LH`\\*(CH`\\*(RH`	#odd page header line
.if e .tl `\\*(RH`\\*(CH`\\*(LH`	#even page header line

..
.de BT
.nr PX \\n(.s
.nr PF \\n(.f
.ft 1
.ps \\n(PS
'lt \\n(LTu
.po \\n(POu
.if o .tl `\\*(LF`\\*(CF`\\*(RF`	#odd page footer line
.if e .tl `\\*(RF`\\*(CF`\\*(LF`	#even page footer line
.ft \\n(PF
.ps \\n(PX
..
.\" Header definitions
.ds CH \s10\fBOn-Line \fIhelp\fB Files\fR\s0
.ds LH \s10\fBVSS Command Reference\fR\s0	
'	# below, "H" is help subject
.ds RH \s10\fB\\s+1\\*(]H\\s-1\fR\s0
.\" Footer definitions
.\".ds LF \s10\fSRev. 2.2\fR\s0
'	# next line prints page number "2-#"
.ds RF \s10\fB2-%\fR\s0
.\"
.\" hS is the Help Subject macro
.\" Syntax which the on-line help parsing stuff accepts:
.\"	.hS SUBJECT "synopsis message"
.\"
.\" No quotes in or around SUBJECT; no quotes in the synopsis message.
.\" The synopsis message does not appear in the printed version,
.\" only with the -l option to the on-line help command.
.\"
.de hS
.ds ]H \\$1
.bp
.ce 1
\\&\\fB\\$1\\fP
.sp 2
..
.\"
.\" hB is the Help Break macro
.\" In the printed documentation, this request becomes a blank line. It forces
.\" the on-line help pager to think it found the end of a page.
.\"
.\" For the on-line pager to work correctly, this must be called
.\" as the only request on a line.
.\"
.de hB
.sp 1
..
.bp
.pn +1
This is a junk page
.nf
.hS ABORT "Abort the current monitor"
Syntax:
	ABORT

ABORT causes the Simulator to stop command execution.

While executing commands associated with a monitor, the Simulator
immediately exits the monitor. This exit happens even if the Simulator
executes an ABORT command while executing a COMM or INCLUDE file
called by the monitor.

When a stop-monitor ABORTs, the stop does not take place. The
simulation continues as if a continue-monitor had finished normally.
You can use this feature to create a conditional stop-monitor.

When the Simulator encounters the ABORT command while executing
commands that are not associated with a monitor, the Simulator stops
command execution and returns you to the primary prompt.

See also:  EXIT, QUIT.

.hS ABSTIME "Display the current absolute runtime"
Syntax:
	ABSTIME

ABSTIME causes the Simulator to display the current runtime.

.hS ASSIGN "Assign a new value to a signal, variable or generic"
Syntax:
	ASSIGN [-after delay] (vhdl_expression) {vhdl_object_name}

ASSIGN sets the value of the given variable(s), signal(s), and
generic(s) to the value of the given VHDL expression.

For an architecture residing on the external Simulator (hardware
accelerator), the ASSIGN command works only for ports and signals, not
for generics. No variables are allowed in an architecture residing on
the external Simulator.

The "-after delay" clause creates a "delayed action" monitor. This
monitor fires after the specified time and performs the specified
assignment.

The "-after delay" clause is not allowed on signals which represent
SmartWindows.

Assigning to signals during signal evaluation produces unpredictable
results. Therefore, the Simulator automatically schedules these
assignments as "delayed action" monitors. These monitors fire after
signal evaluation, but before the Simulator resumes any processes.

Generics are intended to remain constant throughout the simulation.
Therefore, ASSIGN is only legal for a subset of all generics. The
subset consists of generics that appear only on the right hand side of
a variable or signal assignment (except in a signal attribute). If the
generic appears anywhere else in the design, the assignment command
issues an error message.

See also: HOLD CONTROL_VARIABLES for DACTION_STUB, WIFIN.

.hS BACKANNOTATION "Backannotate VHDL delay using SDF format"
vhdlsim provides a mechanism to support VHDL delay backannotation
using the Standard Delay Format SDF (OVI Standard Delay File SDF
Format specification, revision 1.0). The vhdlsim Simulator maps the
SDF timing information (intrinsic delays, iopath delays, interconnect
delays and so forth) into VHDL generic parameters. To invoke vhdlsim
to read SDF files, specify the Simulator command line arguments or use
the Simulator include command.

The timing information in the SDF files can cover the whole VHDL
design or any portion of the hierarchy. If two or more SDF files
annotate an instance, the last SDF file vhdlsim scans may overwrite
the previous timing values.

When you invoke the Simulator, it reads the vss setup file
(.synopsys_vss.setup) to determine how to annotate the timing
information (naming convention and wild card capability) in the SDF
file. The Simulator then reads the SDF files and annotates the timing
into its data structures.

The vhdlsim program also stores the SDF header in signals declared in
a VHDL package. $SYNOPSYS/arch/packages/sdf_header.vhd defines this
package. If vhdlsim does not reference this package, it will not
update it.

The vhdlsim Simulator supports the backannotation of macro cells. By
using the attribute PROPAGATE_VALUE defined in the Synopsys ATTRIBUTES
package, you can specify which internal generic values in the macro
cell the Simulator updates.

The vhdlsim Simulator supports the state-dependent timing
backannotation. By using the attributes SDT_CONDITION, SDT_VALUE_NAME,
and SDT_VALUE defined in the Synopsys ATTRIBUTES package, you can
specify under some conditions which generic values the Simulator updates.

See also:  VHDLSIM, .SYNOPSYS_VSS.SETUP.

.hS CALL "Call a VHDL procedure" 
Syntax:
	CALL procedure_name

CALL executes the named VHDL procedure.

Note: The EVALUATE command executes functions.

See also: EVALUATE.
.hS CD "Set the Current Working declarative Region"
Syntax:
	CD [declarative_region]

CD changes the current working declarative region in your model.

A declarative region is a slash-punctuated path name from the top of your model
to a specific declarative region within your VHDL design hierarchy.

Suppose you want function F as your current working declarative region
in process P in component instance TOP. Enter:

	CD   /TOP/P/F

The Simulator interprets all VHDL names not preceded by '/' relative
to the current working declarative region.

If you do not specify a declarative region, the HOME control variable
specifies the new current working declarative region.

See also:  CONTROL_VARIABLES for HOME, DESIGN_HIERARCHY,
	STATUS_VARIABLES for CWR.
.hS CHECKPOINT "Create a snapshot of the current simulation"
Syntax:
	CHECKPOINT [-every interval [-replace]] checkpointFileName

CHECKPOINT command creates a snapshot of the current simulation and
places it in the file checkpointFileName.

If you specify the -every command line option, the simulator creates a
snapshot every interval seconds of process execution time (using the
virtual timer). The checkpoint command names the new snapshot file
created at each interval by using the form checkpointFileName_%d where
%d is the snapshot iteration count. If you specify the -replace option
with the -every option, even though the simulator checkpoints at each
interval, it keeps only the most recent snapshot in checkpointFileName.

See also: RESTART.
.hS CLOSE "Close an output device"
Syntax:
	CLOSE device_tag

CLOSE closes the specified device. The Simulator flushes all pending
output and the device no longer appears open to the Simulator.
Subsequent attempts to redirect output to a closed file looses the
previous contents of that file.

See also:  OPEN, OUTPUT_REDIRECTION.
.hS COMM "Create/list/remove Simulator command procedures"
Syntax:
	COMM [-r | -l] {comm_name}
    or	COMM -n name_space {comm_name}

COMM defines, redefines, or lists simulation command procedures.

The Simulator responds to COMM xyz with the secondary prompt
instead of the usual primary execution prompt. At the secondary prompt,
enter one or more Simulator commands exactly as you want to store them
in your command procedure. Enter END to exit command definition mode and
return to regular execution mode.

COMM options:
	-r	Removes the specified command procedures.
	-l	Lists the contents of the specified command procedures.
	-n	Sets the default wildcard expansion name space for the
		command procedure(s) to the name space specified.
		The valid name spaces are VHDL, MONITOR, COMM, SHVAR and
		FILE. If you do not specify a name space, the
		Simulator uses VHDL.

COMM with no options or arguments lists the names of all command procedures.

See also:  EXIT, POSITIONAL_PARAMETERS, SHIFT.
.hS CONTINUE "Change monitors to be CONTINUE monitors"
Syntax:
	CONTINUE {name}

CONTINUE changes a set of monitors to CONTINUE so when the monitors fire,
they do not stop the simulation.

See also:  MONITOR, STOP, DISABLE, ENABLE, REDIRECT.

.hS CONTROL_VARIABLES "Variables that affect the behavior of the Simulator"
Some Simulator shell variables are unique to the Simulator. You can
only set them to specific values that affect the behavior of the
Simulator.

You may set variables to the shortest unambiguous prefix of a legal
value. The Simulator then sets the variable to the value of the
complete string.

Below is an alphabetical listing of the Simulator control variables
with the set of legal values, the default value and a description of
how the values affect the behavior of the Simulator:

ABS_REGION
	Legal values:  TRUE, FALSE.  Default is TRUE.
	Affects the initialization of certain monitors. If set to
	TRUE, the name the Simulator prints in the default monitor
	FPRINT statement is an absolute name (it begins with a /). If
	set to FALSE, the name the Simulator prints out is the one you
	specified when you created the monitor. Note: Changing the
	value of ABS_REGION does not affect existing monitors.

ASSERT_IGNORE
	Legal values: NOTE, WARNING, ERROR, FAILURE, NOIGNORE.  Default is 
	NOIGNORE.  The first four values suppress the assertion message when 
	there are VHDL assertion violations of that severity or lower. If the 
	value of ASSERT_IGNORE is NOIGNORE, the simulation never suppresses 
	for assertion violations.  When an assertion is suppressed, the 
        behavior is as though that assertion never existed in the design; the 
        simulator will not stop at a suppressed assertion due to an assertion 
        violation.

ASSERT_STOP
	Legal values: NOTE, WARNING, ERROR, FAILURE, NOSTOP.  Default is 
	ERROR.  The first four values stop the simulation when there are VHDL 
	assertion violations of that severity or greater. If the value of 
	ASSERT_STOP is NOSTOP, the simulation never stops for assertion 
	violations. The Simulator always reports all assertion violations 
	regardless of level, but the simulation stops only at the level you 
	specify with ASSERT_STOP.  See also ASSERT_IGNORE.

BASE
        Legal values:  HEXADECIMAL, OCTAL, BINARY.  Default is HEXADECIMAL.
        Determines the base in which the Simulator displays bit vectors from
        commands such as EVALUATE and LS. For BASE values
        HEXADECIMAL and OCTAL, the variable EXTRA_BITS affects the print
        format.

COV_DISABLE
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If you do not specify either the -d or the -e option in a COVERAGE
        command, this variable determines the initial enabled/disabled
        status of a coverage monitor. If the value of COV_DISABLE is FALSE,
        the Simulator initially enables the coverage monitor.

CWP
        Legal values:  Absolute name of a VHDL process. There is no default.
        Used when the Simulator needs a process stack to execute a command (for
        example, printing the value of a subprogram local variable). Normally
        if you do not set this variable, the Simulator uses the CRP status
        variable.

CYCLE_POINT
        Legal values:  ENTER, BEGIN, MIDDLE, END, LEAVE.  Default is LEAVE.
        The MONITOR and TRACE commands use this variable to determine where
        in the simulation cycle they fire time monitors or strobe traces
        if you do not specify a cycle point in the MONITOR/TRACE command line.

DACTION_STUB
        Legal values:  any word beginning with a letter. Default is da.
        Names the "delayed action" monitors. The Simulator 
	appends small integers to the end of the stub you 
	specify if you create multiple monitors or if the stub
        name is the name of an existing monitor.

ECHO_EXECUTE
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If set to TRUE, the Simulator prints command lines just before it
        executes them. ECHO_EXECUTE allows you to see the results of variable
        substitution and wildcard expansion.

ECHO_NAME
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If set to TRUE, the MONITOR and TRACE commands print the names of
        the monitors they create.

ECHO_READ
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If set to true, the Simulator prints command lines as it reads them.

EXTRA_BITS
        Legal values:  LEFT, RIGHT, PAD.  Default is PAD.
        Determines how the Simulator displays bit and mvl7 vectors in
        hexadecimal or octal when the number of bits is not an exact multiple
        of 3 (for octal) or 4 (for hexadecimal). If EXTRA_BITS is set to PAD,
        the Simulator pads the vector with zeros on the left. Otherwise, it
        displays the vector as a concatenation of a vector, in the
        desired base, and a binary vector that contains the extra bits.
        The LEFT and RIGHT values of EXTRA_BITS specify whether the Simulator
        takes the extra bits from the left or right end of the bit vector
        value.

HOME
        Legal values: Absolute name of any declarative region. Default
	is /. The CD command uses this variable when you invoke it
	with no arguments.

LOCKSTEP
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If TRUE, the Simulator waits for window output operations
        to complete before it continues with the simulation. This
        keeps the window displays closer to the true state of the simulation
        but slows down simulations with lots of output to windows.
.bp
MON_DISABLE
        Legal values:  TRUE, FALSE.  Default is FALSE.
        When you do not use the -d and the -e options in the MONITOR command,
        this variable determines the initial enabled/disabled status of the
        monitor. If the value of MON_DISABLE is FALSE, the monitor is
        initially enabled.

MON_ISTOP
        Legal values:  TRUE, FALSE.  Default is FALSE.
        Determines how the Simulator responds to keyboard interrupts
	during monitor code execution. If set to TRUE, the Simulator
	stops unconditionally on an interrupt, throwing away
        any pending monitor code. If set to FALSE, the Simulator asks
        whether or not you want to stop immediately. If you answer YES, the
        Simulator stops as described above. If you answer NO, the Simulator
        stops after it executes all pending monitor code.

MON_STOP
        Legal values:  TRUE, FALSE.  Default is FALSE.
        Determines the initial stop/continue status of the
        monitor when you do not specify the -s and the -c options in a
        MONITOR command. If the value of MON_STOP is FALSE, the monitor is
        initially a continue monitor.

MON_STUB
        Legal values:  any word beginning with a letter.  Default is 'm'.
        Names the monitors created when you do not specify the -n option in the
        MONITOR command. The Simulator appends small integers to the end
        of the stub you specify if it creates multiple monitors or if the
        stub name is the name of an existing monitor.

PROMPT
        Legal values:  any value.  Default is # .
        The Simulator prints this variable when it is expecting
        user input.

PROMPT2
        Legal values:  any value.  Default is > .
        The Simulator prints this variable when it expects
        a continuation line for a deferred-execution multi-line Simulator
        command, such as FOREACH, EDIT, or COMM. Use the END command to
        exit from deferred-execution mode to the primary command prompt.

STRICT_TICK
        Legal values:  TRUE, FALSE.  Default is FALSE.
        If set to TRUE, the Simulator requires unabbreviated selector names
        when doing wildcard expansion. If set to FALSE, the Simulator
        requires only the shortest unique prefix. Setting this variable to
        TRUE allows you to inspect the value of user defined attributes
        that are prefixes of wildcard selectors.

.bp
TRACE_DISABLE
        Legal values:  TRUE, FALSE.  Default is FALSE.
        This variable determines the initial enabled/disabled status when
        you do not use the -d or the -e options in the TRACE command line.
        If the value of TRACE_DISABLE is FALSE, the trace is initially enabled

TRACE_STUB
        Legal values:  any word beginning with a letter.  Default is t.
        Names traces when you do not use the -n flag in the
        TRACE command. The Simulator appends small integers to the end of
        the stub you specify if the stub name is the name of an existing trace.

TRAP
        Legal values:  TRUE, FALSE.  Default is FALSE.
        Partially determines how the Simulator responds to keyboard
	interrupts. If set to TRUE, the Simulator warns that 
	interrupts are currently disabled and asks whether it should
        ignore the interrupt and continue the simulation. If you answer
        YES, the Simulator continues without interruption. If you answer
        NO, the Simulator uses the value of the control variable MON_ISTOP
        to determine its stopping behavior.

USE
        Legal values:  space separated list of directory names.
        Default is the value of the .synopsys_vss.setup USE variable.
        If set, the Simulator searches the directories in the order
        specified for VHDL source code files. Once it locates a file,
        it reads it into the simulation. Changes to USE do not allow you to
        find a different file with the same name. However, if the Simulator
        cannot locate the source file, then changing USE allows you to locate
        the file.

See also:  STATUS_VARIABLES, MONITOR_VARIABLES, POSITIONAL_PARAMETERS,
        VARIABLES.

.hS COVERAGE "Produce a file containing source code coverage data"
Syntax:
	COVERAGE [-a] [-e | -d] [-n name_stub] {vhdl_srcfile_name}

The meanings of the option flags are as follows:

	-a 		Append the coverage data to the existing coverage file.
			(Allows coverage data to be collected across several
			simulations)

	-e or -d\ \ \ 	COVERAGE monitor enabled or disabled when it is created.

	-n		Name the monitor using name_stub.

The VHDL Simulator provides a mechanism for keeping a count of the
number of times it executes each line of VHDL source code in a data
file (known as a coverage data file). You can then manipulate the data
using post processoring tools (including 'coverage', that merges the
data with the VHDL source code).

The COVERAGE command creates a coverage monitor for each source files
you specify. If you do not specify a source file, COVERAGE creates a
coverage monitor for each and every source file used in the
simulation.

The Simulator actually creates the coverage data file when the it
exits or when it deletes the coverage monitor.

Notes: 1. You can create only one coverage monitor per source file.
       2. COVERAGE command is not supported for compiled code in this
	  release.

See also:  MONITOR, DISABLE, ENABLE, DELETE, COV_DISABLE.
.hS DECLARED "Distinguish between overloaded items"
Syntax:
	name'DECLARED(number)

The 'DECLARED operator specifies one of a set of overloaded items. 
The "number" specifies which of the items the Simulator selects. 

For Example: If "number" is 1, the Simulator selects the first
declared item with the name "name". If "number" is 2 then the
Simulator selects the second declared item with the name "name".

.hS DELETE "Delete the named monitors/traces"
Syntax:
	DELETE {name}

The DELETE command deletes the named monitors/traces.

See also:  MONITOR, TRACE, COVERAGE,  DISABLE, ENABLE.
.hS DESIGN_HIERARCHY "Simulator representation of the design hierarchy"
A structure is a named part of a simulation. Structures include:

	Entities, Architectures, Processes, Functions, Procedures, Blocks,
	Signals, Constants, Variables, Packages, Types and so forth.

A structure has a name that reflects its location in the topology.
Because VHDL has a hierarchical topology capability, a structure
has a potentially complex name composed of several 'components'.
Syntactically, separate components with the slash (/) character.

You can form a structure name descending through the hierarchy of
a topology specifying the composite 'components' from left to right
until you reach the desired part.

By using wildcards and selectors, you can specify a large
collection of structures with a single regular expression.

Assume you have an entity 'E', an architecture 'A', and a package 'P'.
The package contains a function 'BVTOI' that contains a variable 'I'.
The entity 'E' contains a function 'SETUP' and the architecture A
contains a process 'P'. Process 'P' contains a type declaration 'T'
and a variable 'V'.

The valid names are

	/P		- The package
	/P/BVTOI\ \ \ 	- The function within the package 'P'
	/P/BVTOI/I\ \ 	- The variable within the function 'BVTOI'

	/E/P		- The process within the entity 'E'
	/E/P/T		- The type definition within process 'P'
	/E/P/V		- The variable within process 'P'
	/E/SETUP\ \ \ 	- The function setup within Entity 'E'

NOTE: You place structures in the entity under the architecture.

The Simulator has a concept of 'Current Working declarative Region'
(CWR). You can reference structures relative to the Current Working
Declarative Region.

For example, with a working region of /E/P

	T = /E/P/T, and V = /E/P/V

See also:  WILDCARDS, SELECTORS, STATUS_VARIABLES for CWR.
.hS DISABLE "Disable a named monitor/trace"
Syntax:
	DISABLE {name}

The DISABLE command disables a set of monitors. The monitors do not fire,
even when the conditions they are monitoring occur.

See also:  MONITOR, TRACE, COVERAGE,  ENABLE, DELETE.

.hS DRIVERS "Show the drivers of signal and their values"
Syntax:
        DRIVERS [-d|-e] {signal_name}

DRIVERS command prints the name of the drivers for the signals specified
as arguments. It also prints the value of each of the driver if the signal
is resolved. The name of the driver is the hierarchical path name of the
VHDL process contributing the driver.

DRIVERS accepts the following options:

-d      Show drivers contributing to the driving value of the signal.

-e      Show drivers contributing to the effective value of the signal.
        If no option is specified this is assumed to be the default.

.hS DUMP_MEMORY "Dump a VHDL array/memory_component into a memory image file"
Syntax:
      DUMP_MEMORY  [output_format_option]  [-start start_addr]  [-end end_addr]
		   vhdl_array | vhdl_memory_component    mem_file_name

      the options are:
	  -ascii_h(default) 	  - Hexadecimal VSS ASCII format
	  -ascii_o 		  - Octal VSS ASCII format
	  -ascii_b 		  - Binary VSS ASCII format
	  -mmicro 		  - Synopsys metaMicro memory image format
	  -waft,-wfiles,-wbinary  - QTC WAFT,WFILES, or WBINARY format 
	  -start,-end		  - The start,end of the memory being dumped 

The DUMP_MEMORY command writes the contents of a VHDL array variable,
constant or component instantiation of a memory primitive to a memory
image file (mem_file_name).

The vhdl_memory_components currently support the DLATRAM and DLATROM 
primitives from the COMPONENTS package.

DUMP_MEMORY works for following two cases:

  1. vhdl_array or vhdl_memory_component located in the
     Vhdl Software Simulator (VHDLSIM).

     - The options -start, and -end are not supported, instead use
       a slice to dump a piece of the array.
       e.g.,
		#dump_memory /e/c/p/m(8 to 15) 
	instead of:	
		#dump_memory -start 8 -end 15 /e/c
	

  2. vhdl_memory_components located in the external backplane
     Simulator (hardware accelerator)

     - You can dump only memory components of the types DLATRAM and DLATROM
       from memories in the external backplane.

     - It does not support the following flags for memories located in the
       external backplane:  -mmicro, -waft, -wfiles, -wbinary
    
See LOAD_MEMORY for a description of various kinds of VHDL array
objects that you can dump and examples of VHDL memory components and
the Simulator ASCII format.

See the Synopsys VSS Expert Software Tools Manual for more
information on the DUMP_MEMORY command.
.hS ECHO "Echo arguments back"
Syntax:
	ECHO {arg}

The Simulator prints the arguments to the ECHO command, separated
by spaces. The ECHO command line is subject to variable
substitution and wildcard expansion.

ECHO is useful for printing messages from COMM procedures and INCLUDE
files, for displaying the value of Simulator shell variables (for
example, ECHO $CWR), and for viewing the results of wildcard expansion
(for example ECHO *'signal).

See also:  WILDCARDS, FPRINT.
.hS EDIT "Edit an existing monitor"
Syntax:
	EDIT monitor_name

EDIT causes the Simulator to enter monitor procedure-definition mode,
signified by the secondary prompt. This mode allows you to define
the commands associated with the named monitor.

At the secondary prompt, you enter simulation command lines exactly as
you wish the Simulator to execute them when the monitor fires. The
Simulator uses the lines you enter as replacement text for the default
FPRINT command, originally supplied to the monitor. You enter END to
leave procedure definition mode and return to the primary command line
prompt.

See also:  MONITOR, RENAME, LIST, COMM.
.hS ELABORATION "Elaboration of VHDL subprogram declarations"
After a subprogram call takes place, but before the Simulator executes
the statements contained in the subprogram, Simulator elaborates the
declarations that are local to the subprogram.

The Simulator can access the subprogram parameters, but not the local
data, when the subprogram it elaborates the subprogram.

After elaboration, the Simulator can access the local data in the
function or procedure.

When execution returns from the procedure or function, local data in
the procedure or function becomes inaccessible again.

See also:  DESIGN_HIERARCHY, CONTROL_VARIABLES for CWP, STATUS_VARIABLES for
	CRP and CWR.
.hS ENABLE "Enable a named monitor/trace"
Syntax:
	ENABLE {name}

The ENABLE command enables a set of monitors. The monitors fire when
the condition they are monitoring occurs.

See also: MONITOR, TRACE, COVERAGE, DISABLE.
.hS END "End the specification of a multi-line construct"
Syntax:
	END

END specifies the end of a multi-line construct. Enter the END
command to exit from command-definition mode (secondary prompt), when
you finish defining a simulation procedure. The Simulator then
returns you to the regular primary prompt for command execution.

Commands that use the deferred execution secondary prompt to allow
definition of multi-line command procedures are COMM, EDIT, and
FOREACH. Use END to exit from a command definition sequence following
COMM, EDIT, WHILE, IF, or FOREACH.

See also:  FOREACH, WHILE, IF, COMM, EDIT.
.hS ENVIRONMENT "Print all variables, monitors and command procedures"
Syntax:
	ENVIRONMENT

ENVIRONMENT displays information about the current simulation
environment. The information includes your monitors and command
procedures, plus the names and values of all user-definable simulation
variables.

You can use the ENVIRONMENT command with the redirect operator, >, to save
information in a file. For example,

	ENVIRONMENT > MYFILE

sends the current environment data to MYFILE.

You can use the INCLUDE command to include this environment in another
simulation. For example, the command INCLUDE MYFILE restores the
environment saved above.

Read-only simulation status variables are not included in the output
of ENVIRONMENT, since you cannot set these variables.

This command is temporary, and may not be available in future releases.

See also:  SET, LIST, COMM, INCLUDE.
.hS EVALUATE "Print out the value of a VHDL expression"
Syntax:
	EVALUATE vhdl_expression {vhdl_expression}
    OR  EVALUATE (vhdl_expression) {(vhdl_expression)}

The EVALUATE command evaluates and prints each VHDL expression.

Enclose the expression in parenthesis if the expression contains
either spaces or wildcard characters. This will protect the expression
from interpretation.

If the expression includes the division operator (/), the operator
should be replaced with a double slash (//). This will distinguish it
from the hierarchical pathname separator.

See also:  FPRINT, LS.
.hS EXIT "Exit the enclosing command procedure or include file"
Syntax:
	EXIT

When the Simulator encounters an EXIT command, execution leaves the
current COMM procedure, monitor, or INCLUDE file as if execution had
"fallen off the end" of the sequence of commands.

See also:  LPBREAK, LPCONTINUE, ABORT.
.hS FLUSH "Flush pending output on the named output device"
Syntax:
	FLUSH {device_tag}

FLUSH writes any buffered data on the given output device out to the
device. If you do not give any arguments, the Simulator flushes the
buffer for the "current" output device.

See also: OPEN, OUTPUT_REDIRECTION
.hS FOREACH "Iterate through commands with a changing shell variable"
Syntax:
	FOREACH index_name IN {word}
		{command_line}
	END

The Simulator executes the commands in the FOREACH loop once for each
word following the IN keyword. It sets the value of the shell variable
specified by index_name to the corresponding word for each iteration
of the loop.

You can list the words explicitly or generate the list through
variable substitution and wildcard expansion.

See also:  LPBREAK, LPCONTINUE, WHILE.
.hS FPRINT "Print formatted output"
Syntax:
	FPRINT format_string {argument}

FPRINT prints formatted output. It is similar to the printf function
in C programming language.

The Simulator interprets the format_string as a VHDL expression which
must be of type STRING. It copies each character in the format_string
to the output in left to right order with the exception of conversion
specifications and backslash escapes, described below.

FPRINT interprets subsequent arguments according to the corresponding
conversion specification in the format_string. The number of conversion
specifications and the number of additional arguments must match.

The character % introduces each conversion specification. The
conversion specification ends with a conversion character. The
conversion characters and their meanings are described below:

b	FPRINT interprets the argument as a VHDL expression whose type
	is a single dimension array of BIT. FPRINT prints the argument
	in binary notation.

o	FPRINT interprets the argument as a VHDL expression whose type
	is a single dimension array of BIT. FPRINT prints it out in
	octal notation.	The EXTRA_BITS control variable affects this
	conversion.

x	FPRINT interprets the argument as a VHDL expression whose type
	is a single dimension array of BIT. FPRINT prints it out in
	hexadecimal notation. The EXTRA_BITS control variable affects
	this conversion.

r	FPRINT interprets the argument as a VHDL expression. FPRINT
	prints it out in a "reasonable" default format. The EXTRA_BITS
	and BASE control variables affect the conversion.

t	FPRINT copies the argument to the output without any further
	interpretation.

c	FPRINT interprets the argument as a VHDL expression whose value can
	be represented as a character literal. FPRINT prints the
	argument without the enclosing quotes.

s	FPRINT interprets the argument as a VHDL expression of type
	STRING. It copies each character in the string to the output
	in left to right order.
	This differs from %r in two ways: (1) FPRINT does not surround
	the output with	double quotes, nor does it represent embedded
	double as two quotes, and (2) FPRINT copies non-graphic
	characters directly to the output rather than represent them
	as enumeration literals.

d	FPRINT interprets the argument as a VHDL expression of any
	integer type. It prints the argument in decimal format.

e,f,g	FPRINT interprets the argument as a VHDL expression of any
	floating point type. It converts the argument according to the
	rules for the C language printf statement on your machine.
	This specification may yield an	ASCII representation of the
	value which is not lexically legal VHDL.

If the character after the % is not a conversion character, FPRINT
does not print that character. Therefore, print '%' by typing '%%'.

The conversion characters may have a width/precision part of the conversion
specification between the % and the conversion character. This part of the
conversion specification behaves according to the rules for the C language
printf statement on your machine.

Within the format_string, you may represent certain non-graphic
characters and the backslash \\ using the following escape sequences.

\\n	LF, newline
\\t	HT, horizontal tab
\\\\	\\, backslash
\\ddd	ddd, the bit pattern specified by the 1, 2, or 3 octal digits

If the character following a backslash is not one of those specified,
FPRINF ignores the backslash.

See also:  ECHO, CONTROL_VARIABLES for BASE and EXTRA_BITS.

.hS GET_VSS_PRODUCT "Print the VSS product in use."
Syntax:
	GET_VSS_PRODUCT

GET_VSS_PRODUCT prints the name of the VSS product in use. It prints
"pro" if VSS-Pro is being used and "expert" if VSS-Expert is being
used.

You can use this command in the VSS simulation scripts to test for the
product being used.

.hS HELP "On-line help for the vhdlsim Simulator Control Language"
Syntax:
        HELP [-l | subject] 
    or  HELP vss-NNN

Use the -l flag to get a listing all available subjects.
Specify a subject to get information on an individual topic.

The above second format of HELP displays information about a given
error number from the analyzer and simulator error manuals. The user
can also display complete error manual pages using the unix command
"man". 

For long HELP messages, the Simulator prompts you to
        press RETURN to continue, or
        enter q to quit help and return to command mode.

Simulator Commands:
abort		assign		backannotation	call		cd
close		comm		continue        delete		disable
dump_memory	echo		edit		enable		end
environment	evaluate	exit		flush		foreach
fprint		help		icon		if		include
list		lmsi		load_memory	local		logtime
lpbreak		lpcontinue	ls		monitor		netlist_dump
next		open		quit		redirect        rename
restart		run		set		shift		show
slist		status		step		stop		trace
unicon		unset		vcdaddobjects	vcdcomment	vcddumpall
vcddumpobjects	vcdfile		vcdflush	vcdlimit	vcdoff
vcdon		wfield		where		while 		wmove
wsize

Other topics:
ASIC_simulation_violation_message
control_variables	declared		design_hierarchy
elaboration		monitor_variables	output_redirection
positional_parameters	quotation		search_string
selectors               shell_escape		simulation_windows
status_variables	syntax			variables
.synopsys_vss.setup	wildcards		vhdlsim
vhdldbx			vhdldbx_textviewer_win	vhdldbx_pulldown_menus

.hS HOLD "Hold the value of signals (stuck at)"
Syntax:
        HOLD [-after delay] (vhdl_expression) {vhdl_object_name}

HOLD holds the value of the given VHDL signal or signals to the value
of the VHDL expression. It releases the value when you assign a new value
to the signal by using the ASSIGN command. The Simulator ignores
simulation stimulus when it holds a signal.

(Note: For architectures residing on the external Simulator (hardware
       accelerator), the HOLD command works only for ports and
       signals, not for generics. No variables are allowed in
       the architecture residing on the external Simulator)

The "-after delay" clause causes the creation of a "delayed action"
monitor. This monitor fires after the specified time and performs
the specified signal hold.

Assigning to signals during signal evaluation produces unpredictable
results. Therefore, the Simulator automatically schedules these
assignments as "delayed action" monitors. These monitors fire after
signal evaluation, but before processes resume.

See also: ASSIGN, CONTROL_VARIABLES for DACTION_STUB, WIFIN.

.hS ICON "Turn a simulation window into an icon"
Syntax:
        ICON window_tag

Turns the named window into an icon.

See also:  UICON, SIMULATION_WINDOWS.

.hS IF "Conditionally branch over/to commands"
Syntax:
	IF (boolean_vhdl_expression) THEN
		{command_line}
	[ ELSE
		{command_line} ]
	END IF

The IF construct is executed as follows:

	i)   The Simulator evaluates the boolean_vhdl_expression. 

	ii)  If the value of the expression is TRUE then the lines after
	     the THEN  are executed (through to either the END IF or ELSE).

	     If the value of the expression is FALSE and there is an ELSE
	     clause, then the lines after the ELSE are executed.

	iii) Continue command execution after the END IF.

See also: WHILE, FOREACH, EVALUATE.
.hS INCLUDE "Read and execute commands from a file"
Syntax:
        INCLUDE [-e] file_name {arg}
        INCLUDE -sdf[_min |_max |_typ |_top declregion |_af] sdffilename

The first form of INCLUDE reads and executes commands from a file.
The syntax of the file_name obeys the file naming conventions of your
operating system. If you use the -e flag, the Simulator displays the lines
as it reads them from the file.

You can prepare INCLUDE files with your favorite editor. Positional parameters
are available for include files.

The above second format of INCLUDE reads SDF file sdffilename to
incorporate delay timing and backannotation in the VHDL Simulator.
You can specify the following options on the INCLUDE command:

-sdf_min
        Extracts the minimum timing values from the SDF file.

-sdf_max
        Extracts the maximum timing values from the SDF file.

-sdf_typ
        Extracts the typical timing values from the SDF file.

-sdf_top declregion
        Overlays the timing values for the sub-portion of the design
        below the named declarative region.

-sdf_af
        Creates an assign file that will perform the override of the
        timing value. Takes the name of the file from the SDF
        file. For example, given an SDF file myfile.sdf it will create
	an assign file myfile.inc.

See also:  BACKANNOTATION, COMM, POSITIONAL_PARAMETERS, SHIFT.

.hS LIST "List monitors and traces"
Syntax:
	LIST [-l] {monitor_name}

The LIST command lists information about the monitors you specify.
For each monitor you specify, LIST prints the monitor's name, stop/continue
status, enabled/disabled status, and details of the monitor type.

The -l flag causes LIST to print the sequence of commands currently
associated with each monitor.

LIST without any monitor_name arguments prints all existing monitors.

See also:  MONITOR, EDIT, RENAME.
.hS LMSI "Commands for the LMSI modeler"
Syntax:
	LMSI LIST DEVICES|IDS
     or	LMSI LIST PINS device_name

     or	LMSI LOG ON  instance_name|instance_id#  [file_name]
     or	LMSI LOG ON  ALL
     or	LMSI LOG OFF instance_name|instance_id#
     or LMSI LOG OFF ALL

     or	LMSI XPROPAGATION HIGH|LOW|FLOAT|PREVIOUS scope_all_dev_pin
     or	LMSI XPROPAGATION ON|OFF scope_all_dev_pin
     or	LMSI XPROPAGATION SEQUENCES number_of_sequences
     or	LMSI XPROPAGATION SEED random_seed

     or	LMSI LOOP ON [instance_name|instance_id#]
     or	LMSI LOOP OFF

     or	LMSI DELAY ON|OFF  scope_all_dev
     or	LMSI VIOLATIONS ON|OFF  scope_all_dev

scope_all_dev: ALL |  device_definition_name

scope_all_dev_pin: ALL 
		   | device_definition_name ALL 
		   | device_definition_name pin_name


"LMSI" is the command interface to the Logic Modeling Corporation 
(LMC) hardware modeler. 

"LMSI LIST" shows information about the component instances which are
currently elaborated on the modeler, or lists pin names for a
particular device definition. The command can be used, for example, to
determine a device_definition_name, an instance_id#, an instance_name,
or a pin_name to be used as a parameter in one of the other LMSI
commands.

"LMSI LOG" turns on or off test vector logging (i.e., the creation of test 
vectors for later use by a production IC tester). See lm_log_test_vectors()
in "Simulator Integration Manual" from Logic Modeling.

"LMSI XPROPAGATION" sets various features for handling unknown propagation.
See lm_on_unknown().

"LMSI LOOP" turns on or off pattern looping for a particular instance.
Pattern looping repeatedly plays the pattern history to the specified
instance, so that, for example, the user can observe the waveform on
an oscilloscope. See lm_loop_patterns(). "LMSI LOOP ON" with no
instance_id# or instance_name turns ON pattern looping for the instance
specified in the previous "LMSI LOOP ON" command (error if none).

"LMSI DELAY" causes the modeler software to ignore (if the user types
"OFF") or use (if the user types "ON") Shell Software delay
information. Ignoring this information decreases the model evaluation
time. See lm_timing_information().

"LMSI VIOLATIONS" causes the modeler software to check (if the user
types "ON") for violations of the timing specifications in the Shell
Software or to ignore them ("OFF"). Note: this command is always
silently over-ridden by the "report timing_violations" Shell Software
statement.

As usual in the command interface, the user need only specify the first
few letters of the command keywords, enough to allow unique
identification ("command keywords" are the words shown in CAPS in the
syntax description above).  This feature is particularly appreciated
when typing "X" instead of "XPROPAGATION".  At present "LM" is enough
to uniquely identify "LMSI".  One potentially annoying implication is
that "A" and "AL" are recognized as "ALL"; this is fine unless there is
a pin_name or device_definition_name "A" (or "AL" or "ALL"): for
example, the command parser will recognize "LMSI XPROP HIGH MC68020 A"
as "LMSI XPROP HIGH MC68020 ALL", masking pin_name "A". Note that
instance names do not have this problem (they all have at least one /
in them).

As usual in VSS, all commands and keywords are case-insensitive.

.hS LOAD_MAP "Create a map from memory addresses to assembly source"
Syntax:
	LOAD_MAP [-l] [-v] file_name [array_name]

LOAD_MAP reads the lines of a Synopsys metaMicro assembly-code listings
(.lst) file into an array-type Simulator shell variable. The array
is indexed by memory addresses; the contents of the array are text lines
from the listing file. 

You produce listing files by running the software tools merge program.
You must invoke merge with the '-b d' option (b for base, d for decimal),
so that physical addresses are displayed in base 10.

The -l (long) flag places the whole metaMicro assembly instruction line,
including the metaMicro address, into the array variable.

The -v (verbose) flag displays the value of each array element as it is set.

If you do not specify the array name (array_name) then LOAD_MAP gives
it the same name as the assembly code listing file (file_name).

See the Synopsys VSS Expert Software Tools Manual, for more
information on metaMicro.

See also:  LOAD_MEMORY.
.hS LOAD_MEMORY "Load a memory image into a VHDL array/memory_component"
Syntax:
	LOAD_MEMORY  {vhdl_array | vhdl_memory_component}   mem_file_name

LOAD_MEMORY supports several image file formats:
	Hexadecimal, Octal, Binary VSS ASCII format
	Synopsys metaMicro Software Tools memory image format
	QTC WAFT, WFILES, WBINARY format

The LOAD_MEMORY command reads the contents of a memory image file into
an array variable, constant, or component instantiation of memory
primitive(DLATRAM or DLATROM) in your VHDL model.

The VHDL array variable must be a one-dimensional array and its index
subtype must be an integer type. The element type of the variable must
also be a one-dimensional array. The type of the array elements must
be an ennumeration type that contains the literals '0' and '1'.

LOAD_MEMORY files the VHDL array based on the address found in the
memory image file. If the memory image file has fewer elements than
the VHDL array, LOAD_MEMORY changes only the corresponding elements
(addresses) of the VHDL array. The rest of the VHDL array elements are
unaffected. If the memory image file has an address that does not
exist in the VHDL array, the Simulator issues a warning message and
ignores such elements in the memory image file.

LOAD_MEMORY fills each element of the VHDL array from right to left.
If the width of the VHDL array element is smaller than the width of
the memory image file element, the most significant (leftmost) bits of
the memory image file element are lost. If the corresponding entry in
the memory image file has fewer elements than the VHDL array element,
LOAD_MEMORY changes only the corresponding entries of the VHDL array
element. The rest of the VHDL array element is unaffected.

An example of a VHDL array that satisfies these conditions follows:

      type MVL4 is ('X', '0', '1', 'Z');
      -- This is the type of the array entries.

      type MVL4_VECTOR is array (natural range <>) of MVL4;
      -- This is the element type of the VHDL array elements.

      type MEMTYPE is array (natural range <>) of MVL4_VECTOR (31 downto 0);
      -- This is the VHDL variable type with an integer index subtype.
 
      variable MEM: MEMTYPE (0 to 1023);
      -- This is the VHDL array variable to be loaded.
.bp
An example of a VHDL design with a memory component is given below.


	library MVL_7;
	use MVL_7.types.all;
	use MVL_7.components.all;
	
	entity ram_top is
		port (DATAin: in MVL7_VECTOR(3 downto 0);
	      		DATAout: out MVL7_VECTOR(3 downto 0);
	      		ADDR: in MVL7_VECTOR(4 downto 0);
	      		WE: in MVL7;
	      		RE: in MVL7);
	end ram_top;

	architecture A of ram_top is
	begin
		C_RAM: DLATRAM
			generic map (4, 5, 6 ns, 9 ns)
			port map (DATAin, DATAout, ADDR, WE, RE);
	end A;

    The load_memory command for the C_RAM component is:

	load_memory <top_path>/C_RAM <mem_file_name>	      OR
	load_memory <top_path>/C_RAM/p/m <mem_file_name>

    Following is an example for the memory image file for the C_RAM:

	#use the # symbol as the first character for a comment line
	#address format: H(Hex) or B(Binary), or O(Octal)
	#data format: H(Hex) or B(Binary), or O(Octal)
	#default value for unspecified addresses: 0, 1, or X(Unknown)
	#0:0/0 sets the address 0 to value 0
	#set address 1 to 5 to values: a, b, c, d, and e
	#values for address 6 to 9 will be set to X
	#a:1f/f sets the address range a:1f(in Hex) to value f(in Hex)

	$ADDRESSFMT H
	$DATAFMT H
	$DEFAULTVALUE X

	0:0/0
	1/a;b;c;d;e;
	a:1f/f
	
Note: The VSS ASCII file format must have $ADDRESSFMT <> as the first
non-comment line.

Note: The MetaMicro and QTC memory formats can not be used to load memories
located in the external backplane.

See the Synopsys VSS Expert Software Tools and Core
Programs Manuals, for more information on metaMicro and VSS ASCII
image file formats.

See the QTC Software Foundry SF/Assembler manual for more information on the
QTC's WAFT, WFILES, and WBINARY image file formats.

See the Synopsys VSS Family Core Programs Manual for more
information on the LOAD_MEMORY command.

See also:  LOAD_MAP, DUMP_MEMORY.
.hS LOCAL "Make assignments to shell variables local to a comm"
Syntax:
	LOCAL {shell_variable_name}

Use LOCAL inside comm procedures and include files to localize the
effect of setting Simulator shell variables. At the end of the
enclosing comm or include file, the shell variables you specify with
the LOCAL command revert to the value they had when the Simulator
encountered the LOCAL command.

For example:

	# comm xxx
	\> local mon_stub
	\> set mon_stub event_
	\> mon event $*
	\> echo $last_name
	\> end
	# xxx S
	EVENT_
	# echo $mon_stub
	M

Because of the LOCAL command, the affect of setting the mon_stub shell
variable is seen only inside the comm.

See also:  COMM, INCLUDE, SET, VARIABLES.
.hS LOGTIME "Broadcast time to output devices"
Syntax:
	LOGTIME [-d | -e] device_tag {device_tag}

The meanings of the option flags are as follows:

	-e or -d\ \ \ 	enable (default) or disable time reporting

If LOGTIME is enabled (-e) for an output device, the Simulator
displays the current simulation time and time units on that device
whenever a monitor fires at a new simulated time. If you do not
specify any flags, then LOGTIME assumes -e (enable).

The Simulator automatically enables LOGTIME for the standard output
(usually the screen) when you invoke the Simulator.

You can obtain a list of devices with LOGTIME enabled using the OPEN
command without arguments.

See also: OPEN
.hS LPBREAK "Exit from an enclosing FOREACH loop"
Syntax:
	LPBREAK [n]

LPBREAK causes the Simulator to exit from enclosing FOREACH loop(s).
If n is missing, it defaults to 1. Otherwise, the Simulator exits from
'n' enclosing FOREACH loops.

See also:  LPCONTINUE, FOREACH, WHILE.
.hS LPCONTINUE "Cause the next iteration of an enclosing FOREACH loop"
Syntax:
	LPCONTINUE [n]

LPCONTINUE causes the next iteration of the n'th enclosing FOREACH loop
to begin. If n is missing, it defaults to 1.

See also:  LPBREAK, FOREACH, WHILE.
.hS LS "List VHDL names"
Syntax:
	LS [-t] [-v] {vhdl_name}

The LS command lists names from the VHDL name space. LS lists the name
specified or, if a specified name denotes a declarative region, LS
lists the names in that region. If you do not specify any names on the
command line, LS lists the names of everything declared in the current
working declarative region (CWR).

The -t flag causes LS to print the name's class (for example,
VARIABLE) with its corresponding type. If the name is an enumeration
type, LS also prints a list of the enumeration literals.

The -v flag causes LS to print the name's value.

See also:  EVALUATE, CD, STATUS_VARIABLES for CWR, CONTROL_VARIABLES for
	BASE and EXTRA_BITS.
.hS MONITOR "Create a monitor"
Syntax:
	MONITOR [options] STROBE start,delta[,stop] [cycle_point]
    or	MONITOR [options] AT absolute_time [cycle_point]
    or	MONITOR [options] AFTER relative_time [cycle_point]
    or	MONITOR [options] EVERY [cycle_point]
    or	MONITOR [options] ON [source_file] [startline[,endline]]
    or	MONITOR [options] OFF [source_file] [startline[,endline]]
    or	MONITOR [options] READ object_name {object_name}
    or	MONITOR [options] WRITE variable_name {variable_name}
    or	MONITOR [options] ACTIVE signal_name {signal_name}
    or	MONITOR [options] EVENT signal_name {signal_name}
    or	MONITOR [options] BLOCK process_name {process_name}
    or	MONITOR [options] UNBLOCK process_name {process_name}
    or	MONITOR [options] TPROCESS process_name {process_name}
    or	MONITOR [options] CALL subprogram_name {subprogram_name}
    or	MONITOR [options] ELABORATE subprogram_name {subprogram_name}
    or	MONITOR [options] RETURN subprogram_name {subprogram_name}

options:  [-c | -s] [-d | -e] [-tv] [-expr condition] [-o output_dev] 
		[-n monitor_name] [-x command]

cycle_point:  [ENTER | BEGIN | MIDDLE | END | LEAVE]

The MONITOR command creates monitors. A monitor is the "hook" you use
to extract results from your simulation. MONITOR lets you specify an
action or event that the Simulator can detect (a change on a signal or
the execution of a line of source code, for example). MONITOR assigns
this action or event a name (the monitor name) and usually, a sequence
of Simulator commands the Simulator executes when the monitor "fires".
A monitor fires when the specified event or action occurs.

Note:  The MONITOR command is not fully supported in compiled code.
       The description of MONITOR types near the end of this help
       page specifies which types are unsupported.

Monitors have a stop/continue status. If a monitor is a stop monitor
when it fires, the Simulator stops after it executes the monitor
commands. You then type RUN to resume the simulation. If a
monitor is a continue monitor when it fires, the Simulator continues
simulating after it executes the monitor commands.

Monitors also have an enabled/disabled status. A monitor only fires if
it is enabled when the specified action or event occurs.

The MONITOR command accepts following options:

-c or -s\ \ \ 	Creates monitors that are initially a continue (-c) or
		stop (-s) monitors. If you do not specify either,
		MONITOR uses the value of the control variable MON_STOP.

-e or -d\ \ \ 	Creates monitors that are initially enabled (-e) or
		disabled (-d). If you do not specify either, MONITOR
		uses the value of the control variable MON_DISABLE.

		Note: If you use multiple stop/continue or
		disable/enable flags, MONITOR uses the last flag.

-tv\ \ \ \ \ \ \ \ 	The -tv flag used by the debugger (vhdldbx).
		MONITOR uses -tv during the creation of ON monitors
		that alters the behavior of the monitors. Instead of
		sending vhdl source code information to the standard
		output, it creates a text viewer window to display the
		information. In stand-alone mode, MONITOR ignores the
		-tv flag.

-expr condition	Makes the monitor conditional, so that it fires only when
		the specified condition is true.  This option is supported
		only for signal and variable monitors in this release.
		Command procedures may be used to achieve the same effect, 
		but the -expr mechanism is more efficient and provides 
		better simulation performance.

-o output_dev\ \ 	Redirects output from the created monitors to
		output_dev. Normally you would previously open this
		device with an OPEN command.

-n name		Names the created monitor or monitors using name. The
		Simulator appends small integers to name to give each
		monitor created	a unique name.

-x command	Names the command to execute, when this monitor fires.
		The specified simulator command overrides the default
		command to be executed. Only one simulator command 
		(including command procedures) can
		be specified with the -x option. All errors occurring 
		in the command sequence will be shown during run time,
		when the monitor actually fires.
		EXAMPLE: (Note the usage of '^' characters to protect
			  the quotes in the fprint command)
		monitor -x ^fprint "%t %b\n" /E/BV/S /E/BV/S^ event S

Time monitors are monitors that specify STROBE, AT, AFTER or EVERY.
They monitor the passage of simulation time. Because there are
potentially many points of interest in the simulation between changes
in simulated time, you can specify the cycle_point at which you want a
time monitor to fire. If you do not specify a cycle point on the
MONITOR command line, the Simulator uses the value of the control
variable CYCLE_POINT.

Here is a description of each cycle point:

ENTER		- The monitor fires right after simulated time has
		  changed.  
BEGIN		- The monitor fires just before the Simulator
		  evaluates signals. 
MIDDLE		- The monitor fires after the Simulator evaluates signals 
		  but before it resumes processes.
END		- The monitor fires just after the Simulator has run
                  processes.
LEAVE		- The monitor fires just before simulated time changes.

Following are descriptions of the monitors:

MONITOR [options] STROBE start,delta[,stop] [cycle_point]
	This monitor fires at the time start and then every delta time units
	thereafter until the simulation reaches time stop. If you do
	not specify stop, the monitor continues to fire until
	simulated time overflows. Note that no spaces are allowed in the
	time specifications. A comma character (',') is used as a delimiter.

	EXAMPLE: monitor strobe 100,5,200
		 monitor strobe 20,40

MONITOR [options] AT absolute_time [cycle_point]
	This monitor fires once, at absolute_time. The Simulator
	deletes the monitor after it fires.
	EXAMPLE: monitor -s at 500

MONITOR [options] AFTER relative_time [cycle_point]
	This monitor fires every relative_time units, measured from the time
	of its creation.
	EXAMPLE: monitor -s after 20

MONITOR [options] EVERY [cycle_point]
	This monitor fires every time the Simulator reaches cycle_point. 
	MONITOR EVERY MIDDLE, for example, fires after signal
	evaluation but before processes are resumed.
	EXAMPLE: monitor every enter

MONITOR [options] ON [source_file] [startline[,endline]]
	This monitor fires when the Simulator executes the specified
	line or lines of the VHDL source file. If you do not specify
	source_file, MONITOR uses the value of the control variable
	FILE. If you omit both startline and endline, the Simulator
	monitors the whole source file. If you omit endline, the
	Simulator monitors only	startline.
	EXAMPLE: monitor on counter.vhd 50
	NOTE: This monitor is not supported in compiled code in this
	release.  


MONITOR [options] OFF [source_file] [startline[,endline]]
	This form is not really a monitor. It keeps ON and TPROCESS monitors
	and STEP and NEXT commands from firing on the lines you specify. The
	defaults are the same as for ON monitors. OFF monitors have no
	commands associated with them (they never fire), and stop/continue 
	does not apply to them. You can, however, enable and disable OFF
	monitors. An OFF monitor keeps other monitors from firing
	only when it is enabled. This monitor is useful for turning off
	line tracing in VHDL code you know works.
	EXAMPLE: monitor off types.vhd
	NOTE: This monitor is not supported in compiled code in this
	release.  

MONITOR [options] READ object_name {object_name}
	This monitor fires when the Simulator reads the specified
	object. The object must be a variable or a signal name.
	Multiple object names on the command line create multiple
	monitors.
	EXAMPLE: monitor read p/*'variable
	NOTE: This monitor is not supported in compiled code in this
	release.  

MONITOR [options] WRITE variable_name {variable_name}
	This monitor fires when the Simulator updates the specified
	variable is updated. Multiple variable names on the command
	line create multiple monitors.
	EXAMPLE: monitor write p/count
	NOTE: This monitor is supported in compiled code only if
	-debug flag was set in vhdlan.

MONITOR [options] ACTIVE signal_name {signal_name}
	This monitor fires when the specified signal is active. Multiple
	signal names on the command line create multiple monitors.
	EXAMPLE: monitor active *'signal

MONITOR [options] EVENT signal_name {signal_name}
	This monitor fires when an event occurs on the specified signal.
	Multiple signal names on the command line create multiple monitors.
	EXAMPLE: monitor event S

MONITOR [options] BLOCK process_name {process_name}
	This monitor fires when the specified process encounters a VHDL wait
	statement. Multiple process names on the command line create
	multiple monitors.
	EXAMPLE: monitor -s block A/_P0

MONITOR [options] UNBLOCK process_name {process_name}
	This monitor fires when the specified process resumes from a VHDL wait
	statement. Multiple process names on the command line create
	multiple monitors. Note: This monitor may fire more often than
	you expect for wait statements that contain a condition clause because
	the process unblocks to evaluate the condition and blocks again if
	the condition is false.
	EXAMPLE: monitor unblock */*'process

MONITOR [options] TPROCESS process_name {process_name}
	This monitor fires each time the specified process executes a line of
	VHDL source code. Multiple process names on the command line
	create multiple monitors. See the OFF monitor description for a
	method of reducing the firing rate of this monitor.
	EXAMPLE: monitor tprocess P1 P2
	NOTE: This monitor is not supported in compiled code in the
	v3.1a release.  

MONITOR [options] CALL subprogram_name {subprogram_name}
	This monitor fires when the Simulator calls the specified
	subprogram (procedure or function). Multiple subprogram names
	create multiple monitors. Typically, you will use ELABORATE
	instead of this monitor. This monitor is useful for debugging
	subprograms that call a function while elaborating their local
	declarations.
	EXAMPLE: monitor call f p
	NOTE: This monitor is not supported in compiled code in the
	v3.1a release.  

MONITOR [options] ELABORATE subprogram_name {subprogram_name}
	This monitor fires when the Simulator calls the specified
	subprogram (procedure or function) that has elaborated its
	local declarations. Multiple subprogram names create multiple
	monitors. At this point, you can set up monitors on the
	variables declared in a subprogram.
	EXAMPLE: monitor elaborate /package_1/*'procedure
	NOTE: This monitor is not supported in compiled code in the
	v3.1a release.  

MONITOR [options] RETURN subprogram_name {subprogram_name}
	This monitor fires when the specified subprogram (procedure or
	function) returns. Multiple subprograms names create
	multiple monitors. The monitor variable RET_VALUE is available
	at this point.
	EXAMPLE: monitor return /package_1/inc
	NOTE: This monitor is not supported in compiled code in the
	v3.1a release.  

If MONITOR encounters conflicting options on the command line, it uses
only the last (rightmost) option.

See also:  LIST, EDIT, MONITOR_VARIABLES, STOP, CONTINUE, DISABLE, ENABLE,
	DELETE, REDIRECT, RENAME, TRACE, COVERAGE, CONTROL_VARIABLES for MON_ISTOP,
	MON_STOP, MON_DISABLE, MON_STUB and CYCLE_POINT, STATUS_VARIABLES
	for LAST_NAME.
.hS MONITOR_VARIABLES "Variables that are available during monitor execution"
When a monitor fires, the Simulator sets the values of certain status
variables. You can use the values of these variables in monitor procedures,
but you can not SET them.

The variable names and the meaning of their values are described
below. The ACTIVE_NAME variable is available inside any monitor. The
monitor variable names that start with 'S' describe the piece of a composite
object that causes the monitor to fire. These variables are available only in
READ and WRITE monitors. The RET_VALUE monitor is available only in RETURN
monitors for functions.

ACTIVE_NAME
	Contains the name of the currently executing monitor.

SNAME
	Contains the absolute name of the object being monitored.

SACTIVE
	Contains a string that denotes the active piece of
	a composite object. The contents of this variable, appended to
	the contents of SNAME, yield a VHDL name that describes the piece
	of the object that has been accessed.

S0
	Contains the name of monitored object as specified to the
	MONITOR command.

S1 - S9
	Contain individual elements of SACTIVE.

SLICE
	Set to TRUE or FALSE, depending on whether or not SACTIVE
	represents a slice.

SNUM
	Contains the number of elements in SACTIVE. In other words, the
	number of S1 - S9 variables that are set.

RET_VALUE
	Contains the return value of a function call.

Here is an example in which a slice is active in an array:
	SNAME = /cpu/process/array, SACTIVE = (2).element(5 downto 3)
	S0 = array, S1 = 2,  s2 = element, s3 = 5, s4 = downto, s5 = 3
	SNUM = 5, SLICE = TRUE

See also:  VARIABLES, CONTROL_VARIABLES, STATUS_VARIABLES,
	POSITIONAL_PARAMETERS.
.hS NETLIST_DUMP "Dump a textual representation of the flat netlist"
Syntax:
	NETLIST_DUMP [component_instance]


NETLIST_DUMP displays a textual representation of the "flat" netlist
for a given component instance. If you do not specify an instance, it
assumes the top level entity.

You can use the NETLIST_DUMP command with the redirect operator, >,
to save this information in a file.
For example:

	NETLIST_DUMP > MYFILE

sends the netlist to MYFILE.

The format of the output is based on VHDL. It consists of a single
BLOCK statement containing a series of component instances, one for
each primitive instanced in the design. The label on each component
instance is the hierarchical name of the primitive component instance
NETLIST_DUMP is describing. The names it uses in the port maps are the
hierarchical names of the signals associated with the port.

For example, given the VHDL code:

	entity E is 
	end;

	architecture A of E is
		component  COMP 
			port (i: bit; o: bit);
		end component;

		for all:  COMP
			use entity WORK.E0(A0);

		signal s1, s2, s3, s4: bit;
	begin
		U0: COMP 
			port map(s1, s2);
		U1: COMP
			port map(s3, s4);
	end;

Would generate the following netlist:

	E: block
	  /E/U0: COMP port map (/E/S1, /E/S2);
	  /E/U1: COMP port map (/E/S3, /E/S4);
	end block;

Limitations and restrictions:

1. The Simulator assumes that no components have the same name.  
2. The Simulator assumes that the default configuration is always used.
3. NETLIST_DUMP does not show generic maps, signal type information,
   and local signals.
4. NETLIST_DUMP does not support "Complex" port maps. A complex port 
   map is one that uses vectors signals, formal sub-element association, 
   or type conversion functions.

See also: DESIGN_HIERARCHY, OUTPUT_REDIRECTION.
.hS NEXT "Execute next source line(s)"
Syntax:
	NEXT [n]

NEXT executes the next "n" lines of VHDL source code from the current
process. If you omit the argument "n", it executes a single line.

NEXT does not step into functions or procedures.

NEXT does not count or stop on lines that have an OFF monitor
monitoring them.

Notes:
a. Since NEXT counts only lines from the process that was current
when you called NEXT, if the process suspends (waits), the simulation
may continue executing for a long period of time. Executing a NEXT over a
wait statement (when the process does not execute any more lines) is
equivalent to a RUN.

b. NEXT is not supported in compiled code in the v3.1a release. 
If the design is mixed (interpreted and compiled), the command
stops at the next interpreted statement to be executed.

See also: STEP, RUN, MONITOR.
.hS OPEN "Open an output device"
Syntax:
        OPEN
    or  OPEN device_tag  [file_name]
    or  OPEN -s[y,x[,w,h]]  device_tag [window_title]
    or  OPEN -p[y,x[,w,h]] device_tag [window_title]

The OPEN command opens the indicated output device. On systems that support
windows, output devices include scrolling windows and YX-addressable
pads.

If you use OPEN with no arguments, the command lists all open devices.

To open an ordinary output file, omit the -s and -p flags. If you omit the
file_name, the Simulator creates a file with the name of device_tag.

You can create a simulation window by including the -s flag for a
scrolling window or the -p flag for a YX addressable pad. If you open
a simulation window, the position and dimensions [y,x,w,h[,vw,vh]] are
optional. (See SIMULATION_WINDOWS for more information)

When opening a simulation window, you can indicate an optional
window_title after the device_tag. OPEN displays window_title in the
simulation window title bar. If you do not use the argument, OPEN uses
device_tag.

See also:  CLOSE, SIMULATION_WINDOWS.

.hS OUTPUT_REDIRECTION "Redirect Simulator command output"
If you append the syntax

	> output_device[(y,x) | (field_name)]

to a simulation command line, the Simulator redirects any output of
the command to output_device. The redirection operator affects only
the current command and does not perform any wildcard expansion on the
output device name. You can use a file or an output window as the
device.

If output_device is open (see the OPEN command), the Simulator appends
the output. Otherwise, the Simulator opens a file with the indicated
name (destroying anything that was previously in the file), writes the
output from the command, and closes the file.

If output_device is a simulation window, the Simulator displays the
text in the simulation window. For scrolling windows, it displays the
output at the bottom of the window while scrolling up the existing
lines, if necessary. If output_device is a pad window, you can append
an optional (Y,X) or (field_name) parameters to the output_device tag.
If you use the (Y,X) paramenter, the Simulator displays the output at
the Y,X position in the pad. If you use the (field_name) parameter,
the Simulator places the output text at the (y,x) location for the
named field (see WFIELD).

See also:  SIMULATION_WINDOWS, MONITOR, OPEN, WFIELD.

.hS POSITIONAL_PARAMETERS "Accessing parameters to comms and include files"
You can pass any number of parameters to a command procedure or include file.
Inside the procedure or include file you reference the parameter values
positionally as $1, $2, and so forth. The variable substitutions that relate
to parameters are as follows:

$0	- The name of the executing comm or include file.
$1-$9	- The first nine parameters.
$*	- All the positional parameters passed (for example, $1 $2 $3 ...).
$@	- All the positional parameters passed (for example, ^$1^ ^$2^ ^$3^ ...).
$#	- The number of positional parameters passed.

You can refer to Positional Parameters beyond the ninth one by using the
SHIFT command to move subsequent parameters into the first nine positions.

See also:  COMM, SHIFT.
.hS PWD "Print the Current Working declarative Region"
Syntax:
	PWD

PWD prints out the current value of the status variable CWR.

See also:  STATUS_VARIABLES for CWR, CD, DESIGN_HIERARCHY.
.hS QUIT "Exit the VHDL Simulator"
Syntax:
	QUIT

QUIT causes the VHDL Simulator to exit immediately.

See also:  RESTART.
.hS QUOTATION "Control wildcard expansion and variable substitution"
You can use quotation marks, parentheses or up-arrows around Simulator command
arguments to pass quoted strings to the Simulator without wildcard expansion
and variable substitution.

Quotation marks suppress both wildcard expansion and substitution.
When '*', '?' or '$' appear between quotation marks, the command
interpreter passes the character to the VHDL analyzer without
interpretation.

Parentheses and up-arrows suppress wildcard expansion but allow
variable substitution. The '*' or '?' characters within parentheses do
not produce wildcard expansion, but a '$' before a variable name in
parentheses does produce variable substitution.

The Simulator strips the up-arrows from quoted words, but includes
the parentheses as part of the quoted word.

The Simulator preserves white space inside quotation marks, parentheses and
up-arrows.

Back ticks (left quotes) return the value of the enclosed VHDL expression.
The expansion of back ticks can yield wildcard characters or I/O redirection
characters. 

.hB
QUOTATION EXAMPLES

Suppose procedure A, function B, and variable C are in the current working
declarative region, and the current value of A is 7:

	echo * $A    displays  A B C 7
	echo "* $A"  displays  "* $A"
	echo (* $A)  displays  (* 7)
	echo ^* $A^  displays  * 7

A backslash character suppresses special interpretation of the next character:
	echo \\* \\$A  displays  * $A

A single quote restricts wildcard expansion to the types you specify:
	echo *'process'function  displays  A B

See also:  DESIGN_HIERARCHY, SELECTORS, WILDCARDS.
.hS REDIRECT "Redirect the output of monitors"
Syntax:
	REDIRECT output_device monitor_name {monitor_name}

The REDIRECT command redirects the output from the specified monitors
to the named device.

See also:  MONITOR, STOP, CONTINUE, DISABLE, ENABLE.
.hS RENAME "Rename monitors"
Syntax:
	RENAME monitor_name {monitor_name}  new_monitor_name

The RENAME command renames the specified monitor or monitors. The last
argument acts as the new stub name for the old listed monitors.

You can use wildcard expansion to specify an old monitor list. For example,
suppose your existing monitors are m, m1, and m2. The command

	RENAME m* xyz

renames your monitors to xyz, xyz1, and xyz2.

If any existing monitors already use the target stub name, RENAME continues
the naming sequence beyond the existing monitors to avoid conflicts.

See also:  MONITOR, EDIT, LIST.
.hS RESTART "Restart the Simulator"
Syntax:
	RESTART [file]

The RESTART command restarts the Simulator.

If you use RESTART without any arguments, the Simulator restarts based on the
following criteria:

    1. If a CHECKPOINT command was issued before the RESTART command, then
       the last checkpointed file is used to restart the simulator to restore
       the state of the Simulator to state when it was checkpointed.
	   
    2. If no CHECKPOINT command was issued before the RESTART command, then
       the Simulator executes all commands typed from invocation to either
       the RESTART command or the first RUN command (whichever happens first)
       after restarting the Simulator. It preserves all Simulator command line
       arguments. 
       Note that in this case, the simulator re-elaborates the
       entire design during the restart. Thus, there is minimal amount of time
       saved in using a RESTART command from the simulator prompt, compared 
       to quitting the current simulator session and re-invoking the simulator
       command from the system shell.

If you specify a file and it is a checkpoint file, then the Simulator is restored
to the state of the checkpoint file.

If you specify a file and it is not a checkpoint file, RESTART reads it as an
include file after it reads all other "original" include files and the RUNREAD
file. 

If you use RESTART without any arguments a second time, the Simulator executes
all the command lines from the previous restart plus all the command lines
typed from the current re-invocation through the first RUN/RESTART if no
CHECKPOINT command was issued before this RESTART command. 

Since the RESTART command causes the simulator to re-execute all the commands
previously read from an include file, you should not place a RESTART command
within a run-time command file (to be executed using either the INCLUDE
command or the command line option -i). In such a case, the simulator would
recursively execute the restart command, until it runs out of system 
resources (such as memory or file descriptors) and may exit abnormally.

See also:  INCLUDE, CHECKPOINT.
.hS RUN "Start/resume the VHDL simulation"
Syntax:
	RUN [maximum_time_period]

Use RUN to start or resume execution of your VHDL simulation.

A simulation runs until one of the following situations occurs:

	The maximum time period expires.
	A Simulator STOP monitor fires.
	A VHDL assertion violation occurs with appropriate severity level.
	You interrupt the simulation manually with a keyboard interrupt.
	A run time error occurs in the simulation.
	All simulation events complete normally.

After time period expiration, a STOP monitor, an assertion violation, or a
keyboard interrupt, you can execute RUN to resume the simulation from the
interrupt point.

See also:  CONTROL_VARIABLES for MON_ISTOP and ASSERT_STOP, ABORT, QUIT.

.hS SEARCH_STRING "Search the current VHDL source file for a string"
Syntax:
	/[string]
	?[string]

Use '/' or '?' to search forward or backward for the string, from the
current line to the end or beginning of the file. If you omit string,
SEARCH_STRING repeats the search using the previous search string. For
example:
	
	# /en
	1>	entity E is;	-- first "en" encountered
	# /
	5>	end E;		-- next occurrence of "en"

See also:  SLIST, CONTROL_VARIABLES for USE.
		
.hS SELECTORS "Specify a name category for wildcard expansion"
To specify a name category for wildcard expansion, attach one or more
selectors to a regular expression. For example, echo *'block'unblock
displays all block and unblock monitors. Do not leave any white space
within selector regular expressions.

Selectors are available for VHDL names, monitor names, Simulator command
names, Simulator shell variable names and filenames. Selectors for these
name categories are:

	'vhdl		'monitor 	'read		'comm
	'label		'time		'write		'shvar
	'type		'enter		'event		'file
	'subtype 	'begin		'active		'strobe
	'constant 	'middle		'block		'trace
	'variable 	'end		'unblock        'on
	'signal		'leave		'call		'off
	'function	'at		'elaborate	'coverage
	'procedure 	'after		'return
	'process 	'every		'tprocess
	'port
	'generic
	'alias
	'parm

See also:  WILDCARDS, MONITOR, COMM, CONTROL_VARIABLES for STRICT_TICK, INCLUDE.
.hS SET "Set a Simulator shell variable"
Syntax:
	SET {variable_name} {argument}

The SET command sets Simulator shell variables.

If you specify arguments, the Simulator sets the named variable to a value that
is a string composed of the arguments separated by spaces.

If you omit the argument, the Simulator sets the variable to
the null string.

If you do not specify any arguments, the Simulator displays the current
value of all Simulator shell variables.

See also:  LOCAL, UNSET, VARIABLES.
.hS SHELL_ESCAPE "Execute a sub-instance of a host command interpreter"
Syntax:
	! host specific command
	!!

On hosts that support sub-instances of command interpreters, this command
passes the remainder of the command line to one for execution. For example:

	! date
 
displays today's date on a UNIX system.

Using !! re-executes the previous shell escape command.
.hS SHIFT "Shift positional parameters"
Syntax:
	SHIFT [n]

SHIFT with no argument shifts current parameter values one position to
the left in the positional parameter list. $1 receives $2, $2
receives $3, and so forth. The original $1 value is lost.

If you specify an integer argument n, the values shift left 'n' times.

Use the SHIFT command in COMM procedures and include files to
access values beyond the ninth parameter position.

See also:  POSITIONAL_PARAMETERS.
.hS SHOW "Display the signals' and ports' connectivity"
Syntax:
	SHOW [-f] [-v] [-m] name [name...]
	
The meanings of the option flags are as follows:

	-f	Display the internal connected objects of the
		specified signal/port.

	-v	Display the current values of the connected
		signals/ports.

	-m	Display the mode of the objects connected to 
		the specified port/signal. For example, IN, INOUT, OUT,
		LINKAGE, and BUFFER. If the connected object is 
		signal then display the word SIGNAL.

SHOW displays the external (internal with the -f flag) connectivity of
a signal or port within the netlist.

(Note: For architectures residing on the external Simulator (hardware
       accelerator), the SHOW command is currently not supported)

If the named object is connected through a type-conversion, SHOW
also displays the type-conversion function name.

If you specify a resolved signal, SHOW also displays the resolution
function for each of the sources.

See also: NETLIST_DUMP, LS, DESIGN_HIERARCHY.

.hS SIMULATION_WINDOWS "Simulation Output Windows"
The Simulator provides X Window-based simulation windows for recording
and displaying simulation output. VSS supports the creation and
manipulation of two types of simulation windows:

	- Scrolling Simulation Window (Scroll)
	- YX-addressable Pad Window  (Pad)


Scrolling Simulation Output Windows 
Scrolls provide a means of recording and displaying textual simulation
output without requiring the user to provide any formatting
information. The window displays each line of text in the order
received. When the text window is full, existing lines scroll up and
the new line appears at the bottom of the window. You can redisplay
text that scrolls out of view by moving the scroll bar.

.hB 
Pad (YX-addressable) Simulation Windows 
The pad window displays simulation output in a user-defined format and
location.  Pad windows support formatted output through the use of
named text fields. A named text field is a pad-displayable text object
with the following attributes:

	- Text in the field
	- Foreground and background color of the field
	- Position (Y,X) of the field within the pad
	- Font for the text
	- Boolean indicating whether the field is to blink or not
	- Enabled/disabled attribute indicating whether the field is
	  visible or hidden

The WFIELD command enables you to create, manipulate and modify the
appearance of text fields in a pad window.

.hB
Opening And Closing Simulation Windows
Use the OPEN command with the "-p" or "-s" option to create a pad or
or a scrolling window. 

  open -s[Y,X[,W,H]] window_tag [window_title]
	Opens a scroll window whose id is "window_tag". The initial
	position (Y,X), size (W,H), and label "window_title" are
	optional parameters. The default label is the same as the
	window_tag. Position and size units are in text-size rows 
	and columns.

  open -p[Y,X[,W,H]] window_tag [window_title]
	Opens a pad simulation window whose id is window_tag. The
	initial position (Y,X), window size (W,H), pad size (VW,VH),
	and window_title are optional.
.hB
  close window_tag {window_tag}
	Closes one or more simulation windows.

.hB 
Redirecting Output To A Simulation Window 
To display text in a window, you can redirect the output of any
Simulator command to the window. You can redirect command output to a
pad window or scrolling window using the syntax

                        command > window_tag

window_tag identifies the window in which the Simulator displays
the text. If the simulation window is a pad, you can follow window_tag
with a position or field name

                      command > window_tag(Y,X)
                  command > window_tag(field_name)

If you specify a position (X,Y), the Simulator displays the command
output at the X,Y position in the pad window. If you specify a field
name, the Simulator replaces the text in the field_name text field
with the command output. If field_name does not exist, the Simulator
creates it.

.hB
Saving A Simulation Window
You can save the contents of a simulation window in a file by
selecting "Save" from the simulation window File menu. When you
select the "Save" menu item, a file dialog appears prompting you for
the filename. When you save a scrolling window, the Simulator writes
the window contents as an ASCII file. When you save a pad window, the
Simulator generates an includable simulator script that is composed
of the commands (for example, wfield and fprint) necessary to reproduce
the pad window.

.hB
Importing and Writing ASCII
For pad windows, there are two additional file menu items available:

	- Import ASCII
	- Write ASCII

When the Simulator writes a pad window as an ASCII file, most of the
formatting is lost (for example, font, foreground, and background).
Also, because each field can use a different font, the relative
distance between fields will be approximate.  

See also: WSIZE, WMOVE, WFIELD, ICON, UNICON.
.hS SLIST "List VHDL source code lines"
Syntax:
	SLIST [source_file] [start_line[,end_line]]

SLIST lists one or more lines from the VHDL source file you indicate.

If you omit the source_file, the Simulator uses the current value of
either the file specified on a previous SLIST (if you have not
executed the RUN command since then), or the FILE control variable. If
you specify source_file, SLIST uses it until you re-issue the RUN
command.

If you specify a start_line with no end_line, the Simulator displays one line.

If you omit both the start_line and the end_line, the Simulator uses the
line after the last line listed with SLIST (unless SLIST has not be used
since the last RUN, in which case it uses the contents of the status variable
LINENUM). The display range is the next ten lines.

For example:

	# slist counter.vhd 2,20
		-- lists lines 2 through 20 of counter.vhd
	# slist
		-- lists lines 21 through 30 of counter.vhd

See also:  MONITOR, CONTROL_VARIABLES for USE.
.hS SMARTMODEL "Issue a SmartModel Command Channel command"
Syntax:
	SMARTMODEL INSTANCE {smartmodel_instance_name} {"command"}
     or SMARTMODEL SESSION  {"command"}

SMARTMODEL passes the specified command to the SmartModel instance
indicated, or to the SmartModel session.  The command string may be a
list of commands separated by semi-colons.
.hS STATUS "Print the status of the simulation"
Syntax:
	STATUS [-t] {process_name | signal_name}

STATUS prints the ready-to-run queue and a list of the processes
waiting for events on signals. If you specify a process or signal
name, STATUS prints information pertaining only to that signal or process.

STATUS accepts the following options:

-t	Include transactions on drivers in the ready-to-run queue listing.
	STATUS does not display transactions if you omit this flag.

The output of STATUS is as follows:
	Transaction   5  /E/P1, /E/S1 = '0' ('1' at 10, 'Z' at 15)

.hS STATUS_VARIABLES "Simulator variables that contain simulation state"
The Simulator sets status variables as the simulation progresses.
You can check these variables at any time to establish the current state
of the simulation, but you cannot change the values of these variables.

Here is a list of Simulator status variables along with the meaning
of their values:


CRP
        Contains the absolute name of the current running
        process. The Simulator clears it if no process is currently
	running. It sets this variable only when a VHDL process has resumed,
        but has not yet encountered a wait statement.

CMD_FAILED
        Is set to TRUE if the preceeding command failed. Otherwise it is
	FALSE.

CWR
        Contains the absolute name of the current working
        declarative region. The value changes when you
        CD to a different declarative region.

FILE
        Contains the name of the current source code file of
        your VHDL model. As the simulation runs, the Simulator updates the
        value of this variable.

LAST_NAME
        Contains the name of the most recently recently
        created monitor or trace.

LINE
        Contains the text of the current VHDL source line.

LINENUM
        Contains the line number of the current VHDL source line.

NOW
        Contains the current simulation time as a decimal
        number without any units (See TIMEBASE, below).


TIMEBASE
        Contains the base unit of time for the simulation.
        The base unit is the argument to the -t program invocation flag,
        if present; the value of the .synopsys_vss.setup TIMEBASE variable, if
        specified; FS (femtoseconds) is the default value.

See also:  CONTROL_VARIABLES, MONITOR_VARIABLES, POSITIONAL_PARAMETERS,
        .SYNOPSYS_VSS.SETUP VARIABLES.

.hS STEP "Execute next source line(s)"
Syntax:
	STEP [n]

STEP executes the next "n" lines of VHDL source code. If you omit the argument
"n", it executes a single line.

STEP enters functions and procedures.

STEP does not count or stop on lines that are monitored by an OFF
monitor.

Note: STEP is not supported in compiled code in the v3.1a release. 
      If the design is mixed (interpreted and compiled), the command
      will stop at the next interpreted statement to be executed.

See also: NEXT, RUN, MONITOR.

.hS STOP "Change a set of monitors to STOP monitors"
Syntax:
	STOP {name}

STOP changes a set of monitors to STOP monitors. When one of the
monitors fires, the simulation stops.

See also:  ABORT, MONITOR, CONTINUE, ENABLE, DISABLE, REDIRECT.
.hS SYNTAX "Conventions of the Simulator Control Language description"
Help messages use the following conventions to describe the parameter 
syntax of vhdlsim Simulator Control Language commands:

	A | B	A vertical bar means either A or B. Either A or B must appear.
	[C]	Square brackets means that C is optional. C may appear zero
		times or exactly once.
	{D}	Curly braces means that D is repeatable. D may appear zero
		or more times.

See also:  DESIGN_HIERARCHY, CONTROL_VARIABLES, WILDCARDS.
.hS .SYNOPSYS_VSS.SETUP "VHDL User Variable/Setup File"
Before the simulation starts, the Simulator reads several VSS setup
files (.synopsys_vss.setup). The entries allowed in these files are described below.

A VSS setup file is organized as a set of lines. Each line has the following
format:
        TAG = VALUE
    or  TAG : VALUE
    or  TAG > VALUE

The mapping characters (=, :, and >) have the following meaning:

=       Associates VALUE with the corresponding TAG. This character
        is the standard mechanism for communicating with the Simulator.

:       Maps the host directory VALUE to the Simulator
        design library named TAG.

>       Binds the library logical name TAG to the 
        Simulator design library named VALUE.

The Simulator searches for setup files .synopsys_vss.setup in the following
        order:

        1)  The directory $SYNOPSYS/admin/setup.
        2)  The directory named by the environment variable HOME. This is
                normally your LOGIN directory.
        3)  The current (or DEFAULT) directory.

If it finds a file in one location, it continues to search subsequent
locations. If one VSS setup file sets a TAG, a subsequent setup
file overwrites it.

These rules permit a hierarchy of customization. Keep information specific
to a particular simulation (TIMEBASE or RUNREAD, for example) in the
.synopsys_vss.setup file in the directory where you are running the simulation.
Keep in your home directory VSS setup file information specific to you
but common to all of your simulations (for example, the 
Simulator design library to which WORK is bound). Finally, keep
information common to the entire Synopsys VSS Family Simulator
installation (for example, the location of Simulator on-line help), in
a .synopsys_vss.setup file in $SYNOPSYS/admin/setup.

The Simulator uses the : and > lines in the setup files to determine where
it finds the design unit you specify for simulation.

.bp
Following are the other TAGS (followed by example values) used by the
Simulator:

ASSERT_IGNORE  (Example: ERROR)
	Legal values: NOTE, WARNING, ERROR, FAILURE, NOIGNORE.  Default is 
	NOIGNORE.  The first four values suppress the assertion message when 
	there are VHDL assertion violations of that severity or lower. If the 
	value of ASSERT_IGNORE is NOIGNORE, the simulation never suppresses 
	for assertion violations.  When an assertion is suppressed, the 
	behavior is as though that assertion never existed in the design; the 
	simulator will never stop at a suppressed assertion due to an 
        assertion violation.

ASSERT_STOP  (Example: NOSTOP)
	Legal values: NOTE, WARNING, ERROR, FAILURE, NOSTOP.  Default 
	is ERROR.  The first four values stop the simulation when 
	there are VHDL assertion violations of that severity or 
	greater. If the value of ASSERT_STOP is NOSTOP, the simulation 
	never stops for assertion violations. The Simulator always 
	reports all assertion violations regardless of level, but the 
	simulation stops only at the level you specify with 
	ASSERT_STOP.  See also, ASSERT_IGNORE, CS_ASSERT_STOP_NEXT_WAIT.

ALLOCATOR  (Example: $SYNOPSYS/$SIM_ARCH/sim/bin/cater)
        Full host path name for the Software Tools program Allocator.
        Used by the mas utility.

BROWSER_NUMLISTS  (Example: 3)
        Provides the number of lists the browser shows.
        The minimum value is 2 and the default value is 3.

COMPONENT_BINDING  (Example: SOFT)
	Defines HARD or SOFT binding of components to
	entity-architecture pairs.

	If you use HARD binding, then each level of the design is
	dependent on the level below it. A lower-level architecture
	must exist in the design library before you can analyze the
	parent architecture. Also, re-compiling the lower level
	architecture requires re-compilation of the architecture that
	instances it.

	Soft binding relaxes these dependencies. If you use SOFT
	binding, you can analyze the architecture declarations of a
	design hierarchy in any order and you must do only the minimum
	number of re-analysis steps.

CS_ASSERT_STOP_NEXT_WAIT  (Example: TRUE)
	When running in compiled-code, an ASSERT_STOP will cause the 
	simulator to stop as expected.  However, the user will not be 
	allowed to continue simulating after the ASSERT_STOP.  This is 
	the default behavior. 

	The user can override this behavior by setting this variable 
	TRUE.  This will cause the simulator to run until the next 
	wait statement before stopping the simulation.  Further, the 
	user will be allowed to continue simulating after the 
	ASSERT_STOP.  So, the state of the simulation when the 
	simulation actually stops is not identical to the state of the 
	simulation at the ASSERT_STOP. 

CS_CCPATH  (Example: /usr/bin/cc)
	Specifies the compiler the Analyzer uses for compiling from 
	VHDL to C-code. The default value is /bin/cc.  

	WARNING!	Use only the compiler that is shipped with 
	your operating system. Also, the compiler and operating system 
	must support dynamic linking. The platforms with operating 
	systems that support dynamic linking are IBM, HP, SPARC and 
	Solaris. 

CS_CCFLAGS
	Specifies flags the Analyzer passes to the C compiler. The 
	default value depends on your platform. If you change the 
	flags, you must always use the -PIC (position independent 
	code) flag because the compiled code is dynamically linked to 
	the Simulator. 

	One reason to use the CS_CCFLAGS variable is to turn off the 
	-O (capital O) compiler option. Some compilers have trouble 
	compiling large files when the -O compiler option is on.  For 
	example, to turn off the -O option on a SPARC platform, use 
	the Analyzer option: 
		CS_CCFLAGS = -c -PIC

CS_COMPILED  (Example: TRUE)
	If set to TRUE, (default is FALSE) the Analyzer generates 
	compiled (.o) and interpreted (.sim) simulation files. You can 
	then have the Analyzer (vhdlan) generate only interpreted 
	simulation files for individual VHDL files by using the 
	Analyzer -i option.

	If set to FALSE, (the default value) the Analyzer only 
	generates interpreted simulation (.sim) files. You can then 
	have the Analyzer (vhdlan) generate compiled simulation files 
	for individual VHDL files by using the Analyzer -c option

CS_NOCHECK  (Example: TRUE)
	If set to TRUE (the default), the Analyzer optimizes the 
	compiled code by eliminating VHDL checks for 
	*	Arithmetic overflow.
	*	Constraint checks.
	*	Array bounds compatibility at assignment.
	*	Subscripts out of bounds.
	*	Negative exponents to integer.

	WARNING!	Set the CS_NOCHECK variable to FALSE until you 
	have completely debugged your design and are performing final 
	design simulation. If a VHDL error occurs when CS_NOCHECK is 
	TRUE, you can get erroneous results or cause the Simulator to 
	fail in an unpredictable way. 

	To have the Analyzer (vhdlan) produce optimized compiled code 
	for individual files, use the Analyzer -nocheck option. 

CS_DEBUG
	If set to TRUE, (default value is FALSE) the Analyzer 
	generates extra code that lets you set write monitors on 
	process variables. Only use CS_DEBUG when you need to use 
	write monitors because the extra code slows down the 
	Simulator. 

	To have the Analyzer (vhdlan) generate debug code for 
	individual files that lets you set write monitors, use the 
	Analyzer -debug option.

DBX_ANALYZER_CMD  (Example: vhdlan)
	Alternative command for the Debugger Misc.  Analyze menu 
	selection. 

DUT  (Example: top/my_asic top/my_asic2)
	Design under test on the gate-level simulation engine for 
	quiescence violation checking. If you set the DUT variable and 
	enter the dut_quiet command during simulation, the Simulator 
	prints a quiesence violation message if there is any activity 
	in the design under test.  You can specify multiple design 
	regions.

EDITCMD  (Example: sterm -T Synopsys-Editor -e vi)
        Indicates the shell command necessary to
        invoke your preferred text editor. The default editor is vi.
        However, since vi does not automatically create a toplevel
        window, it must be executed as a child of a sterm. It is not
        necessary to parent an editor such as emacs that does open a
        top-level window.

GPPHELP  (Example: SYNOPSYS/doc/sim/help/gpp.hlp)
        Full host path name for the help files for the General Purpose
        Post-Processor.

GPPREAD  (Example gppcom.inc)
        If defined, contains the name of a file read when GPP starts. This
        file contains GPP commands.

GS_REPORT_BUS_CONTENTION  (Example: TRUE)
	If TRUE when using gate-level simulation, the Simulator 
	reports the nodes in the design that have multiple drivers 
	producing a value of 'X' (unknown). Default is FALSE. 

GS_REPORT_BUS_FIGHT  (Example: TRUE)
	If TRUE when using gate-level simulation, Simulator reports 
	the nodes in the design that meet the conditions for bus 
	fight.  Default is FALSE.

GS_REPORT_BUS_FLOAT  (Example: TRUE)
	If TRUE when using gate-level simulation, Simulator reports 
	the nodes in the design that have multiple drivers all driving 
	a value of Z. Default is FALSE.

GVAN_EDITSTR  (Example: +%L %F)
        Defines the command line arguments for
        the text editor. The VHDL Analyzer Error Browser uses this
        string to position the text editor on the file and line in error.
        This string can contain two format variable: %F and %L. The Browser
        replaces %F with the name of the file containing the error and replaces
        %L with the line number the error appears on.

GVAN_STOP_ON_WARNS  (Example: TRUE)
	When FALSE (the default) the Graphical Analyzer stops and 
	displays an error browser window if it encounters errors in 
	the file it is analyzing. If TRUE, the Graphical Analyzer 
	stops and displays an error browser window for errors and 
	warnings in the file it is analyzing.

HELPDIR  (Example: /usr/local/vhdl/help)
        Defines the host directory where interactive help files are kept.

IEEE  (Example: SYNOPSYS/$ARCH/packages/IEEE/lib)
        Full pathname to the IEEE package.

INTERPRETER  (Example: $SYNOPSYS/$ARCH/sim/bin/inter)
        Full host pathname for the Software Tools program interpreter.
        Used by the mas utility.

LEVEL  (Example: expert)
        The experience level of the user. Possible
        values are novice, intermediate, and expert with the default as novice.
        GPP uses this specification to determine the text of error messages
        and the feedback from interactive commands. The more inexperienced
        the user, the more descriptive the feedback.

MAX_HIERARCHY_DEPTH  (Example: 20)
	Controls the maximum hierarchical depth allowed during 
	elaboration. If the hierarchical depth exceeds the value of 
	MAX_HIERARCHY_DEPTH, the Simulator issues an error message and 
	terminates elaboration.  The default value is 5000. You can 
	set it to any value you wish to alert you when the depth of 
	your design exceeds a certain value.

MERGE  (Example: $SYNOPSYS/$ARCH/sim/bin/merge)
        Full host pathname for the Software Tools program Interpreter.
        Used by the mas utility.

METAMICRO  (Example: $SYNOPSYS/$ARCH/sim/bin/micro)
        Full host pathname for the Software Tools program metaMicro. Used
        by the mas utility.

MVL_7  (Example: $SYNOPSYS/$ARCH/packages/mvl_7/lib)
        Full pathname to the IEEE package.

NO_CONSTRAINT_MESG  (Example: TRUE)
	If true, turns off constraint violation messages in optimized 
	gate-level simulation if your FTGS library prints constraint 
	violation messages.

NO_CONSTRAINT_XGEN  (Example: TRUE)
	If true, turns off x-generation for constraint violations in 
	optimized gate-level simulation if your FTGS library has 
	x-generation.

NO_HAZARD_MESG  (Example: TRUE)
	If true, turns off hazard messages in optimized gate-level 
	simulation if your FTGS library prints hazard messages. 

NO_HAZARD_XGEN  (Example: TRUE)
	If true, turns off x-generation for hazards in optimized 
	gate-level simulation if your FTGS library has x-generation. 

OPEN_WFILE_APPEND_MODE  (Example: OPEN_WFILE_APPEND_MODE = true)
	If true, opens files in append mode (new text is appended to the end
	of the existing file).

PROMPT_STD_INPUT  (Example: PROMPT_STD_INPUT = true)
	Defines the source of the input when the Simulator executes a
	READLINE(STD_INPUT) in the standard TEXTIO package. When set to TRUE,
	the Simulator reads from the keyboard. When set to FALSE, it
	reads from the default file "STD_INPUT".

RESFUNC_OPT  (Example: STD_OPT)
        Specifies the level of optimization performed on resolution
	functions. Possible values are NO_OPT, STD_OPT and FULL_OPT
	with FULL_OPT as the default. The NO_OPT setting does not
	perform any optimization. Use this setting when debugging a
	resolution function. The STD_OPT setting optimizes only those
	resolution functions defined in the standard packages.
	FULL_OPT optimizes all resolution functions including those that are
	user-defined. Using this value requires that all user-defined
	resolution functions have both commutative and associative
	attributes. If you observe incorrect behavior, it may be the
	result of a non-commutation/associative function that
	requires disabling full optimization.

RUNREAD  (Example: am29k.run)
        Specifies the name of a Simulator include file that the Simulator
        runs at startup.

SAVE_WVMSGS  (Example: true)
        Saves all messages communicated to the waveform tool in order to
        restore state for a checkpoint-restart.

SDFNAMINGFILE  (Example: my_path/sdf_naming.sdf.S)
        Full path name for default naming scheme of SDF parameters.

SDFWILDCARD  (Example: true)
        If true, enables wildcard capability for backannotation. The default
	is false.

SETUPEXIT  (Example: xxx)
        If set, immediately terminates all setup file
        processing. For example, the Simulator will not read the rest of the
        file after SETUPEXIT is set, and it does not search for or read
        from any further setup files. Synopsys normally uses this option
        for debugging.

SIMFILE_ENCRYPTION  (Example: CUSTOM)
	When turned on, the analyzer and simulator generate and use 
	encrypted simulation (.sim) files, so that information in the 
        VHDL source is shielded.  Possible values are NONE 
	(for no encryption) and CUSTOM. 

SPC  (Example: SPC = true)
	If true, Synthesis Policy Checking is always invoked when you run the
	Analyzer. Setting this variable has the effect of using the -spc flag
	with the vhdlan command. Default is false.

SPC_ELAB  (Example: SPC_ELAB = true)
	If true, Synthesis Policy Checking is always invoked when you run the 
	Analyzer. Setting this variable has the effect of using the -spc_elab
	flag with the vhdlan command. Default is false.

SYNOPSYS  (Example: $SYNOPSYS/$SIM_ARCH/packages/synopsys/lib)
        Full path name to Synopsys Standard Packages.

TIMEBASE  (Example: ns)
        Specifies the base time unit for the simulation. The Simulator uses
        the value if you omit the -t option to the Simulator.

TIME_RES_FACTOR  (Example: 0.01)
        Number of simulation ticks per base time unit. The Simulator uses
	this value if you do not use the -tres option on the Simulator
	command line.  Default is 1.

USE  (Example: /u/joe/vhdl/u/fred/vhdl/src)
        A white-space-separated list of host directories.
        The Simulator initializes its shell variable of the same name with
        this tag value at startup. It uses this Simulator shell variable
        when searching for VHDL source files.

USE_LONGTIME  (Example: true)
        Increases the maximum absolute simulation time to 62 bits, or
	2 raised to the 62nd power. The default is 32 bits. Maximum
	duration of individual run commands and arguments to monitor
	commands remains 32 bits. USE_LONGTIME invalidates predefined
	attributes of type time (for example, time'high,
	time'right, s'last_event, s'last_active). Also, you cannot
	call the pre-defined function standard.now.

USER_MENU  (Example: USER_MENU = "Pad Window": open -p pad)
	Defines the menu items in the VHDL Debugger User menu and the
	commands each menu item executes when you select it. For more
	information, see the vhdldbx man page.

VLOG_C_COMPILER_PATH    (Example:  /usr/lang/acc)
	Full pathname for the C compiler to compile and link 
	the new Verilog simulator with the interface to VSS. 
	Use only a UNIX C compiler (cc) or an ANSI C compiler (acc).

VLOG_C_COMPILE_FLAGS    (Example:  -c -Dsun4Arch;  default:  -c)
	Flags for the C compiler to compile the new Verilog simulator.

VLOG_C_LINK_FLAGS    (Example:  -Bstatic; default:  -Bstatic)
	Flags for the linker to link the new Verilog simulator.

VLOG_TARGET_DIR    (Example:  ~/vlg_for_vss.  default:  ./)
	The directory for the new built Verilog simulator.

VLOG_ACC_LIB_DIR    (Example:  /remote/verilog/acc1.6a.4/)
	Directory that contains the Verilog-PLI access function 
	archive library.

VLOG_LIB_DIR    (Example:  /remote/verilog/vlog1.6a.4)
	Directory that contains the Verilog-PLI access function 
	archive library	

VLOG_ACC_LIB_NAMES    (Example:  acc.o)
	Names of the Verilog-PLI access function libraries List 
	the libraries with a space between each one. 

VLOG_LIB_NAMES    (Example:  vlog.o omnitasks.o)
	Names of the Verilog-PLI utility function libraries. List the 
	libraries with a space between each one. 

VLOG_ACC_LIB_VERSION    (Example:  1.6a;  default:  1.6a)
	The version number of the Verilog-PLI access function libraries.

VLOG_USER_LIB_DIR    (Example:  ~/my_lib_for_vlg)
	Directory that contains your Verilog-PLI task/function libraries.

VLOG_USER_LIB_NAMES    (Example:  my_lib1.o my_lib2.o)
	Names of your Verilog-PLI task/function object libraries. List 
	the libraries with a space between each one and in the order you 
	want them linked into the Verilog simulator. 

VLOG_OTHER_LIB_PATHS    (Example:  /remote/verilog/vlog1.6a.4/libvoids.a)
	Full pathnames for additional libraries to be linked into 
	the new Verilog simulator. List the pathnames with a space 
	between each one. 

VLOG_SIM_SHELLPATH    (Example:  ./ ;  default: (vlgsh in VSS image))
	Path the Simulator uses to run the Verilog interface executable 
	vlgsh.

VLOG_SIM_HOSTNAME    (Example:  homer;  default: (the host running VSS))
	Name of the machine where the Verilog simulator is to be executed.

VLOG_COMMAND_OPTIONS    (Example:  -q -u +liborder)
	Verilog simulator options. List the options with a space between 
	each one. 

VLOG_COMMAND_FILE    (Example:  vss_vlg.vc)
	Name of the command file containing Verilog simulator options.

VLOG_OPEN_SIM_WINDOW    (Example:  false;  default:  true)
	Option for Opening a Verilog command window.
	Value can be set to false, true, or a command string.
	In the case of the value being a command string, the interface
	opens Verilog command window by using the value of 
	the variable as the window command.

VLOG_SIM_WINDOW_PAUSE    (Example:  false;  default:  true)
	Pauses the Verilog command window before closing, so you can 
	read messages in the window.

VLOG_SIM_WINDOW_HOST    (Example: king; default: (host name in $DISPLAY))
	Host for the Verilog command window (not the Verilog simulator).
	If not specified, the interface will try to obtain the host
	name from the UNIX environment variable DISPLAY.

VSS_PRODUCT		(Example: PRO; default: EXPERT)	
	Specifies the VSS product to be used. Command line switches
	-pro or -expert, if present, override this setting.

WAVEFORM  (Example: wif)
	Specifies the format the Simulator uses to save trace data.
	Possible values include wif, waves, and wif+waves. If the
	value of this tag is wif, the Simulator creates a trace file
	in wif format. After quitting the simulation, you can display
	the trace with the Waveform Viewer operating as a stand-alone
	tool. If WAVEFORM is set to waves, the Simulator automatically
	starts the Waveform Viewer and displays signal values as the
	simulation progresses. The wif+waves setting causes the
	Simulator to both store and immediately display the trace
	data.

WIF2TAB_HDRLEN  (Example: 40)
	The maximum number of characters wif2tab uses to print the 
	name of a trace. You can use any integer from 0 to 255. The 
	default value is 20.

WINDOW  (Example: /usr/local/vhdl/bin/sv_window)
        The name of Simulator output window daemon program.  Has
	meaning only on hosts that support multiple graphics windows.

XP_AUXPATH  (Example: $SYNOPSYS/$SIM_ARCH/xp/aux)
	Pathname of custom technology files for Zycad XP accelerator. 
	See the VSS Expert Interfaces Manual.

XP_CBMODS  (Example: /home/users/jklios/xp/cbmod/edif/bmod.edif2)
	Full pathname of the bmod.edif2 file for simulating CBMODs 
	with the Zycad XP interface. See the VSS Expert Interfaces 
	Manual.

XP_DELAY_CELL_NAME  (Example: DELAY)
	Name of the delay cell in an EDIF library simulating with the 
	Zycad XP interface. See the VSS Expert Interfaces Manual. 

XP_DELAY_LIB_NAME  (Example: MY_LIB)
	Name of the EDIF library for simulation with the Zycad XP 
	interface. See the VSS Expert Interfaces Manual.

XP_LOAD_FILES  (Example: ./file.dly.mm)
	Full pathname of the delay timing files for back-annotation in 
	the Zycad XP interface. See the VSS Expert Interfaces Manual. 

XP_MAP_FILE  (Example: /usr/chris/mapfile_mvl7.chris)
	Full pathname of a custom value-translation table file for the 
	Zycad XP interface. See the VSS Expert Interfaces Manual. 

XP_SCRIPT_PATH  (Example: $SYNOPSYS/$SIM_ARCH/xp/bin)
	Pathname of the simbuddy script files that compile simulation 
	EDIF files for the Zycad XP accelerator. See the VSS Expert 
	Interfaces Manual.

XP_GEN_TIMING_ERR  (Example: TRUE)
	Value of TRUE turns on timing error checking on the Zycad XP 
	accelerator when you use the XP interface. See the VSS Expert 
	Interfaces Manual.

XP_TIMING_ERRFILE  (Example: err.log)
	Filename for timing error messages from the Zycad XP 
	accelerator when you use the XP interface. See the VSS Expert 
	Interfaces Manual.

See also:  STATUS_VARIABLES for TIMEBASE, CONTROL_VARIABLES for USE, VHDLSIM.

.hS TBM "TestBench Manager specific commands"
The following set of simulator commands can be used while simulating testbenches
generated by the TestBench Manager product. Type "help <command>" for more
information on any of the TBM specific commands.
tbm_connect	tbm_force	tbm_mask	tbm_strictX
tbm_signal	tbm_strictHL	tbm_trace	tbm_unforce
tbm_unmask

.hS TBM_CONNECT "Displays the value of the specified ports and signals, when an error occurs on the trigger port"
Syntax:
	TBM_CONNECT <trigger_port_name> [<port_name>...| <signal_name>...]	

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_CONNECT creates a breakpoint for any error that occurs on the
first port and displays the value of this port and all other specified
ports and signals.
Specify signal_name as a complete hierarchical path.
.hS TBM_FORCE "Forces a value on a port"
Syntax:
	TBM_FORCE [<port_name>] [<forced_value>]

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_FORCE forces a value on the specified port. The forced value
overwrites the driving value of the port in the stimulus file.
<forced_value> must be a value of VHDL type bit or bit_vector 
containing `0' or `1'.
When you use TBM_FORCE without any argument, the
forced values on all ports are displayed.
Limitations:This command only works on the input ports of the 
following VHDL types:
bit, bit_vector, boolean, boolean_vector, std_ulogic, std_ulogic_vector, 
std_logic, std_logic_vector, unsigned and signed.
Examples:
-- assigning to std_logic
# tbm_force std_logic_p 1
-- assigning to a vector
# tbm_force std_logic_vec 1011
-- Display current forced value on all input ports
# tbm_force
See also: TBM_UNFORCE
.hS TBM_MASK "Changes the mask value on a specified port"
Syntax:
	TBM_MASK [<port_name>] [<mask_value>]

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_MASK disables the output comparison by changing the mask value on
the specified port. The expected output value in the capture data is
over-written by the new masked value.  mask_value must be a valid
value for the type of the corresponding port you specify.  When you
specify TBM_MASK without any argument, the masked value on all ports
are displayed.
See also: TBM_UNMASK
.hS TBM_SEVERITY "Sets the severity level of error messages (mismatches and assertions) on the specified ports"
Syntax:
	TBM_SEVERITY [-none] [-note] [-warning] [-error] [-failure] [<port_name>]...

-none	Turns off the error messages. 
-note	Sets severity level to note.
-warning	Sets severity level to warning.
-error	Sets severity level to error.
-failure	Sets severity level to failure.

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_SEVERITY changes the severity level of mismatches assertion for
specified ports or all ports.  To change the severity level on all
ports, use the option you want without specifying any port names on
the command line.
.hS TBM_SIGNAL "Shows settings and values of a port"
Syntax:
	TBM_SIGNAL [-v] [-i] [-o] [-b] [<port_name>] 

-v 	Shows signal information in verbose mode. 
-i 	Shows signal information on all input ports.
-o 	Shows signal information on all output ports.
-b 	Shows signal information on all bidirectional ports.

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_SIGNAL displays the setting and value of a port.
To display signal information on all ports, use tbm_signal without any
arguments (except -v if you want the verbose mode.)
Example: 
TBM_SIGNAL -v data_bus 

	Signal Information for DATA_BUS
Current Value: X"5A" Changed at: 10 NS
Current Error: FALSE        Severity: ERROR
Accumulated Errors: 2 
Force: "........" 
                      Mask: "........" 
                 Port Type: INOUTP 
            Check Strategy: PERIODIC
                    Strobe: STD1
               Drive Delay: 0 NS 
               Check Delay: 0 NS 
                  Match Xs: FALSE 
              Match Strict: TRUE 
            Report Enabled: TRUE 
                    Traced: FALSE 
.hS TBM_STRICTHL "Controls the strength checking for comparing the output value on the specified ports"
Syntax:
	TBM_strictHL [-e] [-d] [-v] [<port_name>]... 
-e	Enables the strength checking (default).
-d	Disables the strength checking.
-v	Show current settings for strict strength checking on specified ports.

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_strictHL enables or disables the strict strength checking on the 
specified ports. 
When enabled, the check simulation compares the actual output strength value 
with the expected output value. 
When disabled, the check simulation converts the actual output strength 
values to logic values, before performing the comparison. Thus, actual output 
strength values of `H', `L' and `W' are converted to the logical values of `1',
`0' and `X' respectively. For example, using "tbm_strictHL -d" does not report
a mismatch between `H' on the actual output and `1' on the expected output.
To enable or disable strict strength checking on all ports, use the -e or -d 
option, without specifying any port names.
Limitations:This command only works on the output ports of the 
following VHDL types:
std_ulogic, std_ulogic_vector, std_logic, std_logic_vector, unsigned, signed.
Examples:
-- Enable strict strength checking for ports p1 and p2
# tbm_strictHL -e -v p1 p2 
-- Verbosely display strength checking status for all ports
# tbm_strictHL -v
-- Disable strict strength checking for all ports
# tbm_strictHL -d
.hS TBM_STRICTX "Controls the output comparison on the specified ports when the expect output from the capture process is 'X'"
Syntax:
	TBM_STRICTX [-e] [-d] [-v] [<port_name>]...

-e	Enables strict matching with 'X'. (default)
-d	Disables strict matching with 'X'.
-v	Show current settings for strict matching on specified ports. 

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_STRICTX changes the output comparison mechanism on the ports only
when the expected output value of the ports are 'X'.
When enabled, the actual output value should be one of '0', '1' or 'X' for the
comparison to succeed. A mismatch error is generated for all other strengths 
of the actual output values of the ports. Disabling strict matching with 'X'
results in the expected output value matching ALL strength values of the
actual output.
You can add multiple port names on the command line. To disable or
enable the X-matching output comparison on all ports, use the -e or -d
option without any port name.
Limitations:This command only works on the output ports of the 
following VHDL types:
std_ulogic, std_ulogic_vector, std_logic, std_logic_vector, unsigned, signed.
Examples:
-- Enable strict X matching for ports p1 and p2
# tbm_strictX -e -v p1 p2 
-- Verbosely display X matching information for all ports
# tbm_strictX -v
-- Disable strict X matching for all ports
# tbm_strictX -d
.hS TBM_TRACE "Traces the specified port and shows the actual port value, expected port value, driving value (if it is an input or bi-directional port),check signal, and the error flag"
Syntax:
	TBM_TRACE [-a] [-i] [-o] [-b][<port_name>]...

-a 	Traces all ports.
-i 	Traces all input ports.
-o 	Traces all output ports.
-b 	Traces all bidirectional ports.


NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_TRACE shows the actual port value, expected port value, driving
value (if it is an input or bi-directional port), check signal, and
the error flag in the waveform display tool.
.hS TBM_UNFORCE "Resets the forced values for the specified ports"
Syntax: 
	TBM_UNFORCE [<port_name>]... 

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_UNFORCE resets the forced value for the specified ports, that is,
the drive value from the captured stimulus file is resumed. To clear
forced values on all ports, use TBM_UNFORCE without specifying any
port names.
See also: TBM_FORCE
.hS TBM_UNMASK "Removes masking value of a port and resumes the output comparison on the specified ports"

Syntax:
	TBM_UNMASK [<port_name>] 

NOTE: This command is available only while simulating Test Benches generated by
      the TestBench Manager tool.
TBM_UNMASK clears the forced mask value and resumes the output
comparison on the port. The expected value in the capture data becomes
valid. To resume the output comparison on all ports, use TBM_UNMASK
without specifying any port names.

See also: TBM_MASK
.hS TRACE "Produce a file containing a trace of simulation events"
Syntax:
        TRACE [-b -e | -d] [-n name_stub] [-wif] [-waves] 
              [-o trace_file] [-all [declarative_region]]
	      [-strobe start,delta[,stop]]  {name}


The meanings of the options are as follows:

	-b		Create a bidirectional trace -- a trace for the
			value on the inside of a component port.  By
			default, the trace name is portname__o.
	
        -e or -d\ \ \   Enable or disable trace when it is created.

        -n              Name the monitor using name_stub.

        -o              Use the trace file "trace_file" instead of the
                        default trace file. This option implies
			the -wif option.

	-wif		Write the trace data to a WIF file. 

	-waves		Display the trace data in the Waveform Viewer. This
			can be combined with the -wif option (or -o option),
			such that data can be sent to both a Waveform
			Viewer window and a WIF file.
			
        -strobe start,delta[,stop]
                        Fire the trace at the time start then every
                        delta time units thereafter until time stop.
                        If you do not specify stop, the trace
                        continues to fire until simulated time overflows.

                        Use the CYCLE_POINT variable to specify the cycle point
                        at which the strobing takes place. The default value of
                        CYCLE_POINT is LEAVE (the end of the time cycle).

        -all [declarative_region]
                        If you omit the declarative_region, the Simulator
                        traces all the simulation events in the design.
                        Otherwise, the Simulator traces only the events from
                        the declarative_region and all regions visible to
                        the declarative region.

The VHDL Simulator provides a mechanism for logging Simulator events
in a data file. You can then analyze the data using post-processor
tools.

The format of the data file is determined from the command line options 
-wif, -waves and -o. The -wif and -o options result in the generation of
a WIF file. The -waves option results in the trace data being sent to 
the waveform viewer. The -wif (and/or -o) and -waves options can be
combined to both view and store the data on a disk file for later use.
If none of the three options -wif,-o, and -waves, is specified, 
the format of the data file is determined from the WAVEFORM entry in
the .synopsys_vss.setup file. If it is set to WIF, the Simulator
generates only a WIF file. If it is set to WAVES, the Simulator opens the
Waveform Viewer to display the simulation values as the simulation
progresses. If WAVEFORM is set to WIF+WAVES, the Simulator opens the
Waveform Viewer to display the simulation values and generates a WIF
file.

The Simulator creates a data file when it issues the first TRACE command.
Instead of running a command procedure, as is the case with monitors,
it writes information about the changes to the trace data file.

There is a semantic difference between tracing a signal and tracing a 
variable. When a signal is being traced, only the "event"s on the signal 
will be recorded. This is equivalent to installing an event monitor on 
the signal. However, when you trace a variable, anytime that variable
is updated, the value is recorded in the trace data file.This is
similar to installing a write monitor on the variable object. The difference
is obvious when the assignment to an object updates the object with its 
previous value: in the case of a signal, no event would be recorded, but in the
case of a variable, the update is recorded in the trace data file.
See also:  MONITOR, VHDLSIM, DISABLE, ENABLE, CONTROL_VARIABLES for
        TRACE_DISABLE and TRACE_STUB.

.hS UNICON "Un-iconize (restore) a simulation window"
Syntax:
	UNICON window_tag

Changes the named simulation window from an icon back into a window.

See also:  ICON, SIMULATION_WINDOWS.
.hS UNSET "Unset a shell variable"
Syntax:
	UNSET variable_name {variable_name}

The UNSET command unsets the specified variables.

See also:  SET, VARIABLES.

.hS VARIABLES "Simulator variables and variable substitution"
There are three types of Simulator variables: read-only variables, user-
definable variables, and positional parameters. The Simulator sets read-only
variables as the simulation progresses; you cannot set them. You can set user-
definable variables. Positional parameters refer to parameters in a comm
or include file.

There are two types of read-only variables: STATUS_VARIABLES and
MONITOR_VARIABLES.

STATUS_VARIABLES are

        CRP\		CWR\		CMD_FAILED	FILE
	LAST_NAME	LINE\		LINENUM\		NOW
	TIMEBASE

MONITOR_VARIABLES are

        ACTIVE_NAME	SNAME		SACTIVE	S0
        S1 - S9		SLICE		SNUM		RET_VALUE


The user-definable variables that have special meaning to the Simulator are
called CONTROL_VARIABLES. They are

        ABS_REGION	ASSERT_STOP	BASE		COV_DISABLE
        CWP		CYCLE_POINT	DACTION_STUB	ECHO_EXECUTE
        ECHO_NAME	ECHO_READ	EXTRA_BITS	HOME
        LOCKSTEP	MON_DISABLE	MON_ISTOP	MON_STOP
        MON_STUB	PROMPT	PROMPT2	STRICT_TICK
        TRACE_DISABLE	TRACE_STUB	TRAP		USE


You change variable values by using the SET and UNSET commands. You
refer to variable values (called variable substitution) by using either
$variable_name or ${variable_name}.

For example:

        set A hello
        echo $A
prints
        hello


To see the current settings of all defined variables type SET.

See also:  CONTROL_VARIABLES, STATUS_VARIABLES, MONITOR_VARIABLES
        POSITIONAL_PARAMETERS, SET, UNSET, QUOTATION.

.hS VCDADDOBJECTS "Put VCD traces on specified objects"
Syntax:
	VCDADDOBJECTS [-split_bus] [-bidir] {levels} {name} [{name} ...]

Specify one or more variables and/or modules to trace.  {name} can be
either a signal name or a module name.  If it is a module name, {levels}
is used to specify a recursive trace.  Specifically, if {levels} is 1, then
all the variables in the topmost level of the specified modules are traces.
If it is 2, then all the variables in the topmost and second-highest 
levels are traces.  if it is 0, then all the signals in all the specified 
modules (at the topmost level and below) are traced.  For {name}s that
are signal names, the levels parameter is ignored.  Module names and
signal names can be mixed in a single VCDADDOBJECTS statement.  Names
conform to the standard VHDL hierarchical naming scheme and can 
include wildcards.  The scope selected by the command CD can also
be used to control which objects are specified by VCDADDOBJECTS, in the
same was as with the TRACE command.

With no arguments, VCDADDOBJECTS will trace all signals in the design.

If the -split_bus flag is present, the value of any traced buses will be
printed bus line by bus line.  if it is not present, bus values will
be printed as signal vectors.

If the -bidir flag is present, the value printed for the traced signals 
and/or buses will be the driving value of the traced item.  The name
of the trace, as given in the head of the VCD file, will be the name of
the traced object followed by "__o".

Note that signals on a net are not resolved by this command.  it is 
possible for a signal to be traced multiple times.

This command can be executed only at time 0.

.hS VCDCOMMENT "Insert a comment into the VCD file"
Syntax:
	VCDCOMMENT {comment}

Inserts {comment} into the VCD file as a comment.  This command can be
executed only at time 0.  Note that any comments specified before simulation
begins will be placed before the object definitions in the resulting VCD
file, even if the VCDCOMMENT commands are given after some or all of the
VCDADDOBJECT commands are given.

.hS VCDDUMPALL "Dump the current values of all VCD traces"
Dumps the current values of all traced objects to the VCD file.  This 
command can be executed only after simulation begins.

.hS VCDDUMPOBJECTS "Dump the current values of specified VCD traces"
Syntax:
	VCDDUMPOBJECTS {name} [{name} ...]

Dumps the current values of all the given traced objects to the VCD
file.

.hS VCDFILE "Specify the name for the VCD file"
Syntax:
	VCDFILE {unix_path_name} [-nomap]

Specify the filename for the VCD file.  By default, output values will be
mapped from VHDL literals to MVL9.  Specifying the -nomap flag will disable
this mapping.  This command can be executed only at time 0.

.hS VCDFLUSH "Flush trace output to the VCD file"
Flushes any trace output in system buffers to the VCD file. 

.hS VCDLIMIT "Limit the size of a VCD file"
Syntax:
	VCDLIMIT {file_size_limit}
Limits the size of the VCD file to the number of bytes specified by 
{file_size_limit}.  This can be executed only at time 0.

.hS VCDOFF "Disable VCD tracing"
Disable VCD tracing.  This causes the simulator to dump the value "X"
for all VCD traces to the VCD file.  This command can be executed only
after simulation begins.

Note that VCD traces can be enabled and disabled only as a whole.  Due 
to limitations in the VCD standard, it is not possible to enable and 
disable individual VCD traces at this time.

.hS VCDON "Enable VCD tracing"
Enable VCD tracing.  This causes the simulator to dump the current values
for all VCD traces to the VCD file.  When VCD tracing is used, tracing is
enabled by default.  This command can be executed only after simulation
begins.

Note that VCD traces can be enabled and disabled only as a whole.  Due 
to limitations in the VCD standard, it is not possible to enable and 
disable individual VCD traces at this time.

.hS VHDLDBX "Invocation of the Synopsys VHDL Debugger - vhdldbx program"
The VHDL Debugger (vhdldbx) is a graphical debugging tool that is part 
of the VHDL Simulator (vhdlsim). vhdldbx allows you to generate
Simulator commands by selecting objects from the VHDL source code and
using menus, buttons, and dialogue boxes.
	
The vhdldbx program passes to vhdlsim each argument you use when you invoke
vhdldbx. Since the debugger does not generate any output, you cannot use
the "-o" option.

To use vhdldbx you must run the X Window System. 

See also:  VHDLSIM, VHDLDBX_PULLDOWN_MENUS, VHDLDBX_TEXTVIEWER_WIN.
.hS VHDLDBX_PULLDOWN_MENUS "VHDL Debugger Pulldown Menus Subwindow"
The VHDL debugger pulldown-menus bar contains many of the Simulator
debugging commands. Use pulldown menus to issue Simulator debugging
commands. If the command requires arguments, you specify them by
selecting text or entering text in dialog boxes. The Pulldown menu
bar is structured as follows:

  Execute	Breakpoints	Monitors	Traces		Query		Stimulus \ \ \ \ \ \ \ 	Misc
  Run		Signal ->	Signal-> 	Signal 		Where		Assign...\ \ \ \ 	Help...
  Step  \ \ \ \ \ \ 	Variable ->	Variable ->	Variable		EventQueue	Hold...		Edit...
  Next    	SourceLine ->	SourceLine -> 	List		EvalExpr.	Release		Analyze...
  Restart... \ \ \ \ \ \ \ 	SubProgram ->	SubProgram ->							Search...
  Interrupt	Process ->	Process ->							Print...
  Quit	\ \ \ \ 	Edit/List	Edit/List

   - Execute
	The "Execute" menu contains six menu items that control the
	execution of the simulation.

	 \- The "Run" menu item/button generates a Simulator "run" command.
	   VHDLDBX also contains a "run duration" text field. It uses
	   any characters typed in this field as arguments to the
	   "run" command.

	 \- The "Step" and "Next" menu items/buttons generate the Simulator
	   commands "Step" and "Next". They do not generate any arguments.

	 \- The "Restart" menu item restarts the simulation by first
	   generating a dialogue box that displays the command line
	   options. You can then edit the Simulator command line and
	   invoke the Simulator using the OK button.

	 \- The "Interrupt" menu item/button generates a <control-C> or
	   Interrupt. You an use an interrupt to stop a running simulation.

	 \- The "Quit" menu item/button quits both the debugger
	   and the Simulator.

   - Breakpoints 
	The "Breakpoints" menu contains six submenus which
	set, list, and delete simulation breakpoints (stop monitors). 

	 \- The "Signal" submenu creates a breakpoint on a signal selected from
	   the VHDL source. You can create Event, Active, and Read breakpoints. 

	 \- The "Variable" submenu creates a monitor on a variable selected
	   from the VHDL source. You can create Read and Write breakpoints.

	 \- The "SourceLine" submenu creates a breakpoint on the selected
	   VHDL line(s). 

	 \- The "SubProgram" submenu creates a breakpoint on a subprogram
	   selected from the VHDL source. You can create Elaboration,
	   Call, and Return breakpoints. 

	 \- The "Process" submenu creates a breakpoint on a process selected
	   from the VHDL source, block (when the process suspends), unblock
	   (when the process resumes), or tprocess (display lines as they are
	   executed) breakpoint. Creating a tprocess breakpoint creates a Text
	   Viewer window displaying the text of the process. 

	 \- The "Edit/List" submenu enables you to edit, list, and delete 
	    breakpoints. It displays a menu dialog. You can then edit or delete 
	    breakpoints by selecting them from the list and clicking the 
	    Edit or Delete button.

   - monitors 
	The "monitors" menu contains six submenus which
	set, list, and delete simulation monitors (continue monitors). 

	 \- The "Signal" submenu creates a monitor on a signal selected from
	   the VHDL source. You can create Event, Active, and Read monitors. 

	 \- The "Variable" submenu creates a monitor on a variable selected
	   from the VHDL source. You can create Read and Write monitors.

	 \- The "SourceLine" submenu creates a monitor on the selected
	   VHDL line(s). 

	 \- The "SubProgram" submenu creates a monitor on a subprogram
	   selected from the VHDL source. You can create Elaboration,
	   Call, and Return monitors. 

	 \- The "Process" submenu creates a monitor on a process selected
	   from the VHDL source, block (when the process suspends), unblock
	   (when the process resumes), or tprocess (display lines as they are
	   executed) monitor. Creating a tprocess monitor creates a Text
	   Viewer window displaying the text of the process. 

	 \- The "Edit/List" submenu is used to edit, list, and delete 
	    monitors. It displays a menu dialog. You can then edit/delete 
	    monitors by selecting them from the list and clicking the 
	    Edit or Delete button.

   - Traces 
	The "Traces" menu contains three submenus which
	set and list simulation trace monitors. 

	 \- The "Signal" submenu creates a trace on a signal selected from
	   the VHDL source. 

	 \- The "Variable" submenu creates a trace on a variable selected
	   from the VHDL source. 

	 \- The "List" submenu displays a list of trace monitors set in the
	   current design.

   - Query
     The "Query" menu contains 3 menu items you can use to retrieve
     information about the state of the simulation. This information includes
     the contents of a given process execution stack, a list of the active
     processes, and values of VHDL objects.

	 \- The "Where" menu item prints a stack back-trace for the selected
	   process in the Command Output subwindow.

	 \- The "EventQueue" menu item executes the Simulator "status" command.
	   EventQueue causes a printout of the ready-to-run queue and
	   processes waiting in the Command Output subwindow. 

	 \- The "EvalExpr." menu item/button generates the Simulator command
	   "evaluate". It prints the value of the selected object or
	   expression in the Command Output subwindow.
		   	
   - Stimulus
     The "Stimulus" menu contains 3 menu items to set, unset, and hold the
     values of VHDL objects during the simulation.
	   
	 \- The "Assign" menu item sets the value of the selected VHDL object
	   to the value of a given expression. If the object is of an
	   enumeration type, the dialog box lists the enumeration literals
	   for that type to choose from. 

	 \- The "Hold" (stuck at) menu item keeps the value of a VHDL signal
	   at the value of the expression you entered in the dialog box. If the
	   object is of an enumeration type, the dialog box lists the
	   enumeration literals for that type to choose from. 

	 \- The "Release" menu item releases a Hold and allows the signal's
	   value to be changed during the simulation.
.bp
	   
   - Misc
     The "Misc" menu contains 5 miscellaneous menu items.
	   
	 \- The "Cd" menu item allows you to change hierarchy levels in
	    the Simulator.

	 \- The "Help" menu item displays a list of the Simulator and debugger
	   topics. To get information on a subject, double-click the topic and
	   then click on the "Apply" button. To go back to the list, and click on
	   "Apply" without selecting a help topic. 

	 \- The "Edit" menu item generates an xterm window displaying an
	   editable copy of the current source file. You can edit the file
	   with the default editor "vi", or you can use another editor by
	   setting the EDITCMD setup variable to a command that invokes another
	   editor.

	 \- The "Analyze" menu item enables you to reanalyze the design from
	   within the debugger by displaying a dialog box where you can enter
	   a command.

	 \- The "Search" menu item displays a dialog box where you can enter
	   a text string to search for. The debugger searches only the
	   file displayed in the debugger's text viewer subwindow. You
	   can optionally search forward or backward and consider
	   or ignore the case of the text.

	 \- The "Print" menu item enables you to print the VHDL that is file in the
	   current file Text Viewer window.

	 \- The "System Cd" menu item enables you to change directories in
	    your host file system.

	 \- The "Hierarchy Browser" menu item enables you to view a list of
	    VHDL objects in the hierarchy.

See also:  VHDLDBX, VHDLDBX_TEXTVIEWER_WIN.

.hS VHDLDBX_TEXTVIEWER_WIN "VHDL Debugger Text Viewer Window"
Text viewer windows display VHDL source code under the VHDL debugger. 
Three types of text viewer windows are available: text viewer subwindow
built into the debugger interface, application-dependent text viewer windows,
and independent text viewer windows.

-  VHDL Debugger interface subwindow
   This subwindow is built into the debugger interface. It tracks the progress
   of the simulation by displaying the VHDL current file that contains the
   line the Simulator most recently executed. 
   
-  Application-Dependent Window
   The debugger creates this window when you specify the "step within"
   menu item. It also generates this window if you
   specify the "-tv" option with source line monitors. The deletion of
   monitors closes this type of windows.

-  Independent window
   Create this window from an existing text viewer window using the
   "New view" command under the "View" menu. The debugger does not update
   this window as the simulation progresses.

See also:  VHDLDBX, VHDLDBX_PULLDOWN_MENUS.
.hS VHDLSIM "Invocation of the Synopsys VSS Family Simulator - vhdlsim program"
You invoke the Synopsys VSS Family Simulator - vhdlsim as follows:

        vhdlsim [options] [Library.]Configuration_name
    or  vhdlsim [options] [Library.]Entity_name
    or  vhdlsim [options] [Library.]Entity_name Architecture_name
    or  vhdlsim -v

options:  [-t base_unit] {-i include_file} {-e echoed_include_file}
          [-w trace_filename] [-s script_file] [-v] [-o output_file]
          [-sdf[_min |_max |_typ |_top declregion |_af ] -sdf sdf_filename]
	  [-acc] [delay n] [-g] [-gfile command_file_name]

The first three forms of invocation simulate the named design
description. The final form of invocation prints version information
about the Simulator and exits.

You specify the name of the configuration or entity you would like to
simulate. If the form of the name is L.C, the Simulator looks in the
design library named L for the entity or
configuration named C. If you do not specify a library name, the
Simulator uses WORK.

The first form of invocation simulates the description configured by
the named configuration, where the configuration specifies the top
level entity-architecture pair.

The second form of invocation simulates the description based on the
named entity together with its most recently analyzed architecture.

The third form of invocation simulates the description based on the
named entity-architecture pair.

You can use the second and third forms of invocation only if all the component
instantiations in the description are configured in a "bottom-up"
fashion. The Simulator tells you if a particular entity-architecture
pair requires configuration.

You can specify the following options on the vhdlsim command line:

-t base_unit
        Sets the base unit of time for your simulation. Legal values are
        FS (femtoseconds), PS (picoseconds), NS (nanoseconds),
        US (microseconds), MS (milliseconds), and SEC (seconds). If
	you do not specify this option, the Simulator uses the
	.SYNOPSYS_VSS.SETUP TIME BASE entry. If there is no TIMEBASE
	entry, the Simulator uses FS.

-i filename
        Specifies an include file for your simulation. You can give multiple
        -i options. The Simulator reads and executes the include files
        in left-to-right order (after the RUNREAD file, if there is
	one) before it issues the Simulator prompt.
.bp

-e filename
        The -e flag is similar to the -i flag above. The only difference
        is that the -e flag causes the Simulator to echo commands to the
        standard output device as it reads them.

-w filename
        Specifies the default trace output file name.

-v
        Displays Simulator version information and exits.

-o filename
        Specifies an output file for your simulation. The Simulator uses this
        file as the standard output. The Simulator places output that is not
        explicitly redirected within the simulation in the named file.

-s filename
        Saves a copy of all Simulator output (written to the
        standard output device) and all Simulator input (read from the
        standard input device) in the filename.

-uf
        Turns off signal evaluation optimization for the Synopsys
	standard package. See the Synopsys VSS Family
        Packages Manual for more information on the Synopsys standard
        packages.

-sdf_min
        Overlays the minimum timing values from the SDF file.

-sdf_max
        Overlays the maximum timing values from the SDF file.

-sdf_typ
        Overlays the typical timing values from the SDF file.

-sdf_top declregion
        Overlays the timing values for the sub-portion of the design
        below the named declarative region.

-sdf_af
        Creates an assign file that performs the override of the
        timing value. The Simulator takes the name of the file from
	the SDF file. For example, given an SDF file myfile.sdf it
	creates an assign file myfile.inc.

-sdf sdf_filename
	Reads SDF file sdf_filename to incorporate delay timing and
	backannotation in the VHDL Simulator.  
-acc
        Uses the accelerated algorithm for special gate level components.

-delay n
        Uses delay n for all special gate level components. The number
        n must be 0 or a positive integer.

-g
        Interactively prompts for top-level generic values. The
        Simulator assigns the values you enter from the keyboard to
        the generics before it elaborates the design hierarchy.

-gfile command_file_name
        Reads top-level generic assignments from the file
        command_file_name. The command file is like an include file 
        except it can only contain assignment statements, and the
        target of each assignment must be a top-level generic. The
        Simulator reads the assignment statements from the command
        file and displays and applies them prior to elaboration.

See also:  INCLUDE, TRACE, RESTART.

.hS WFIELD "Modifying Text Field Attributes"
Syntax:
	WFIELD window_tag(field_name) [attribute=value] {attribute=value}

A pad window can contain up to approximately 1000 uniquely named text fields.
A named text field is a pad-displayable, text-object with the following
attributes:

	- Text in the field
	- Foreground and background color of the field
	- Position (Y,X) of the field within the pad
	- Font for the text
	- Boolean flag indicating whether the field is to blink or not
	- Enabled/disabled attribute indicating whether the field is
 	  visible or hidden 

The WFIELD command creates, manipulates and modifies the appearance of
text fields. In the above syntax, the "window_tag(field_name)" pair
identifies the pad and text field to which the command applies. If the
text field does not exists in the pad, WFIELD creates it. The
"attribute=value" parameter identifies field attributes and their settings.
For example,

  + wfield window_tag(field_name) pos=<Y,X>
	Positions the field Y character positions from
	the top and X character positions from the left
	edge of the pad. If the field already exists at another
	location, WFIELD moves it.

  + wfield window_tag(field_name) font=<font_name>
	Writes the text of the field using the font font_name. The
	valid values for font_name are in the "*fontList" resource
	specification in your .Xdefaults file. See the "Font
	Attribute" section below.

  + wfield window_tag(field_name) fg=<color> bg=<color>
	Displays field_name using the foreground color fg and
	background color bg. The value of <color> is a character
	string naming the color.

  + wfield window_tag(field_name) blink[=<true|false>]
	If true, the field starts blinking. If false, a blinking
	field stops blinking. If you do not indicate an attribute
	value, the default is true.

  + wfield window_tag(field_name) <enable|disable>
	disable hides an existing field but does not
	delete it. You can enable a disabled field, causing it to
	reappear.

  + wfield window_tag(field_name) delete
	Removes the field. You should delete fields if you no longer
	need them.

You can use the WFIELD command to set several attributes at once. For
example,

  # wfield bus_output(collision) pos=3,10 font=big blink fg=Red bg=Black
  # echo Warning: Bus collision Detected! > bus_output(collision)

.hB
Font Attribute 
To use the font attribute of WFIELD, you must first set up your
\.Xdefaults file to make available the fonts you need. The
\.Xdefaults file contains X resource settings for various X11
applications. 

In the X window system, a resource is any data you can customize that
an X application uses to determine behavior or appearance. Simulation
windows use the "fontList" resource to determine the fonts available
in a pad window and the names that refer to the fonts in the WFIELD
command.

To make a font (or a list of fonts) available in a pad window, add the
following to your .Xdefaults file. (Usually you can find the
\.Xdefaults file in your home directory. If it is not there, create
one.)

  PadWindow*fontList: \\
	-adobe-courier-medium-r-normal--14-100-100-m-90-iso8859-1 = normal \\
	-adobe-courier-medium-r-normal--8-100-100-m-90-iso8859-1  = tiny \\
	-adobe-courier-medium-r-normal--12-100-100-m-90-iso8859-1 = small \\
	-adobe-courier-medium-r-normal--18-100-100-m-90-iso8859-1 = big

The string "PadWindow" identifies the application to which the
following resource is to apply and "fontList" is the resource. You can
place any fonts after the colon that are available on your machine.
(To display a list of all the available fonts, use the "xlsfonts" Unix
command.) If you need more than one line to list the fonts, use a
backslash ('\\') to join the lines. 

The sytax of a font definition is

			<font>=<font_name>

<font> is any entry shown by "xlsfonts" and <font_name> is the
name that you use to reference the font in the WFIELD command. Once
you place the "fontList" resource in your .Xdefaults file, you
must execute the "xrdb" Unix command to force the X Resource Manager
to read and install the new resource setting. Use the syntax

	$ xrdb .Xdefaults

The font is now available for the WFIELD command. For example,

	# echo Tiny Text > mypad(myfield)
	# wfield mypad(myfield) font=tiny

See also:  SIMULATION_WINDOWS, xlsfonts (Unix command).
.hS WHERE "Print out a process stack"
Syntax:
	WHERE [process_name]

The WHERE command prints a stack back-trace for the named process.
The stack back-trace prints the name of each active subprogram on
the process_name stack along with the value of the parameters to the
subprogram.

If you do not specify a process, the Simulator uses the value of
the control variable CWP (current working process), if it is set. If it
is not set, the Simulator tries to use the value of the status variable
CRP (Current Running Process).

NOTE: This command will not display any process or subprograms in
compiled code mode in this release.  

See also:  CONTROL_VARIABLES for CWP, STATUS_VARIABLES for CRP.
.hS WHILE "Conditionally iterate over a set of commands"
Syntax:
	WHILE (boolean_vhdl_expression) LOOP
		{command_lines}
	END LOOP

The WHILE command is executed as follows:

	1. The Simulator evaluates the boolean expression.
	
	2. If the value of the expression is TRUE, the Simulator
	   executes the enclosed command lines and returns control 1
	   above.
	     
	   If the value is FALSE, control passes to the
	   line after the END LOOP.

See also: IF, FOREACH, LPBREAK, LPCONTINUE.
.hS WIFIN "Read a wif stimulus file"
Syntax:
        WIFIN stim_file.iw

The WIFIN command opens a WIF stimulus file. The Simulator uses this
file to stimulate signals within the VHDL simulation.

The Simulator performs various checks to verify that the simulation
signals exist and are compatible with the stimulus vectors in the
stimulus file. If a check fails, the Simulator generates an error
message and ignores the stimulus for that vector.

Stimulating a signal is similar to the ASSIGN command. The only
difference is that the stimulus has no effect when the Simulator
"holds" a signal. See also: ASSIGN, HOLD.

.hS WMOVE "Move an output window"
Syntax:
	WMOVE window_tag X,Y

WMOVE moves the top left corner of the specified window to X character
positions from the left of the screen and Y lines from the top of the
screen.

See also:  SIMULATION_WINDOWS, WSIZE, ICON, UNICON.

.hS WSIZE "Resize an output window"
Syntax:
        WSIZE window_tag W,H

WSIZE resizes the named output window. The new size is W
character positions wide and H lines tall.
See also:  SIMULATION_WINDOWS, WMOVE, ICON, UNICON.
.hS ASIC_simulation_violation_message  "Asic Simulation Violation messages"
VSS prints out ASIC simulation messages which fall in the following categories. Use help followed by the category name to get more information about each category. 
Constraint_message 
Hazard_message
BusViolation_message 
Quiescence_message
ASIC_simulation_note_message

	All violation messages by default go to stdout. 
	You can redirect the violation messages to an ascii file by using `-gsvf <file>' option to the simulator. 
.hS Constraint_message "ASIC Simulation constraint violation messages"
Format: 
	<constraint_mesg>:=
		<current_sim_time> <instance_path>(<celltype>) 
		VIOLATION: <violation_type> 
		<pin1_name>(<transition>@<time>) WRT <pin2_name>(<transition>@<time>)
		SPEC=<constraint_time_val> [XGEN]

        <current sim time>:= current simulation time in proper time units.
        <violation_type>:= character string for the violation type(e.g setup)
        <instance_path>:= full path name of the enclosing ASIC CELL
        <cell_type>:= name of the ASIC CELL
        <pin1_name>:= name of the corresponding pin of the ASIC CELL
        <pin2_name>:= name of the corresponding pin of the ASIC CELL
        <transition>:= <<MVL9_val> -> <MVL9_val>> | R | F | C
        <time> := transition time in proper units
        <constraint_time_val>:= the specified value of the constraint

	[XGEN] is printed out if 'X' is generated when the violation occurs

Example:
        1600 NS /test/inst_8(dff_1) VIOLATION: SETUP clk(0->1@1600 NS) WRT data(C@1593 NS) SPEC=8 NS XGEN

        1610 NS /test/inst_8(dff_1) VIOLATION: PWID_POS clk(1->0@1610 NS) WRT clk(R@1600 NS) SPEC=15 NS
.hS Hazard_message "ASIC Simulation hazard violation messages"
Format:
	<hazard_msg>:=
		<current sim time> <instance_path >(<celltype>) 
		VIOLATION: <violation_type> 
		<pin1_name>(C <current_value> <,[P|N] <value>@<time>>+) 
		[XGEN] 
 
	<violation_type>:= SPIKE | GLITCH
	<current_value>:= <MVL9_val>
	<value>:= <MVL9_val>, a value that was pending before the hazard
		     occurred if preceeded by P, or the new value that
		     is being scheduled and is causing the hazard if preceeded
		     by N.
	<time>:= the time at which the pending or new value is to mature

Example:
	2301 NS /test/inst_7(AOI_1) VIOLATION: SPIKE out(C 0,P X@2303 NS,N 1@2304 NS,P 0@2317 NS) XGEN
.hS   BusViolation_message "ASIC Simulation bus violation messages"
Format:
	<busviolation_msg>
		<current sim time> <full_pathname_to_the_node> 
		VIOLATION: <bus_violation> <contention_msg_state> 
		[DRIVERS: <<instance_path>(<celltype>):<pin_name> 	
		(<driving_val>)>+]
 
	<bus_violation> := BUS_CONTENTION|BUS_FIGHT|BUS_FLOAT
	<full_pathname_to_the_node>:= path name to the signal
	<contention_msg_state>:= START|CHANGE|END
	<driving_val>:= MVL9_val

Example:
	2302 NS /test/inst1(BUF_1)/output VIOLATION: BUS_CONTENTION START DRIVERS: /test/inst1(BUF_1):output(H) /test/inst2(BUF_2):output(H) /test/inst3(BUF_1):output(L)
	2304 NS /test/inst1(BUF_1)/output VIOLATION: BUS_CONTENTION CHANGE DRIVERS: /test/inst1(BUF_1):output (H) /test/inst3(BUF_1):output(L)
	2310 NS /test/inst1(BUF_1)/output VIOLATION: BUS_CONTENTION END


	2302 NS /test/signal_1 VIOLATION: BUS_FLOAT START
	2310 NS /test/signal_1 VIOLATION: BUS_FLOAT END DRIVERS: /test/inst3(BUF_1):output(L) 
.hS Quiescence_message "ASIC Simulation Quiescence violation message"
Format:
	<quiescence_msg> :=
		<current sim time> VIOLATION: QUIESCENCE 
		<object_name> ON  <queue> ["[ and other(s)]"]


	<object_name> := path name to the process|component_instance|driver
 	<queue> := UPDATEQUEUE|EVALQUEUE

Example:
	5 NS VIOLATION: QUIESCENCE /TOP/C1/C1 ON UPDATEQUEUE [and other(s)]
	11 NS VIOLATION: QUIESCENCE /TOP/P1 ON EVALQUEUE

.hS ASIC_simulation_note_message "Asic Simulation Note message"
Note messages do not have a fixed format.
.hS dut_quiet "Check quiescence on DUT"
Syntax : 
	dut_quiet

	At any given time after elaboration, the command dut_quiet checks to see if
there is a process or component pending evaluation or a driver belonging to
the DUT that is pending update.
If there is even one, a Quiescence violation 
message is issued.
	The DUT can be specified either by using the "-dut <instance_pathname>"
option for each highest-level subtree that constitutes the DUT, or by
setting the variable DUT in the .synopsys_vss.setup file. When both are
specified, then DUT is the union of the two.
	dut_quiet command is not available with VSS-Pro.

See also: Quiescence_message
.hS WILDCARDS

You can use the following wildcard symbols to specify names on the
Simulator command line:

*  Matches zero or more characters.

?  Matches one character.

Wildcard symbols enable you to match several names in the
simulation by using a single name plus a wildcard.

EXAMPLES:

#ls*       -- Operates on all objects

#ls S?     -- Operates on all objects that have 2-char names that
           -- begin with S.

See also: Quotation.

