User Guide: DSim Setting Options by Scope Using Specification File

Modified on Thu, 11 Jul at 11:43 AM

User Guide: DSim Setting Options by Scope Using Specification File

Some features allow options to be set differently for different parts of the design by providing a specification file. The specification files for each feature will be of the same structure, however the details will be feature specific. The file will be read at either runtime or compile time depending on the feature, will have one option specification per line, and will be processed in order.

The features supporting specification files include:

wave dump scope: -wave-scope-specs file
timing checks: -timingcheck-specs file
toggle, block, and/or expression coverage: -code-cov-scope-specs file
design object visibility +acc related options: -acc-specs file

General Specification File Structure

Each line will be structured as a list of fields separated by spaces.

<spec_keyword> {depth:}<scope> <options>

Fields:

<spec_keyword> Specification level keyword (not all are supported by all features):

module (affects all instances of this type of module)
instance (affects only the specified instance and not its descendants)
path (affects the path and its descendants upto given depth if specified)
signal (affects the specific signal)

{depth:}<scope> Hierarchical path in the design

Optionally depth can be indicated for path type lines with the following format. If a depth is provided then the option will be applied to the path and "depth" levels below that path. If depth is omitted the option is applied to the full depth under the path.
scope is a string indicating the specific design component to which the options are applied.

<options> List of one or more feature specific options

Comment characters supported: # or // Commented out lines will be ignored

See feature specific examples below.

Specific Examples by Feature

Wave Dump Scope

Supported spec_keywords: instance, path, signal

Depth with the path keyword is supported

Options: +

if + the scope is added to the waves
- is not supported at this time

Run time option for example:

-wave-scope-specs wave_scope_file

With example wave_scope_file:

<div id="dump_all_of_rung0_"></div>

# dump all of rung0 
path stimulus.t_0.rung0 +

// dump rung1 only at level of rung1
instance stimulus.t_0.rung1 +

// dump rung2 and next level
path 2:stimulus.t_0.rung2 +
path stimulus.t_0.rung2.to1 +

<div id="dump_rung3_only"></div>

# dump rung3 only
path 1:stimulus.t_0.rung3 +

// a couple of signals from rung 4
signal stimulus.t_0.rung4.init +
signal stimulus.t_0.rung4.tq +

Timing Check

Supported spec_keywords: instance, path

Depth with the path keyword is supported

if + and one or more timecheck types are specified those timecheck(s) are enabled
if + and no timecheck types are specified then all timechecks specified in the design at the given scope level are enabled
if - and one or more timecheck types are specified those timecheck(s) are disabled
if - and no timecheck types are specified then all timechecks specified in the design at the given scope level are disabled

Run time option for example:

-timingcheck-specs time_spec_file

With example time_spec_file:

<div id="turn_off_rung0_and_descendants_to0_and_to1"></div>

# turn off rung0 and descendants to0 and to1
path stimulus.t_0.rung0 -$setup$hold

<div id="turn_off_all_timing_specs_for_rung1_to1_only_"></div>

# turn off all timing specs for rung1.to1 only 
instance stimulus.t_0.rung1.to1 -

// turn off rung2 and descendants then turn to1 back on
path stimulus.t_0.rung2 -$setup$hold
path stimulus.t_0.rung2.to1 +$setup

<div id="should_turn_off_rung3_and_all_descendants_"></div>

# should turn off rung3 and all descendants 
path 0:stimulus.t_0.rung3 -$setup$hold

// should turn off rung4 at level 1 only which would not include descendants, but there are none at rung4
path 1:stimulus.t_0.rung4 -$setup$hold

Code Coverage Scope

The code coverage scope spec file is used for the code coverage features that are enabled and support scoping specification.

Supported spec_keywords: instance, path, signal

Depth with the path keyword is supported.

Options: +[b|t|e], -[b|e]

if + the scope is added to the code coverage features that are turned on
if +b the scope is added to block coverage
if +t the scope is added to toggle coverage
if +e the scope is added to the expression coverage
A scope can be added to multiple code coverage features at a time. E.g. '+te' or '+et' will add the scope to both toggle and expression coverage.
if - the scope is removed from the code coverage features that are turned on and support removal
if -b the scope is removed from block coverage
if -e the scope is removed from expression coverage
A scope can be removed from multiple code coverage features at a time. E.g. -eb or -be will remove the scope from both block and expression coverage
Toggle coverage does not support -.

While the same file will be used for all coverage types, the keyword signal is only applicable to toggle coverage and will be ignored for block and expression coverages.

For toggle coverage, -code-cov-scope-scpec option only applies during runtime.

For block and expression coverage the '+' option, and the '+' option only, gets used during compile time to instrument coverage collection. The -code-cov-scope-specs argument can optionally be used at runtime to allow '+' and '-" entries to refine which scopes instrumented at compile time have block or expression coverage stored.

Compile and run time option for example:

-code-cov all -code-cov-scope-specs code_cov_scope_file

With example code_cov_scope_file:

<div id="instrument_block_and_expression_coverage_for_dut_and_all_levels_of_hierarchy_underneath_it_"></div>

# Instrument block and expression coverage for dut and all levels of hierarchy underneath it,
<div id="and_collect_toggle_coverage_for_all_nets_and_variables_within_dut_with_callback_permission_"></div>

# and collect toggle coverage for all nets and variables within dut with callback permission 
path top.testbench.dut +

<div id="collect_toggle_coverage_for_nets_and_variables_with_callback_permission_in_instance_a"></div>

# Collect toggle coverage for nets and variables with callback permission in instance A
instance top.testbench.A +t

<div id="collect_toggle_coverage_from_single_net_this_still_requires_that_the_net_be_given"></div>

# Collect toggle coverage from single net.  This still requires that the net be given
<div id="callback_permission_at_compile_time_signal_scopes_do_not_apply_to_expression_or_block_coverage_"></div>

# callback permission at compile time.  Signal scopes do not apply to expression or block coverage.
signal top.testbench.clk +

<div id="but_do_not_collect_block_nor_expression_coverage_for_a_particular_instance_takes_effect_during_"></div>

# But do not collect block nor expression coverage for a particular instance (takes effect during 
<div id="runtime_not_during_compile_instrumentation_"></div>

# runtime, not during compile instrumentation)
instance top.testbench.dut.a.b.c -be

Design Object Visibility

Supported spec_keywords: module, path, signal

Depth with the path keyword is not supported

Options: +[rwcbf]+

+ followed by one or more of r, w, c, b, f turns on the functionality as described with the +acc command line option
- is not supported

Compile time option for example:

-acc-specs acc_spec_file

With example acc_spec_file:

<div id="apply_acc_rb_to_my_var"></div>

# apply +acc+rb to my_var
path top.dut.my_var +rb

<div id="if_the_general_acc_cmdline_option_included_f_this_removes_f"></div>

# if the general +acc cmdline option included f this removes f
top.dut.my_var -f