User Guide: DSim Common Options

Options can be applied on the command line. Additionally, DSim will apply any valid DSim options which have been assigned to the environment variable $DSIM_CMD_OPTIONS. $DSIM_CMD_OPTIONS are applied after all other options.

Conversely, DVlcom and DVhcom will respond to $DVLCOM_CMD_OPTIONS and $DVHCOM_CMD_OPTIONS respectively.

DSim Cloud CLI

In DSim Cloud CLI, the 3 environment variables need to be used like so:

• $DSIM_CMD_OPTIONS should be %DSIM_CMD_OPTIONS%
• $DVLCOM_CMD_OPTIONS should be %DVLCOM_CMD_OPTIONS%
• $DVHCOM_CMD_OPTIONS should be %DVHCOM_CMD_OPTIONS%

Getting Help

-help will list all options supported by the executable. This applies to any Metrics product.

Standard Options

The following options are common to most HDL simulators. Those specific to a particular Metrics product are annotated in the table.

Option	DSim	DVlcom	DVhcom	Description
+ignore+item[+...]	Y	Y		Specifies preprocessor directives, valid in other tools, that are to be ignored by DSim. When encountered, the directive and any other text on the same line will be ignored. Multiple items can be specified separated by +. This option may be given more than once.
+incdir+dir[+...]	Y	Y		Specifies one or more directories to add to the include file search path. Separate path elements with '+' signs. This option may be given more than once.
-incdir dir[:...]	Y	Y		Specifies one or more directories to add to the include file search path. Separate path elements with ':' signs. This option may be given more than once.
+define+NAME[+...]	Y	Y		Define a preprocessor macro called NAME on the command line. +define+NAME will define the name such that `ifdef will see it. +define+NAME=value will assign a specific value to the name. This option can be given more than once.
-define NAME[:...]	Y	Y		Define a preprocessor macro called NAME on the command line. -define NAME will define the name such that `ifdef will see it. -define NAME=value will assign a specific value to the name. Separate define elements with ':' signs. This option may be given more than once
-f / -F file	Y	Y	Y	Include additional options in file. If -f is used, then any items in the file are interpreted relative to the directory in which DSim was invoked. Alternatively, -F will interpret pathnames relative to the location of the file being read.
-l logfile	Y	Y	Y	Specify the log file (default is dsim.log which logs stdout and stderr from DSim itself). To suppress creation of a log file, use -l /dev/null.
-v file	Y	Y		Specify a library file, which is scanned if required to resolve references to otherwise undefined module instances. This option may be given more than once. Each file may contain one or more module definitions which are used as required to resolve unresolved references.
-y dir	Y	Y		Specify a library directory, which is scanned if required to resolve undefined module references. This option may be given more than once. For each unresolved module, a file having the module's name, plus any extension, is searched in all -y path directories, and is loaded as required.
+libext+xyz[+...]	Y	Y		Specifies a suffix xyz to use for searching in -y library directories.
-iter-limit n	Y			Set scheduler iteration limit to detect infinite zero-delay loops (default: 1000000)
-profile <level>	Y			Enable cpu time profiling for the entire simulation reporting at the given level. The profiling feature has some limitations and although it provides significant value it is not a full featured profiling tool. For more information see Profiling
-profile-start <time>	Y			Start profiling at the given simulation time
-profile-end <time>	Y			End profiling at the given simulation time
-gen-profile	Y			Compile time option to instrument code to track number of times a function is called during simulation. Results reported when -profile is used
-sv	Y	Y		Make -sv20XX options apply to all SystemVerilog and unknown files regardless of suffix. Note: Exclusion of this option may defer to assumptions made on the filename, see below.
-sv2005	Y	Y		Treat SV-LRM'05 keywords as reserved in SystemVerilog and unknown files. Note: Exclusion of this option will may defer to assumptions made on the filename, see below.
-sv2009	Y	Y		Treat SV-LRM'09 keywords as reserved in SystemVerilog and unknown files. Note: Exclusion of this option may defer to assumptions made on the filename, see below.
-sv2012	Y	Y		Treat SV-LRM'12 keywords as reserved in SystemVerilog and unknown files (default). Note: Exclusion of this option may defer to assumptions made on the filename, see below.
-sv2017	Y	Y		Treat SV-LRM'17 keywords as reserved in SystemVerilog and unknown files. Note: Exclusion of this option may defer to assumptions made on the filename, see below.
-sysvlog-ext	Y	Y		Provide a set of one or more extensions, delimited by : or , that should be understood to represent SystemVerilog files. Initially only .sv is included in this set. Each use of this option will replace the known set.
-timescale <unit/precision>	Y			Provide a default timescale for any design unit which has no timescale directive. Note: if no timescale directive is given either in the code or via the -timescale option the simulator default of 1ns/1ns will be used.
-top name:name	Y			Specifies the top-level module for elaboration. If this option is not given, then all modules which are not instantiated by some other module are used as top-level modules, as per SV-LRM. If this option is given (possibly more than once) then only the named module(s) are used as top-level modules. You may specify multiple top-level modules using -top multiple times, or by using colons to separate names from the single argument. You need to specify at least one top-level module if pre-compiled libraries are involved in the design elaboration (e.g. such is the case with VHDL).
-vhdl2000			Y	Treat VHDL-LRM'00 keywords as reserved in VHDL and unknown files.
-vhdl2008			Y	Treat VHDL-LRM'08 keywords as reserved in VHDL and unknown files.
-vhdl2019			Y	Treat VHDL-LRM'19 keywords as reserved in VHDL and unknown files.
-vhdl87			Y	Treat VHDL-LRM'87 keywords as reserved in VHDL and unknown files.
-vhdl93			Y	Treat VHDL-LRM'93 keywords as reserved in VHDL and unknown files.
-vlog1995	Y	Y		Treat only V-LRM'95 keywords as reserved in Verilog files
-vlog2001	Y	Y		Treat V-LRM'01 keywords as reserved in Verilog files
-vlog2005	Y	Y		Treat V-LRM'05 keywords as reserved in Verilog files (default)
-vlog_sv2005	Y	Y		Treat SV-LRM'05 keywords as reserved in Verilog files
-vlog_sv2009	Y	Y		Treat SV-LRM'09 keywords as reserved in Verilog files
-vlog_sv2012	Y	Y		Treat SV-LRM'12 keywords as reserved in Verilog files
-vlog-ext	Y	Y		Provide a set of one or more extensions, delimited by : or , that should be understood to be Verilog files. Each uses of this option will replace the known set.
-version	Y	Y	Y	Prints the formal version name
-version-verbose	Y	Y	Y	Prints extra information about the build from which the release was built. This matches what DSim prints into the log file at the end of a simulation run and is potentially useful when communicating with the Metrics support team.

Note: A file is recognized as containing code written against a particular version SystemVerilog by their primary or secondary extensions against any known extensions (-sysvlog-ext or vlog-ext). Unrecognized files can be forced to SystemVerilog using any of the -sv* options, otherwise Verilog is assumed.

The primary extension can also be used to identify compression, see Transparent Compression for supported compression types. See Input Filename Examples for examples using different filename extensions with and without compression specification.

Controlling Error Messaging

Text messaging is used to flag various exception conditions during compile, elaboration, or run phase. The header of a message is formatted in accordance with the exception severity, as follows:

• =F:[MessageName] for fatal errors
• =E:[MessageName] for errors
• =W:[MessageName] for warnings
• =N:[MessageName] for informational notes

After flagging an error or fatal error, the compilation phase is aborted. Warnings and informational notes do not affect the rest of the compile, elaboration or run phase.

The severity of a message may be altered using the following options:

Option	Description
-error msg[:msg...]	Promote the warning/informational messages to errors.
-warn msg[:msg...]	Demote certain error messages to warnings.
-info msg[:msg...]	Demote error/warning messages to informational.
-suppress msg[:msg...]	Suppress a message altogether.

where msg is the MessageName as given inside the square brackets in the header line. For example, to suppress a "missing timescale" error message, use

 

-suppress MissingTimescale

 

These options may be given more than once. For example:

 

-error ConflictAssignToVar -error MultiBlockWrite

 

In order to alter the severity of multiple messages, concatenate their names using a colon. For example:

 

-error ConflictAssignToVar:MultiBlockWrite

 

You can also promote/demote the severity of an entire class of messages by specifying note, warning, error or fatal instead of a message name. Overrides of individual messages take priority over such "global" overrides. e.g.:

 

-error warning -suppress MultiBlockWrite

 

will promote all warnings to errors, with the exception of MultiBlockWrite, which will be suppressed.

Not all error messages can be demoted. Error messages that can be demoted will be labelled "<demotable>".

These options apply to DSim, DVlcom, and DVhcom.

Error Message Limits

Simulation may be terminated based on the count of run-time errors. You may enable this capability by setting the count threshold.

Option	Description
-exit-on-error n	Terminate the simulation if the count of run-time errors reaches the specified threshold n. n shall be a positive integer. By default, the threshold is undefined.

Effectively this option has the same effect as the following pseudocode.

 

initial begin
   wait (number_of_system_errors == n);
   $fatal(0, "The message limit has been reached");
end

 

This option is available in DSim and applies to the simulation.

Debugging

Option	Description
-debug-verbose category[:...]	Trace operation of one or more specified categories. Separate categories with ':' signs. The categories are: pp - preprocessing, hier - instance hierarchy, lib - library maps.
-g	Enable symbolic debugging.

The -debug-verbose pp option traces operation of the preprocessor. The following actions are logged when enabled:

• Opening files
• Defining/undefining macros, including defining from command line
• Entering a new include file
• Resuming former input at end of include file

This option is available in DSim, DVlcom, and DVhcom.

The debug-verbose lib option traces design elements being placed in libraries and default library search paths. This option is available in DSim, DVlcom, and DVhcom.

The debug-verbose hier option prints the instance hierarchy and the module/configuration-rules for an instance. This option is available in DSim.

The -g option is provided for future use by a GUI debugger. For the moment, enabling symbolic debugging will allow backtraces printed when a fatal signal happens (e.g. null handle dereference) to have file and line number information.

There is no simulation-time performance penalty incurred with -g. However, compiles will be slower.

This option is available in DSim.

C Language Support

C or C++ source code files or object files and libraries can be passed to DSim to compile and link into the generated image.

The PLI and DPI assume that any linked code conforms to C language ABI and naming conventions. C code is obviously compliant. In C++ files the standard practice is to use extern "C" for any function that is to be linked into the simulation via DPI. Other languages may require additional handling.

Option	Description
-cc c_compiler_name	Specifies the name of the gcc-compatible C/C++ compiler
-c-opts options	Specifies additional options to pass to the C/C++ compiler
-ld-opts options	Specifies additional options to pass to the linker.
-cc-verbose	Prints extra information indicating the full commands used to compile each C/C++ file

These options are available in DSim.

Reproduce

Option	Description
-repro dsim.env	Reproduce from compile/run file.

When a tool, such as DSim, DVlcom, or DVhcom is run, it creates a file named dsim.env, dvlcom.env, or dvhcom.env, respectively. The file contains a record of the invocation environment: the path to the executable binary, the command line arguments and the shell environment variables. This file is useful to support personnel to replicate a run, regardless of the complexity of any scripts that may be wrapped around the tool. The -repro option will run the tool using the environment that was recorded in the given environment file.

Controlling Compiler Behaviour

Option	Description
-j N	Specify number of parallel compile jobs (default N=1).
-no-incr-compile	Indicates that an incremental compile is not necessary and that the related overhead and peristent artifacts will not be needed.
-build-all	Rebuild all modules (not incremental)

DSim uses an incremental/parallel compile strategy. It turns out that the bulk of the compile time is used in final code generation. To minimize compile time, after parsing/elaboration and optimization, DSim determines which modules in the design need code regenerated. The final code generation step is invoked for each such module, potentially in parallel.

The -j option is helpful to compile your code faster if you have multiple CPUs in your machine. It specifies the number of compile jobs that can run in parallel (default 1). Increasing the parallelism can reduce compile time, at the expense of compile machine memory.

The incremental build function is designed to be robust: it ought to compile only what is necessary, and never compile less than necessary. However, should there be a need to force a recompile of every module (e.g. to purge suspected stale cache information) the -build-all option will do just that.

As well the -no-incr-compile will have a similar effect as -build-all. In additon no overhead will be used to allow for incremental compiles in the future, and all compilation artifacts are removed after a successful compile. The results are a slighty faster compile and less resulting disk space.

Instantiation Depth

Option	Description
-max-inst-depth n	Sets maximum instantiation depth (default 100).

This option sets the maximum number of levels of hierarchy supported. The limit exists to detect runaway recursive instantiations, where a module instantiates itself with the same parameters, directly or indirectly. If the limit is too low for your design, then you can raise it.

NOTE: Controlled recursive instantiation is supported and encouraged! With "controlled" instantiation, a module instantiates itself, albeit with different parameter values. Generate statements are used to test the parameters and terminate the recursion.

Using UVM (Universal Verification Methodology)

UVM is an externally developed package intended for faster development of verification platforms. To properly use please consult external documentation, but the core functionality can be simply enabled in the DSim products.

Option	Description
-uvm version	Specifies if UVM should be included and which version should be used. See Using Verification Frameworks for more information

This option is available in DSim and DVlcom. It needs to only be specified once per invocation.

The version given should correspond to one of the UVM installations provided with the DSim release. For example -uvm 1.2 or -uvm 1.1b. Alternatively providing the value of default will utilize the UVM_HOME environment variable setting in the current working environment.

If any missing components are encountered, warnings and any resulting errors will be reported.

Defining Parameters on the Command Line

Option	Description
-defparam name=value	Overrides a parameter or generic in hierarchy.

This option is available in DSim. It may be given more than once.

The name portion may contain a dot, in which case it is a full hierarchical path to some arbitrary point in the Verilog design.

Alternatively, the name may not contain a dot, in which case it affects each top-level:

• Verilog module having a parameter by that name
• VHDL entity having a generic by that name

The value must be a constant using proper syntax. Binary/octal/hex/decimal bases are accepted, as are integers, floating-point numbers and string literals. No other lexical element, including assignment patterns, is accepted.

Since the : character is used to delimit multiple parameter definitions, if the value is a string literal and contains : then it should be encapsulated with either single or double quotes.

In all cases, the effect is to override a parameter in the design, as if the Verilog defparam statement was given with the same arguments in some top-level module of the design.

VHDL-Specific Options

Option	Description
-explain	Provide verbose explanation of inviability/ambiguity errors
-vhdl-no-ov-chk	Disable integral arithmetic overflow checking

VHDL permits operator overloading, and disambiguates expressions based on the types of the operands as well as the type of the result. Each "innermost complete context" provides an expected data type for the expression. The rules for resolving overloads can be quite arcane and complex. The result of a failed constraint is either an ambiguity (more than one solution found) or a "no viable alternatives" (no solutions found) error.

The -explain option enables extra detail for ambiguity and no-viable alternatives errors. The detail ought to help debug constraint failures in the more complex cases. However, the detail report can be voluminous, and a distraction if the failure is easy enough to debug without it. It is recommended to enable this option only as required.

VHDL requires overflow checking for integral arithmetic. DSim supports overflow checking, but other VHDL implementations do not. -vhdl-no-ov-chk will disable overflow checking for compatibility with legacy code, or for slightly improved runtime performance.

Controlling SystemVerilog Assertions

Option	Description
-vacuous	Execute the pass action regardless whether success is vacuous or nonvacuous. By default, execute the pass action for nonvacuous successes only.
-no-sva	Disables SVA support during compilation, causing sequences, properties and concurrent assertion statements to be ignored.

These options are available in DSim and DVlcom and applies to compilation of SystemVerilog assertions.

Controlling UDP update region

By default both sequential and combinational UDP output updates are scheduled in the ACTIVE region. It may be desirable to schedule sequential output updates in the NBA region.

Option	Description
-seq-udp-nba-region	Schedule an update of a sequential UDP output into the NBA region

These options are available in DSim and apply to simulations of SystemVerilog UDP components.

Controlling optimization

Option	Description
-noopt	Disable optimization

These options are available in DSim and apply to the compiling of a simulation image.

-noopt disables most optimizations. Use only if you suspect a bug in the optimizer. Up to 10x performance degradation can be seen with optimizations disabled.

Gate-Level Simulation

These options are available in DSim and apply to simulations of SystemVerilog components.

Min/Typical/Max timing

Option	Description
-comp-mindelays	Compile minimum delays
-comp-typdelays	Compile typical delays
-comp-maxdelays	Compile maximum delays

The above options affect the execution of "mintypmax expressions" which are triples of values in the form (min : typ : max) at compile time. Using one of these options locks the compile of the design to the specified timing delay. Note that using these compile options disables the usage of the run-time options mentioned below since the selected compile options will lock in the selected delay in the design.

When one of the above compile-time options is given. a mintypmax expression whose alternatives are constants is considered to be a true constant, meaning it can be used to assign Verilog parameters.

Option	Description
-mindelays	Use minimum delays
-typdelays	Use typical delays (default)
-maxdelays	Use maximum delays

The above options affect the execution of "mintypmax expressions" which are triples of values in the form (min : typ : max). At run-time, the minimum, typical or maximum value is used depending on which run-time option is selected.

All values of "mintypmax expressions" are compiled in at compile time. They can be "selected" with the above compile time options and at run time only the "selected" expression is evaluated. If the compile time options are not used and only the run time options are used then only the "selected" expression is evaluated, noting that the expressions do not have side effects.

Controlling Timing Imposed by Specify Blocks

The following options interact with timing controls indicated using specify blocks within modules.

Modifying Module Path Delays Globally

Option	Description
+/-nospecify	The specify block will be completely ignored and will not be available for SDF overrides during runtime.
-specify-zero	The result will be all specify path delays are overridden with 0 even in the presence of SDF annotations.
-specify-unit unit	The result will be all specify path delays are overridden with the unit given even in the presence of SDF annotations.

These options are available in DSim and apply to simulations of SystemVerilog components.

When actual timing values are not needed specify blocks can be ignored entirely or setup to use placeholder values.

Modifying Pulse Reject and Error Limits

Option	Description
-pathpulse	The delay model is modified to include filtering based on the $PATHPULSE settings within a specify block. If command line options pulse_e or pulse_r are also specified these shall take precedence over the $PATHPULSE values in the specify block.
+transport_path_delays	Modifies the default error and reject limits to be 0, without this option they would be the delay of the trailing edge of a pulse. Please see the Delay Model for Module Paths section for details on how this option interacts with other options.
-pulse_e percent	Sets the percent of module path delay for error limit (default: 100). If a $PATHPULSE specparam is used inside a specify block and this invocation option is used (with also -pathpulse option), then the $PATHPULSE will take precedence.
-pulse_r percent	Sets the percent of module path delay for reject limit (default: 100). If a $PATHPULSE specparam is used inside a specify block and this invocation option is used (with also -pathpulse option), then the $PATHPULSE will take precedence.

These options are available in DSim and apply to simulations of SystemVerilog components. They control how pulses are handled with respect to reject and error limits.

Full inertial pulse handling is when the reject and error limit are both equal to the delay of the trailing edge of the pulse. This is the default operating mode.

Full transport pulse handling is when the reject and error limit are both equal to 0 and all transitions/pulses are transferred to the output.

Specify spec params $PATHPULSE (used with -pathpulse option) along with other command line options allow the modification of reject and error limits. Please see the section Delay Model for Module Paths.

By default the pulses handling mode will be full inertial with the default error and reject limit equal to the trailing edge delay unless overridden with -pulse_e or -pulse_r. In this mode the $PATHPULSE specparams in specify blocks will be ignored.

Modifying Pulse Style Globally

Option	Description
-pulse_e-onevent	Indicate pulse errors on event. When a pulse (analyzed on the output) is recognized to have pulse width >= the reject limit and < error limit the output will be set to x starting at the leading edge of the output pulse (ie the delayed time of the leading edge).
-pulse_e-ondetect	Indicate pulse errors on detection. When a pulse (analyzed on the output) is recognized to have pulse width >= the reject limit and < error limit the output will be set to x starting immediately upon detection of the pulse (ie when the input changes causing the trailing edge of the pulse)

These options are available in DSim and apply to simulations of SystemVerilog components.

Pulse style invocation options (on-detect or on-event) are mutually exclusive and when specified they override the settings in the specify block.

• These options take precedence over the pulsestyle_ondetect and pulsestyle_onevent in all specify blocks.
• If there is no indication of pulse style in the specify block or the command line, the "on event" style will be used.

Handling Negative Pulses

Option	Description
-noshowcancelled	Do not show negative pulses. When a negative pulse is detected at the output it is rejected without setting the output to the error state and a warning message is issued unless -pulse_e-no-cancelled-msg is specified.
-showcancelled	Show negative pulses as X. When a negative pulse is detected at the output, the output is set to x either immediately or on event depending on the setting of the pulse style. A warning message is issued unless -pulse_e-no-cancelled-msg is specified.

These options are available in DSim and apply to simulations of SystemVerilog components.

Input pulses resulting in a negative pulse at the output can either be automatically cancelled or shown to be in the error state with the above settings.

• These options take precedence over the showcancelled/noshowcancelled in all specify blocks.
• If there is no indication of showcancelled/noshowcancelled the specify block or the command line, the "noshowcancelled" style will be used.

Managing Pulse Messages

Option	Description
-pulse_e-no-cancelled-msg	Turn off warnings when negative pulses are cancelled. By default a warning message will be printed to stderr indicating a negative pulse has been recognized and cancelled. When this option is used those messages are suppressed.
-pulse_e-no-warn-msg	Turn off warnings when pulses cause error state. By default a warning message will be printed to stderr indicating when a pulse with width >= reject limit and < error limit is recognized and set to the error state. When this option is used those messages are suppressed.

These options are available in DSim and apply to simulations of SystemVerilog components.

Standard Delay Format (SDF) Annotation

Option	Description
+/-nosdf	Run-time option to disable $sdf_annotate calls.
+multisource_int_delays	Run-time option to turn on interconnect multi-source delays causing INTERCONNECT paths to behave like module paths (ie IOPATH) including pulse handling. If not specified, INTERCONNECT constructs will be handled like PORT connections and will be more efficient.
-sdf-verbose	Run-time option to log all SDF annotation errors. Without this option only the first 10 SDF errors of the same type will be logged.

These options are available in DSim and apply to simulations of SystemVerilog components when SDF annotations are provided.

SDF annotation is on by default and will log errors to the log file specified in the $sdf_annotate call. If no log file is given, it will use file name sdf.log.

Controlling Timing Checks

Option	Description
+/-notimingchecks	Compile-time option to not include timing checks. The timing checks are not evaluated and are not available for SDF annotation. Delayed signals provided to $setuphold or $recrem are driven with 0 delay to the base signal.
+/-nonegtchk	Compile-time option to set negative limits to 0 and disable the NTC algorithm's calculation of delayed signals. Delayed signals provided to $setuphold or $recrem are driven with 0 delay to the base signal.
+/-ntcnotchk	Compile-time option to disable timing checks, howeverthe NTC algorithm will calculate the delays. Those timing checks that could contribute to the delay calculation remain enabled and are available for SDF annotation. Delayed signals provided to $setuphold or $recrem are driven with the NTC calculated delay to the base signal.
+/-nonotifier	Run-time option to disable notifier signal toggling by timing checks.
+/-no_tchk_msg	Run-time option to suppress timing violation messages. Note that the timing checks are still evaluated. Delayed signals provided to $setuphold or $recrem are driven with the NTC calculated delay to the base signal.
+/-tchk_msg_start time	Run-time option to start reporting violations no earlier than time. Note that the timing checks are always evaluated prior to the time, but violation reports are suppressed. In the absence of this option, the behaviour corresponds to -tchk_msg_start 1. time is a mandatory argument. It consists of a number and an optional time unit, e.g. "100ms". If no time unit is given, then the global time precision is assumed. Design teams may want to consider suppressing the violation reports till the device reset.
-timingcheck-specs file	Enable/Disable timing check at a specific scope using a specification file. See Setting Options by Scope Using Specification File for file details and examples.

These options are available in DSim and apply to simulations of SystemVerilog components.

By default, the timing checks are enabled and may be overridden with SDF annotation. The Negative Timing Check (NTC) algorithm to calculate delays is enabled as well.

User may improve efficiency by specifying either -notimingchecks or -nonegtchk option.

Delay Mode Controls

Option	Description
+delay_mode_zero	Compile time option to turn off distributed delays (associated with nets, gates, switches, UDPs, and continuous assignments). It also disables and removes module path delays and timing checks.
+delay_mode_unit	Compile time option to overwrite nonzero distributed delays by 1 precision time unit. It also disables and removes module path delays and timing checks.
+delay_mode_path	Compile time option to overwrite all distributed delays by 0. Only module path delays are in effect.
+delay_mode_distributed	Compile time option to disable and remove all path delays. Only distributed delays are in effect.

These options are available in DSim and apply to simulations of SystemVerilog components.

The user may specify the delay mode through the above command line options and/or compiler directives of the same name. Note that the above command line options are mutually exclusive. The command line option acts as if it is the first compiler directive in the topmost source file. A subsequent delay mode directive supersedes the current one.

When running with SDF, consider the effect of setting the delay mode. If the constructs are removed as indicated above, they will not be available for SDF to override. The +nosdf option can be used to disable SDF if needed.

Combinational Glitch Removal

Option	Description
-opt-comb-glitch	Enable combinational glitch mitigation

These options are available in DSim and apply to simulations of SystemVerilog components.

RTL code often uses a coding style intended to avoid inadvertent latch inference:

 

    always @* begin
        x = 0;
        y = 0;
        if (a) x = 1;
        if (b) y = 1;
    end

 

In the event that b rises while a is already high, a glitch will be created on x as it is set to 0 and then immediately set to 1. Strictly according to the SV-LRM this glitch must be produced, as other processes may be sensitive to it. However, it is possible to code simulation logic loops by creating two blocks sensitive to each other's glitches. This style may not result in an actual combinational loop during synthesis, and it may not cause a simulation loop on other simulators, depending on how the tools optimize and schedule the processes. For the benefit of users migrating from other tools with legacy code that causes a simulation loop due to this coding style, the option -opt-comb-glitch will enable a transform that suppresses some of these glitches. The resulting simulation will not be SV-LRM compliant, and may break conformant code, but it may also allow non-conforming legacy code to simulate properly.

SV-LRM Reference: 4.9.3 second paragraph, in the case where no delay is specified.

Other Run-Time Options

Option	Description
-run-until time	Specify end time. The end time consists of a number and optional time unit, e.g. "100ms". If no time unit is given, then the simulation time precision is assumed.
-heartbeat N	Specify heartbeat log message interval.
-linebuf	Force line-buffered output (default).
-no-linebuf	Do not force line-buffered output. Potential speedup for verbose simulations.
-sv_seed n	Specify n as the SystemVerilog random seed. n may be an arbitrarily large hexadecimal number, or 'random' to select a random seed. (default seed=1, if not used)
-reseed t=n	Specify time t to reseed the SystemVerilog randomization with seed n.
-override-finish-completion n	Specify an override value to use for all $finish ( and $stop and $fatal) calls to control the diagnostic information produced. Only 0, 1 or 2 is permitted.
-cov-db	Specify file to write coverage database. (default: metrics.db)

These options are available in DSim and apply to the simulation.

The -heartbeat option, if given, causes a message to be printed to simulation output each time the specified interval elapses. It provides a good way to track performance of the simulation and to ensure that a simulation is not "hung" when it gets to a point where the testbench does not output anything.

By default, most simulation output goes to the log file as well as stdout, and certain error messages go to the log file as well as stderr. If stdout and stderr are connected to a Linux terminal window then any buffering on those channels is flushed at the end of each line of output. However, if stdout is redirected to a file, then the buffering is flushed:

• at the end of each line of output, whenever -linebuf is in effect. If both stdout and stderr are redirected to the same file, then their relative order is preserved. Note that enabling -linebuf may impact the performance, in particular for verbose simulations.
• only when the internal buffer gets full, whenever -no-linebuf is in effect. If both stdout and stderr are redirected to the same file, then output from one may be arbitrarily reordered with respect to the other due to the differences in buffering. This is standard Linux behavior. Note that enabling -no-linebuf may improve the performance, in particular for verbose simulations.

IO Tracking

Option	Description
-io_dir	Specifies a path to record all files read and written to by each executable in the DSim product family

When developing a MDC Cloud regression flow it is useful to understand what files are required AND produced by the different tools in a DSim product flow. When activated a report will be generated for the specified executable, as well as any others that are executed within the same process.

The reports will list each category of file or directory as well as their path and will separate them into either inputs or outputs. All reports will have the .io file extension.