Using multi-step mode with the Xcelium requires three main steps:

    xrun -compile <other_options> <source_files>
    This step will parse and compile the specified source files.
    xrun -elaborate <other_options>
    This step will elaborate the design and generate the snapshot.
    xrun -R <other_options>
    This step simulates the snapshot.

1.xmvlog

2.xmelab

• [-sdf_verbose]

 Include detailed information in the SDF log file.

By default, Xcelium Simulator generates a log file name that is based on the compiled SDF file name with the following syntax: < COMPILED_SDF_FILE >_sdf_annotation.log. You can specify a custom name for the SDF log file by adding the log_file argument to the $sdf_annotate system task or by using the LOG_FILE statement in an SDF command file. 

Note: Data that corresponds to protected regions in the file will not be included in the log file.

• [-nonotifier]

Ignore notifiers in timing checks. x-state will not be propagation if happen timing violation.

• [-mindelays/-typdelays/-maxdelays]

For example: -maxdelays 

Apply the maximum delay value from a timing triplet in the form min:typ:max that appears in a specify block in the Verilog description.

This option also selects the maximum delay value if the min:typ:max value appears in the SDF file while annotating to Verilog or to VITAL unless an SDF-specific construct is used to override it. For example, if you use -maxdelays on the command line, but specify MINIMUM in an SDF command file (MTM_CONTROL = "MINIMUM"), in an SDF configuration file (MTM = MINIMUM;), or in the $sdf_annotate task, the maximum values in the specify block will be used. 

• [-sdf_nocheck_celltype]

Disable celltype validation(确认) between the SDF annotator and the Verilog description. By default, the annotator checks the type that is specified in the CELLTYPE construct against the module name in the description. If there is a mismatch, a warning is generated and no annotation to that module instance is performed.

• [-sdf_nopulse]

Ignore pulse reject and error limit specifications in an SDF file.

Path pulse reject and error limits can be specified in an SDF file in IOPATH, PATHPULSE, or PATHPULSEPERCENT statements. Use the -sdf_nopulse option if you want to ignore the path pulse information in an SDF file.

Path pulse information specified in PATHPULSE$ specparams in specify blocks will be used. You must include the -pathpulse option to enable PATHPULSE$ specparams. If path pulse limits are not specified in a specify block, they are calculated based on the global reject/error limits, which can be specified on the command line with the -pulse_r, -pulse_e, -pulse_int_r, and -pulse_int_e options

• [-pathpulse]

You can override global pulse control for module paths(pulse_r and pulse_e) by declaring PATHPULSE$ specparams in specify blocks. The PATHPULSE$ specparam narrows the scope of module path pulse control to a specific module or to particular paths within modules. 

Enable PATHPULSE$ specparams, which are used to set module path pulse control on a specific module or on specific paths within module.

specify
    (clk => q) = 12;
    (data => q) = 10;
    (clr, pre *> q) = 4;
specparam
    PATHPULSE$ = 3;
    PATHPULSE$clk$q = (2, 9);
    PATHPULSE$clr$q = 1;
endspecify

 In this example:

The second PATHPULSE$ specparam sets a reject limit of 2 and an error limit of 9 for the path (clk=>q) . 

The first PATHPULSE$ specparam sets reject and error values of 3 for the path (data=>q) .

The following example illustrates how to use PATHPULSE$ specparams to set path pulse controls on specific paths. You must use the -pathpulse option when you elaborate this design

Standard Delay Format (SDF) annotation can provide new values for pulse limits of both module path delays and interconnect delays. This annotation method operates independently of the PATHPULSE$ specparam construct, and the -pathpulse option is not needed when pulse control values are provided by SDF annotation. 

• [-pulse_r reject_percent， -pulse_e error_percent， -pulse_int_r reject_percent and -pulse_int_e error_percent]

 Use the -pulse_r and the -pulse_e options when you invoke the elaborator to set global pulse control. These options set global pulse limits for both module path delays and interconnect delays.

If you want to set pulse control for module path delays and interconnect delays separately in the same simulation, use the following two sets of options:

    -pulse_r and -pulse_e to set limits for path delays
    -pulse_int_r and -pulse_int_e to set limits for interconnect delays

By setting a global pulse control, you tell the simulator to take one of the following actions:

Reject the output pulse (the state of the output is unaffected),  Reject if 0 <= pulse < (reject limit)..

Filter the output pulse to the error state. This generates a warning message and then maps to the x state,Set to error if reject limit <= pulse < (error limit). 

Let the output pulse through (the state of the output reflects the pulse), Pass if pulse >= error limit.

Note: Pulse widths are measured at the output, not at the input.

 Example:

This example shows how to use the -pulse_r and -pulse_e options to set global path pulse control. In this example, module path delay = 50 time units.

% xmelab -pulse_r 60 -pulse_e 90 hardrive

In this example, a module path delay of 50 time units has a reject limit of 30 time units (60% of 50 time units). The error limit is 45 time units (90% of 50 time units).

    Pulses smaller than 30 time units are rejected.
    At 30 through 44 time units, pulses are set to the error state and then mapped to the x state.
    At 45 time units and above, pulses are passed through

• [-negdelay]

Enable adjustment of negative interconnect and module delays.

By default, the elaborator will zero out all negative delays and issue a warning. Use this option (xmelab -negdelay or xrun -negdelay) when you want to support negative delay adjustments to single-level driver and loads.

•  [-neg_tchk/-noneg_tchk]

        -noneg_tchk : Do not allow negative values in $setuphold and $recrem timing checks in the Verilog description and in SETUPHOLD and RECREM timing checks in SDF annotation

The SETUPHOLD and RECREM use of negative time specifications in these timing checks is enabled by default. Use the -noneg_tchk option when you invoke the elaborator to disallow the use of negative values. If you use this option(-noneg_tchk), negative limits are set to 0 in the description or annotation, and a warning is issued

•  [-tfile timing_file]

Use the specified timing file.

A timing file is a text file that lets you turn off timing for particular instances or portions of a design. You can use wildcard characters in the path specification of the timing file to match full or partial instance names at any level. The two supported wildcard characters are:

An asterisk ( * ) that matches any instance at the current scope

Three dots ( . . . ) used as a suffix that match any instance in the hierarchy below the current scope

With the optional -tfverbose argument, you can enable verbose mode which will print out a list of instances matched to each wildcard rule during elaboration. For example, given the following timing rule:

PATH tb.*.d* -tcheck

3.xmsim

4.others

    Get help on messages generated by the compiler, elaborator, and simulator, and by other utilities.

    Syntax:
    % xmhelp [options] tool_name message_code 

    Example:

    %xmhelp xmelab SANGL2

    xmhelp: 18.03-s004: (c) Copyright 1995-2018 Cadence Design Systems, Inc.
    xmelab/SANGL2 =
    The magnitude of the negative limit value minus the positive limit value
    in a $setuphold or $recrem timing
    check must be less than or equal to the tolerance value given by
    -ntc_tolerance option (by default, the tolerance value is 0).
    The limits will be adjusted: by default, the negative limit will bet set to 0.
    However, if -ntc_neglim is specified, the negative limit will be adjusted 
    to match the positive limit; if the -ntc_poslim is specified, 
    the positive limit will be adjusted to match the negative value.

  Options:
    -ALL <arg>                  -- Prints out the help for all tools with the given mnemonic 
    -CDS_IMPLICIT_TMPDIR <arg>  -- implicit tmpdir for reading
    -CDS_IMPLICIT_TMPONLY       -- only use implicit for reading
    -CDSLIB <arg>               -- Prints the contents of the cds.lib file(s)
    -DUMPWARN                   -- Prints out the complete list of the mnemonics for all warning messages
    -HDLVAR <arg>               -- Prints the contents of the hdl.var file(s)
    -HELP                       -- Prints this message
    -LOCKCHECK <arg>            -- Tests a file system to determine for file locking capabilities
    -NEVERWARN                  -- Disables printing of all warning messages
    -NOCOPYRIGHT                -- Suppresses printing of copyright banner
    -NOWARN <arg>               -- Disables printing of the specified warning message
    -OUTFILE <arg>              -- Dumps the mnemonics  of all the warning messages in the file 
    -TOOLS                      -- Prints out the tools for which help is available
    -VERSION                    -- Prints the version number
    -XMERROR <arg> [Deprecates: NCERROR] -- Increases the severity of a warning to an error
    -XMFATAL <arg> [Deprecates: NCFATAL] -- Increases the severity of a warn/error to a fatal

  Examples:
    -- To find help on the error CUVWSP from xmelab
       % xmhelp xmelab CUVWSP
    
    -- To find help on the error BADCLP from xmvlog
       % xmhelp xmvlog BADCLP
    
    -- To list the currently defined libraries
       % xmhelp -cdslib
    
    -- To list the currently supported tools
       % xmhelp -tools
    
    -- To list the help for all supported tools with the BADCLP mnemonic
       % xmhelp -all BADCLP
    
    -- To print out the complete list of the mnemonics for all warning messages
       %xmhelp xmelab -dumpwarn
    
    -- To dump the list of the mnemonics for all the warning messages generated by all the supported tools in the file
       %xmhelp -all -dumpwarn -outfile <filename>