How to speed-up DVT IDE build using precompiled databases

Overview

This video shows how precompiling fragments of your project can speed up build and consequently tool bring-up - especially relevant when working with large projects, for example doing integration work at SoC level.

It covers both automatic precompilation which you can easily apply to your project to get immediate benefit as well as full-scale deployment: create and update the precompiled databases in batch mode as part of a CI/CD fully automated precompilation process, and deploy the resulting artefacts in a shared location where they can be referenced by teams across the entire organization.

The user-guide provides comprehensive information, including recommended best practices and a configuration skeleton to build upon:
https://eda.amiq.com/documentation/eclipse/sv/toc/application-notes/precompilation.html

This video was shot using version 25.1.3 of the DVT IDE for Eclipse. The functionality is identical in the DVT IDE for VS Code.

Details

Introduction

Working with large projects in DVT IDE, for example doing integration work at SoC level, can be just as smooth and swift as working with a single IP. After all, you typically work only within a small part of the code, while design files or verification IPs are mostly unchanged. Compiling everything from scratch leads to a lengthy build time which in turn impacts both the initial bring-up and subsequent full builds.

Pre-compling fragments of your project is key to bringing down build time. The build configuration of SoCs is usually split into several +dvt_init sections, each corresponding to a simulator invocation in a multi-step compilation flow and typically mapped to distinct worklibs.

Automatic precompiled databases

To see immediate benefit from DVT precompilation, simply add to your build configuration the +dvt_precompiled_db_auto directive followed by a save location. The very first time you build the project, each +dvt_init section gets saved as a pre-compiled database. Subsequent builds will load the pre-compiled fragments from disk instead of reanalyzing the source files, leading to a significantly improved build time.

Moreover, DVT automatically keeps the precompiled databases up-to-date if source code changed since the last build.

It is recommended to disable automatic precompilation for those init sections containing files that are constantly modified - for example the testbench top where you are integrating other IPs. You can either do this by worklib name, or per init section.

Full-blown deployment: CI/CD integration

The next step up is a fully blown integration of precompilation into your flows: prepare precompiled artefacts in advance, perhaps in your CI/CD pipeline, in order to get speed-ups from the very first build.

First, you have to create build configuration files for the project fragments you decide to precompile, typically each containing one or more +dvt_init sections and the +dvt_precompiled_db_save directive specifying the location where the database shall be stored after build.

Next, refactor the project build configuration to first load the saved databases instead of explicitly specifying the files for compilation. The files you are actively working on must be specified last, in separate +dvt_init sections.

Of course you will most likely create and update the precompiled databases in batch mode, using $DVT_HOME/bin/dvt_build.sh, as part of a fully automated precompilation process, and deploy the resulting artefacts in a shared location where they can be referenced by teams across the entire organization.

You can seamlessly browse and navigate around the project, for example in DVT views or diagrams, even if precompiled source files are not available at load time. DVT will automatically pick up the source files if they're exactly in the same location as when pre-compilation was performed. If not, for example when files are checked out to a user-specific location from a version control system, you can use this dedicated directive to remap their paths: +dvt_precompiled_db_src_map.

Ultimately, for maximum benefit, you can combine the presented approaches and tune to the specifics of your project. The user-guide provides comprehensive information, including recommended best practices and a configuration skeleton to build upon.