Compilation Speed-up

Several DVT directives can optimize build times by either condensing the scope of the full build analysis or by restricting certain features within specific code segments.

This application note addresses questions related to performance, specifically regarding the duration of the full build process and the amount of memory used.

How to exclude files from compilation?

You can achieve this by using the +dvt_skip_compile directive.

This allows DVT to bypass specific files completely during build.

Benefits of this approach include reduced build times and lower memory usage.

However, this may lead to false errors when DVT does not compile definitions for certain types (such as classes, modules, typedefs, etc.). To address these errors, you may need to use Compile Waivers.

The directive is available in multiple variations:

  • +dvt_skip_compile+<simple_pattern>

  • +dvt_skip_compile+not+<simple_pattern>

  • +dvt_skip_compile+regex+<regex_pattern>

  • +dvt_skip_compile+regex+not+<regex_pattern>

For simple patterns, wildcards like * (to match any sequence of characters) and ? (to match a single character) are available. The provided patterns are matched against file absolute paths.

Examples

To exclude every file located within the /dir1/ directory
+dvt_skip_compile+*/dir1/*
To exclude everything but files within the /dir1/ directory
+dvt_skip_compile+not+*/dir1/*

To exclude files in both the /dir1/ and /dir2/ directories, you have two options. You can sequentially use two directives:

+dvt_skip_compile+not+*/dir1/*
+dvt_skip_compile+not+*/dir2/*

Alternatively, you can achieve the same effect with a single regular expression directive:

+dvt_skip_compile+regex+not+(.*/dir1/.*|.*/dir2/.*)

This approach allows you to tailor the compilation process precisely, ensuring that only the desired files are compiled, thereby reducing build time and memory usage.

Note

If +dvt_skip_compile+not is the first skip directive DVT encounters, it automatically assumes that a +dvt_skip_compile+ directive has been applied beforehand.

Note

The +dvt_skip_compile directive affects only the +dvt_init section it resides in. To extend the same skip compile directives to every +dvt_init section, you should employ the +dvt_prepend_init directive.

+dvt_prepend_init
+dvt_skip_compile+*/dir1/*

+dvt_init
... build configuration directives ...

+dvt_init
... build configuration directives ...

The order of skip compile directives dictates the selection of files to bypass during compilation. Thus, employing the setup below leads to the exclusion of all files in the dir1 directory, aside from those in the dir1/dir2 subdirectory.

+dvt_skip_compile+*/dir1/*
+dvt_skip_compile+not+*/dir1/dir2/*

Skipped files are decorated distinctively in the Navigator View / Explorer View.

DVT Eclipse:

../../_images/dvt-ignore-file-indication.png

DVT for VS Code:

../../_images/dvt-vscode-ignore-file-indication.png

How to exclusively compile the API?

Shallow compilation can be used to speed up full build in scenarios where you’re working with third-party IPs or internal code that doesn’t change.

It instructs DVT to partially parse the code, focusing on the API and bypassing the details.

This means, for example, that within modules, it will only analyze ports and parameters, and for functions and tasks, solely the signature (arguments and their types).

This strategy of partial parsing through shallow compilation leads to significant improvements in efficiency, reducing both the duration of builds and the demand on memory resources. Obviously, the optimization gains from shallow compilation are not as substantial as those offered by the +dvt_skip_compile directive. However, modules and functions are included in the Autocomplete suggestions, features such as “Open Declaration” hyperlinks function correctly, and perhaps most crucially, it does not introduce new errors, eliminating the necessity for Compile Waivers. This ensures a smoother coding experience, with essential code navigation and completion features readily accessible without the complication of additional errors, like NON_EXISTING_* or UNDECLARED_* errors which may appear when using +dvt_skip_compile directive.

To enable the shallow compilation, use the following directive:

+dvt_shallow_compile+<scope>[+not|+regex|+regex+not]+<pattern>

Within this structure, <scope> can be any of the following:

  • FILE : All the modules and functions in files whose absolute paths match the specified <pattern> will be shallow compiled.

  • MODULE : All modules with fully qualified names that match the specified <pattern> will be shallow compiled.

  • FUNCTION : All functions with fully qualified names that match the specified <pattern> will be shallow compiled.

This directive grants precise control over shallow compilation’s scope, enabling the selective application to files, modules, or functions based on their specified names or paths.

A fully qualified name is defined by its encompassing hierarchical scope path. For instance, consider a function named foo located within my_class, which resides in my_pkg; the fully qualified name would be my_pkg::my_class.foo.

For simple patterns, wildcards like * (to match any sequence of characters) and ? (to match a single character) are available.

The order of shallow compile directives dictates which modules or functions are to undergo shallow compilation. Thus, employing the setup below leads to the shallow compilation of all functions in the my_pkg package, aside from those that contain my_func in their fully qualified name.

+dvt_shallow_compile+FUNCTION+my_pkg::*
+dvt_shallow_compile+FUNCTION+not+*my_func*

Note

If +dvt_shallow_compile+not* is the initial shallow directive DVT encounters, it automatically assumes that a +dvt_shallow_compile+FILE+* directive has been applied beforehand.

Note

The +dvt_shallow_compile directive affects only the +dvt_init section it resides in. To extend the same skip compile directives to every +dvt_init section, you should employ the +dvt_prepend_init directive.

+dvt_prepend_init
+dvt_shallow_compile+MODULE+*

+dvt_init
... build configuration directives ...

+dvt_init
... build configuration directives ...

Examples

Shallow compile everything

+dvt_shallow_compile+FILE+*

Shallow compile the entire design except the testbench top

+dvt_shallow_compile+MODULE+*+dvt_shallow_compile+MODULE+not+fully_qualified_name_of_tb_top

Shallow compile a specific portion of the project - all files that meet a certain pattern

+dvt_shallow_compile+FILE+*pattern*

Shallow compile all functions within a given package

+dvt_shallow_compile+FUNCTION+vip_pkg::*

Shallow compile everything but exclude a specific package

+dvt_shallow_compile+FILE+*+dvt_shallow_compile+FUNCTION+not+compiled_pkg::*

Visual indicators are added in multiple places:

A notification at the top of the editor

../../_images/shallow_editor_notification.png

Not available in VS Code

An “[S]” indicator in the views: Compile Order, Types, Design Hierarchy, Verification Hierarchy

../../_images/shallow_compile_order.png
../../_images/shallow_design_hierarchy.png

An “[S]” indicator in the diagrams: Schematic Diagrams, UVM Component Diagrams

../../_images/shallow_schematic.png

A “(shallow)” indicator in the Console View during full build

../../_images/shallow_build_message.png

Note

Instances of modules or UVM components that have been shallow compiled will not have any children nodes in Design Hierarchy and Verification Hierarchy VIew.

Note

Some features may not be fully operational within the shallow compiled sections of code. For example, refactoring a class variable name will not change its references within a shallow compiled function. Similarly, showing the usages of a package parameter will not show its usages within a shallow compiled module. Any references in non-shallow compiled code will work as expected.

How to improve the elaboration time?

To improve the elaboration time, you can configure it with the directives found in the Elaboration Debugging documentation page.