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.
|
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. |
|
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. |
|
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. |
|
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. |
|
Configure the maximum number of passes allowed when resolving bind directives. |
E.g. |
|
Disable function call evaluation in elaboration. |
E.g. |
|
Skip defparam assignments during elaboration. |
E.g. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
The following build config directives can restrict the functionality in the unelaborated code in order to improve performance.
|
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. |
|
Disable unelaborated package constants evaluation and checking. |
E.g. |