Incremental Compilation

When something changes in your code, the DVT compiler updates the project database by analyzing the impact of your specific change across the entire project.

This is called incremental compilation. Instead of waiting to recompile the entire project, you get instant feedback about the change. Any errors are flagged as you type, for example if you are using the wrong syntax, if you have a typo, or if some data types are mismatched.

This way the compile & fix cycles are significantly cut down. As the project database is properly updated on every change, the DVT functionality is accurate (hyperlinks, auto-compete, refactoring, diagrams, etc.).

The DVT incremental compiler is triggered in 3 situations:

When you save a file.
When the inactivity timeout is reached, by default 5 seconds after you stop typing inside a DVT source code editor.
When changes made outside DVT are detected, for example after a revision control system related operation which leads to code updates.

Note

The Build Automatically inactivity timeout can be modified from the Window > Preferences menu, then DVT > Build Configurations > General.

../../_images/build_automatically_preference.png

Note

The incremental compilation can be disabled if you go to the Project menu and uncheck Build Automatically. However, we strongly recommend not working with the incremental build disabled,

since this will lead to an outdated DVT database and unreliable functionality.

DVT warns you when you’re working with the Build Automatically preference disabled and keeps track of the changes you’ve made via a notification in the top-right corner of source code editor.

../../_images/editor_notification_build_auto_off.png

Corner Case Considerations

You can rely on the DVT incremental compiler to handle the vast majority of your code changes.

However, particular types of changes have a substantial impact on the project database and the incremental compiler would take a while to do its job.

To prevent potentially disrupting your work, such changes are not processed incrementally. Consequently, the project database is not up-to-date with the code changes.

A notification in the top-right corner of the visible source code editors will inform you of such a state.

Here are some examples:

Changing the build configuration file, for example changing the value of a +define switch:

../../_images/editor_notification_modify_bc.png

Changing a file which has more than 15000 lines of code, for example editing a huge netlist:

../../_images/editor_notification_max_lines_exceed.png

You can modify the maximum number of lines threshold by adding the +dvt_incremental_compile_max_lines+<threshold> directive in the build configuration file

Changing a file which has less than 15000 lines but takes more than a configurable threshold to be parsed.

A pop-up is shown:

and the notification is displayed:

../../_images/editor_notification_incremental_timeout.png

This could happen for example when preprocessing is heavily used, and the actual amount of code to be analyzed is much bigger than the apparent length of the file.

Changing a file which leads to many database modifications, for example commenting the definition of an enum used throughout the entire testbench.

After a configurable timeout, a pop-up is shown:

If you choose to stop checking, the database remains in an inconsistent state and the notification is displayed.

../../_images/editor_notification_semantic_cancel.png

In such cases don’t hesitate to reach out, as we constantly improve the performance of our tools based on user feedback - see the Performance section below.

By default, the incremental build timeout is set to 4 seconds. When incremental build is performed on multiple files, the semantic checking timeout is increased proportionally (1 second for every 2 files)

You can modify the incremental compilation timeout by adding the +dvt_incremental_compile_timeout+<timeout> directive in the build configuration file

Changing a macro used in more than 50 files

../../_images/editor_notification_macro_change.png

Changing the design hierarchy structure so that a full elaboration is needed

../../_images/editor_notification_elab.png

When changing more than 50 files, the tool automatically triggers a full build.

Performance Considerations

We expect most common edits to be incrementally compiled in less than 500ms.

In certain situations it might happen to grow up to a few seconds, for example think about changing a SystemVerilog base class upon which all of a UVM testbench is built.

If incremental build feels slow, please report an issue using the following procedure:

add the +dvt_profile_incremental directive in the .dvt/default.build project configuration file
trigger the incremental build in the problematic context, or continue your work regularly until you feel the slowness again
every time an incremental build takes more than 2 seconds, a file named dvt_thread_dump_<timestamp>.zip should be generated under the project root
send the generated log file by submitting an How to Report an Issue?

Note

In case a thread dump file was not generated, it means that the source of slowness is elsewhere, perhaps a slow filesystem. In such a situation, please collect a thread dump and share it with us as described here: How to Report an Issue?