Design Elaboration

Elaboration is the process that occurs after the code is parsed. From one or more starting points, called tops, all instances have their designs computed, parameters and other constants get their values, generate constructs are instantiated and port connections are established.

In the project build config file, specify the elaboration top(s) with one or more -top top_name directives.

E.g.

work.elem_name - from the specified library, the SystemVerilog *module*, SystemVerilog *configuration*, VHDL *entity* or VHDL *configuration* is set as the top

elem_name - all libraries are searched for the design element and the first found is set as top

elem_name:config - the configuration specified is the top, even in the case of a name collision with either a SystemVerilog module or a VHDL entity

If no directive is used, then the elaboration is preceded by a top candidates search through all the designs. A UNSPECIFIED_TOP warning is also displayed in the Console View to mark the absence of any chosen top design.

Note

SystemVerilog modules can be instantiated by a VHDL entity and vice versa. You can also specify design tops from either language.

Top candidates

When no top design element is specified in the project build config file, then any design element that satisfies the following requirements is considered a top:

  1. The design element is either a SystemVerilog module, a SystemVerilog program, a VHDL entity or a VHDL configuration. Do note that a SystemVerilog configuration cannot be a candidate.

  2. The design element is not instantiated anywhere. Even instantiations under inactive generate constructs are considered and rule out the element in question.

  3. Customizable: The design element has sub-instances or local generate constructs. This requirement can be disabled by specifying in the project build config the following directive: +dvt_enable_elaboration_empty_tops+true.

As mentioned before, a mixed-language project can have any combination of SystemVerilog, SystemVerilog or VHDL top candidates.

Parameter values

During elaboration, parameters (or generics in VHDL) get their values computed. The following sources, ordered by importance, are searched:

  • Configuration overrides. Any override of a parameter in a SystemVerilog config or a VHDL configuration rule is considered first.

SystemVerilog
config cfg;


instance top.inst use amod #(.PARAM(1))


endconfig
VHDL
configuration cfg of top_entity

for rtl


  for inst : aent use entity work.aent
    generic map (PARAM => 1);
  end for;



end for;

end configuration;
  • Defparam assignments

SystemVerilog
defparam top.inst.PARAM = 1;
  • Instantiation overrides

SystemVerilog
amod #(.PARAM(1)) inst();
VHDL
inst : entity work.aent
      generic map (PARAM => 1);
  • Default values

SystemVerilog
parameter int PARAM = 1;
VHDL
generic (PARAM : integer := 1);

The computed value can be seen in the parameter tooltip.

../../_images/elab-an-tooltip.png

The Inspect View will also show it, alongside number base conversions.

../../_images/elab-an-inspect.png

To easily jump to the driver or source of the parameter value, you can use the Jump To Assignment hyperlink.

../../_images/elab-an-jump-part1.png
../../_images/elab-an-jump-part2.png

Note

The current design path, shown in the Design Breadcrumb, is used for determining the instance to which the inspected parameter belongs.

Unelaborated Design

The unelaborated design is the part of the compiled code not found under any of the elaboration tops. It can divided into two categories:

  1. Inactive generate constructs: e.g. the else branch of an if generate, all inactive case items, for loop generates with no iterations

  2. Design elements not instantiated under the elaboration tops: unused interfaces, the design of an instance under an inactive generate construct

Unelaborated modules/programs/interfaces/checkers/entities are marked with warnings. Also, packages that are not used in the elaborated design are marked with UNELABORATED_PACKAGE warnings.

Tool functionality in the unelaborated part of the design can be restricted through the +dvt_unelaborated_compile_checks All Build Directives. A faster build time is the main benefit. But, the tradeoff is the loss of all IDE specific functionality, like for example Show Usages, Readers or Writers, Rename Refactoring, or Design Diagrams, in the excluded code.

Debugging

Debugging the elaboration is possible through the +dvt_elaboration_debug global build config directive. Its output is shown in the project DVT Console/build log. It accepts multiple argument values:

E.g. +dvt_elaboration_debug+STATS+EVAL

STATS

enables various statistics, e.g. number of elaborated instances, number of defparams found

MEMORY

the elaborated hierarchy, both designs and parameter values, is listed

EVAL

internal unsuccessful evaluations are marked with an UNKNOWN_EXPRESSION error that appears also in the Problems View

INCREMENTAL

additional information regarding incremental adaptive elaboration is shown

BINDS_PASS

additional information regarding the elaboration of bind directives is shown

SUBINSTANCE_COPIES

additional information regarding the SINGLE_PASS elaboration of sub-instances that get copied

Performance

The following build config directives can restrict the elaboration and therefore improve performance when needed.

+dvt_elaboration_control

Disable or change steps in the elaboration.Use EACH_GENERATE_BLOCK_ONCE to elaborate each generate block, whether active or inactive, only once.

All branches of conditional generate blocks will be elaborated. Loop generate blocks will be elaborated only once, for index 0.

Similarly, an array of instances will have only one element per dimension, corresponding to index 0.Use NO_GENERATE_BLOCKS to not elaborate generate blocks.

Any sub-instance found under a generate block will also not be elaborated.Use NO_PARAM_EVAL to disable parameter evaluation. Parameters and constants will not have their values computed, not even their default values.

Use EACH_SPEC_ONCE to stop the SINGLE_PASS elaboration of an instance whose design specialization has already been elaborated (the instance is BBOX-ed). Use NO_SUBINSTANCE_COPIES to not optimize the SINGLE_PASS elaboration through copies of identical sub-instances.

E.g. +dvt_elaboration_control+NO_GENERATE_BLOCK_EVAL+NO_PARAM_EVAL

+dvt_elaboration_loop_block_cutoff

Configure the cut-off number for elaborated loop blocks.In a design with many loop generate constructs, limiting the number to 1 per loop can drastically reduce the elaboration time.

E.g. +dvt_elaboration_loop_block_cutoff+1 (default: 200)

+dvt_elaboration_loop_statement_cutoff

Configure the cut-off number for elaborated function loop statements.In a design with many evaluated functions, limiting the number to 100 per loop statement (e.g. for, foreach, while) can drastically reduce the elaboration time. Functions affected by the cutoff are not elaborated.

E.g. +dvt_elaboration_loop_statement_cutoff+100 (default: 1000)

+dvt_elaboration_kind

Configure the kind of elaboration performed at full build.Use SINGLE_PASS to have the elaboration be performed in one pass.

A notable performance improvement can be observed but note that any usage of defparam assignments or configurations may lead to unexpected elaboration results.Use MULTI_PASS to have the elaboration use multiple passes. In most cases it is slower than the SINGLE_PASS elaboration, but ensures correct handling of defparam assignments and configurations.Use ADAPTIVE to let the tool determine the kind based on multiple criteria.

E.g. +dvt_elaboration_kind+SINGLE_PASS (default: ADAPTIVE)

+dvt_elaboration_max_nof_resolve_binds_passes

Configure the maximum number of passes allowed when resolving bind directives.

E.g. +dvt_elaboration_max_nof_resolve_binds_passes+1 (default:5)

+dvt_elaboration_disable_method_eval

Disable function call evaluation in elaboration.

E.g. +dvt_elaboration_disable_method_eval+true

+dvt_elaboration_skip_defparams

Skip defparam assignments during elaboration.

E.g. +dvt_elaboration_skip_defparams+true

+dvt_elaboration_skip_modules

Skip elaboration of an instance based on design name.Instance port connections and parameter overrides are not checked and sub-instances are not elaborated.

Skipped designs are considered unelaborated.Elaboration tops cannot be skipped.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_skip_modules+*amod*

+dvt_elaboration_skip_paths

Skip elaboration of an instance based on design file absolute path.Instance port connections and parameter overrides are not checked and sub-instances are not elaborated.

Skipped designs are considered unelaborated.Elaboration tops cannot be skipped.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_skip_paths+/home/user/dvt_project/rtl/*

+dvt_elaboration_skip_instances

Skip elaboration of an instance based on hierarchical path.Instance port connections and parameter overrides are not checked and sub-instances are not elaborated.

Skipped designs are considered unelaborated.Elaboration tops cannot be skipped.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_skip_instances+top.dut.*

+dvt_elaboration_bbox_modules

Black box an instance based on design name.Instance port connections and parameter overrides are checked but sub-instances are not elaborated.

Black boxed designs are considered unelaborated. In the Design Hierarchy View, they are marked as BLOCK BOX.Elaboration tops cannot be black boxed.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_bbox_modules+*amod*

+dvt_elaboration_bbox_paths

Black box an instance based on design file absolute path.Instance port connections and parameter overrides are checked but sub-instances are not elaborated.Black boxed designs are considered unelaborated.

In the Design Hierarchy View, they are marked as BLOCK BOX.Elaboration tops cannot be black boxed.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_bbox_paths+/home/user/dvt_project/rtl/*

+dvt_elaboration_bbox_instances

Black box an instance based on hierarchical path.Instance port connections and parameter overrides are checked but sub-instances are not elaborated.Black boxed designs are considered unelaborated.

In the Design Hierarchy View, they are marked as BLOCK BOX.Elaboration tops cannot be black boxed.Wildcards such as ‘*’ (any string) and ‘?’ (any character) can be used in the pattern.

E.g. +dvt_elaboration_bbox_instances+top.dut.*

The following build config directives can restrict the functionality in the unelaborated code in order to improve performance.

+dvt_unelaborated_compile_checks

Control the scope of the unelaborated design build checks and functionality.

If set to NONE, functionality and checking in the unelaborated modules and unelaborated local generate blocks is limited.

If set to GENERATE_BLOCKS, functionality and checking in all unelaborated modules is limited.

If set to DISCRETE, functionality and checking in the unelaborated modules found in library files is limited. This is the default value of the directive.If set to FULL, functionality and checking is not limited in the unelaborated code.

E.g. +dvt_unelaborated_compile_checks+GENERATE_BLOCKS

+dvt_unelaborated_disable_package_constants

Disable unelaborated package constants evaluation and checking.

E.g. +dvt_unelaborated_disable_package_constants+true