DVT SystemVerilog IDE User Guide
Rev. 24.1.15, 10 July 2024

41.5 Encrypted VIP Support

The DVT compiler safely skips encrypted regions of code. Ideally VIP source code should be compiled without errors by any third party tools. However, some VIPs may not be properly encrypted, and lead to false errors. Most of the time this happens due to:

  • Asymmetric encryption - for example when endmodule or endif is inside the encrypted code while the corresponding module or ifdef is outside the encrypted region. In this situation DVT may signal errors for mismatched language tokens, for example "Unexpected token 'endmodule'". Furthermore some of the types may end up being compiled in the wrong scope altogether.

  • Public encrypted API - for example when the definition of a macro, class, or function is encrypted while still being referenced outside the encrypted region.

Note: How come a simulator works fine in such cases? Because as simulator decrypts the code if you have the proper licenses.

To restore full or partial functionality you can employ one or more of the following solutions:

  • Kindly ask the VIP provider to fix the encryption issues. The SystemVerilog language provides dedicated constructs for this type of encapsulation, such as forward typedefs and extern methods placed in non-encrypted header files.

  • Instruct DVT to automatically close scopes in encrypted files. The automatic closing of scopes will take place in all files that contain encrypted code and whose full path matches the provided pattern.


  • Instruct DVT to automatically define non-existing API. These functions and fields that are accessed within the specified files will be automatically defined with the appropriate signature.

The definition will be placed in the closest scope which is defined in a file containing encrypted code.


Macros whose name matches the macro regular expression are automatically defined at project level.


Note: All +dvt_encrypted_code_auto inclusion directives are applied first, followed by the exclusion (_not) patterns. Any number of such directives can be specified. The directives are global.

  • Particularly for Synopsys encrypted VIPs, instruct DVT to load a predefined set of macro definitions and waivers using the following directives:

+dvt_auto_snps_vip_macros Generate and load in each invocation .dvt/auto_snps_vip_macros.svh file. It contains dummy definitions for macros which are commonly used but not defined or encrypted in Synopsis VIPs.
+dvt_auto_snps_vip_waivers Generate and load .dvt/auto_snps_vip_waivers.xml file. It contains waivers for problems commonly encountered when working with encrypted Synopsis VIPs.

  • As a last resort, you can manually fix the encryption

The encrypted code can be fixed on a case by case basis, for example by adding the missing endmodule, endclass, `endif etc, declaring dummy prototypes of the missing API (classes, functions, fields and so on).

To avoid changing the original files, you will have to substitute the original broken files with the fixed ones.

  • Start by choosing a suitable directory to store the DVT substitute files. Often, they can be used across projects, so the directory should be outside of any DVT project directory in particular. You can define an environment variable to point to the chosen directory, like $DVT_FIXES.

  • For every file that needs to be fixed do:

    • Copy the file to $DVT_FIXES as is.

    • Modify $DVT_FIXES/file with the necessary fixes.

    • Tell DVT to use $DVT_FIXES/file as a substitute to file. This means adding to the default.build the following build directive: + dvt_file_substitute+/path/to/file=$DVT_FIXES/file

Having done the above, DVT will use the substitute files and offer valuable functionality, like hyperlinks, type hierarchy, references in the now correctly compiled code.

Note The + dvt_file_substitute directive accepts only absolute paths as arguments. Environment variable can be used to define the absolute paths. Regular expressions are not supported.