42.8 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:

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

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.

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:

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

A pop-up is shown:

and the notification is displayed:

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.

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.

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

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:

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: issue report