VS Code supports automatic extension updates.
Since VS Code version 1.85, fine-grained control about which extensions to auto-update is available.
If your Extensions: Auto Update setting is set to _Selected Extensions, you can right-click the Sigasi extension in the Extensions pane and select the Auto Update option.
Doing so ensures that your Sigasi extension will be updated even when other extensions are not auto-updating.
You can reach the settings for the Sigasi extension as follows.
Open the Command Palette using Ctrl+Shift+P
Start typing and select Preferences: Open Settings (UI)
In the Search field on top, type Sigasi.
Optionally, configure the JRE location in Sigasi > Java: Path. Make sure to add the java executable name to the configured value.
First, configure the
sigasi.pathToLicense setting. It can be a local node-locked license file or a floating license server, e.g., 27000@myserver.example.com.
Alternatively, you can access the Sigasi extension settings through the Manage icon (
) in the extensions overview.
You can help improve the Sigasi extension for VS Code by enabling automatic submission of usage statistics and error stack traces through Talkback and telemetry.
More information about these features is available on the Talkback page.
Talkback is disabled by default.
To enable Talkback in the VS Code extension, enable the
sigasi.enableTalkback setting.
The messages sent to Sigasi are logged locally. You can view these messages using the Sigasi: Open Talkback Log Folder command.
Disk caching is enabled by default in the Sigasi extension for VS Code. We recommend leaving it enabled as the cache will significantly speed up the extension by preserving the state from an earlier moment.
However, if you’d like to disable it, you can turn off the
sigasi.server.caching.enableOnDiskCaching setting.
The Sigasi Visual HDL (SVH) extension will start once a .project file is detected in the root of the open folder. Make sure that you configure your license before trying to work on a project.
Follow the steps below to set up your project to be used with SVH.
Once set up, SVH will fully start, indicated by the Sigasi Logo appearing in the Activity Bar. Clicking on this item will show the Sigasi View, where you can manage your Sigasi project, view your project files and libraries, and much more.
From then on, you should use the Sigasi Projects View instead of the VS Code file explorer.
Every Sigasi project has mixed-language support.
To create a new project, use the Add Project... button in the empty Sigasi or Explorer View. Alternatively, the command Sigasi: Add Project… can be run from the command palette.
You can import a project from another tool (e.g., a Quartus project) by first it converting into an SVH project using scripts. Find the scripts and documentation at https://github.com/sigasi/SigasiProjectCreator .
The tutorial project covers most of Sigasi’s features.
Press Ctrl+Shift+P and start typing Sigasi: New Tutorial Project… to open the tutorial.
When the extension has finished building the project, you will see a number of issues for some files pop-up in the Projects View.
There will also be several errors and warnings in the status bar, which you can click to open the Problems View. Within that view, you can navigate through the error and warning markers for the project.
VHDL libraries are fully supported. For Verilog/SystemVerilog, Sigasi reuses the VHDL library concept (just work in practice) to distinguish between design files that should and shouldn’t be analyzed.
To change library mappings, you can use the right-click menu in the Sigasi Projects View and select Configure > Set Library as shown in the image below.
Then, you can select an existing library or choose New Library… to type a new library name.
Once you type a new library name, the file/folder you selected will be added to the library you created.
If you want to add a file/folder to an existing library, you can choose one of the existing ones from the list (such as work).
If you want to exclude files/folders from a Sigasi project, select Exclude from Build.
Note that the excluded resource(s) will still be visible in the Sigasi Projects View, and you can still add them (Set Library) to the project.
Creating new libraries, adding a file/folder to an existing library, or excluding files/folders from the build will modify your project’s .library_mapping.xml file.
To change the VHDL or Verilog version, right-click on a project, folder, or file in the Sigasi Projects View and click Configure > Set Language Version.
Then, select whether you want to set the VHDL or Verilog version. If you only see one of the two, you might need to add language support through Configure > Add [VHDL / Verilog/SystemVerilog] Support. Be sure to select the version you want.
Linked resources are a convenient way to link to a file/folder in the Sigasi ecosystem. They work without having to create symlinks or copy content.
To add a linked resource, you can right-click on the node where you want to add it, then click Add Linked File/Add Linked Folder. A file open dialog will pop-up and you can select the file(s)/folder(s) you want to link.
SVH supports environment variables in its project configuration.
This helps to avoid absolute paths in the .project file.
To use environment variables, you have to prefix the environment variable with ENV-.
For example, to refer to the home directory, you can use ENV-HOME.
Any directory with a valid project description file (project.sigasi) is considered to be a Sigasi project.
Sigasi project description is a JSONC (JSON with comments) file. At the top level, it’s a JSON object with the following fields:
A project can be given a logical name that is used to identify it. If the name field is not specified,
the name of the directory containing this project.sigasi file is used as the project name.
You may want to work with multiple versions of the same design or library. In this case, you can use the version field to differentiate between them.
The version of the project can be any string value. No interpretation of the version string is made, e.g., 1.2, 2020-3.1, and latest are all valid versions.
If a version is not specified, default is used as a value. The project’s version can be used when specifying a project target dependencies.
A project target defines how to compile project HDL source files. A project should define at least one target.
You can define multiple targets as well. In this case, a target can correspond to a specific part or configuration of your project.
The sources of each target are compiled and analyzed independently, unless dependencies are explicitly defined.
If necessary, same sources can be safely compiled into multiple targets.
Targets are defined in the targets section. Each target consists of a name and a definition.
A target name is an arbitrary string that is used to identify it.
You can use supported compiler commands (or scripts that invoke these commands) to define a target.
SVH executes specified commands in a target shell, intercepts, records, and analyzes compiler invocations to extract information
on what files should be compiled in this target and how it should be done.
A scripted target definition can have the following fields:
One or multiple compilation commands. If multiple commands are specified, they are executed in their own shells.
You can use any valid shell command or script, or even use your build system command line interface that invokes
one of the supported compiler commands.
Specified commands should run full compilation. SVH considers files that were compiled during the last run to be the only project files.
If commands perform an incremental build, SVH will see only part of the design.
SVH executes compilation commands as is, and thus don’t have an understanding of what build files contribute to a project structure
in case of complex build scripts. To ensure the project structure is up-to-date, SVH detects changes in project directories and re-runs target commands.
If compilation commands create or change files in one of the project directories, it may result in a refresh loop.
While SVH tries to avoid them, if you experience a refresh loop, you may want to update your build scripts
not to make filesystem changes or disable the
sigasi.project.enableAutomaticTargetRefresh setting.
In addition to system environment variables, SVH makes the following environment variables available in the target shell:
Environment Variable
Description
SIGASI_TARGET_SHELL
Shell that is used to run the target’s commands, e.g., /bin/bash -c or cmd.exe /c
SIGASI_COMPILATION_LOG
Absolute path of the compilation.log file that is being populated
SIGASI_PROJECT_DIRECTORY
Absolute path of the directory that contains the project.sigasi JSON file
SIGASI_COMPILER_STUBS_DIRECTORY
Absolute path of the directory that contains the tool stubs
SIGASI_TCL_SHELL
Absolute path of the TCL shell that is used to run the Questa vsim -doTCL commands
If you need more environment variables for your commands or scripts, or you want to override their value, you can do this in the
environment section. Values can use other environment variables (supported formats: $ENV_VAR, ${ENV_VAR}, ${ENV_VAR:default_value})
When you use existing compilation scripts, they may fail because SVH intercepts compiler command invocations.
If these invocations are supposed to produce artifacts that are required by follow-up commands that are not intercepted by SVH,
these commands may fail.
In such cases, you may set ignoreReturnCode to true in the target definition to ignore such failures. It’s recommended to adapt such scripts
for SVH, so they don’t fail during normal operation. You can look at environment variables, to check if your script is executed by SVH.
Commands are executed in one of the following shells:
bash -c <command> on Linux
cmd.exe /c <command> on Windows
A different shell to use can be configured by defining SIGASI_TARGET_SHELL environment variable.
The value should contain a command prefix, e.g: powershell -command, or /usr/bin/zsh -c.
Target commands will be appended to the specified prefix before execution.
A directory with supported compiler executable stubs is prepended to shell’s PATH,
so no actual compiler invocations are performed by Sigasi. All other commands are executed as is.
Additional environment variables are also set before executing commands.
If you don’t have compilation scripts, or would like to use a declarative way to define target sources, you can use the following fields in a target definition:
Object whose property names are path prefixes (relative to the project directory) and whose values are library names. If this property is omitted or empty, no files will be mapped to a library (Required)
A directory that should contain all HDL sources of this target.
If the directory field is not specified, a project directory is considered to be a target sources directory.
All other paths specified in this target definition are relative to this directory.
It’s recommended to use project directory (default behavior) or specify a path relative to the project directory.
If you need to use a directory that is located somewhere else, you can use environment variables in the directory field value to make it portable.
Supported formats: $ENV_VAR, ${ENV_VAR}, ${ENV_VAR:default_value}.
Using absolute paths is not recommended, as it makes it harder to use such project files on different systems.
In order for SVH to compile HDL sources, they have to be mapped to a library. This can be done in libraryMapping section.
Each key is a path inside the target sources directory. A value is a logical name of a library this path should be mapped to, or a list of library names.
Note that the order of specified paths is not relevant, instead, mappings for longer paths have higher priority.
You can map individual files, or whole directories. If you map a directory, each HDL file in this directory and in all nested directories
will be mapped to the specified library, unless the libraryMapping section contains different mappings for nested directories or files.
You can unmap an HDL file or directory by specifying an empty library names list as a value. In this case, specified file or files in specified directory will not be compiled.
Example:
{"targets":{"UVM":{"libraryMapping":{"":[],// don't map any source file in project directory
"src/uvm.sv":"UVM"// other than this one
}}}}
Target sources directory can contain files generated by your toolchains. If there are a lot of such files, it may negatively affect SVH performance.
If that’s the case, or you want to see and use only relevant source files, you can specify what files in the sources directory should be ignored by SVH.
One or multiple pattens can be specified. Each pattern follows .gitignore format.
Example:
{"targets":{"rtl":{"ignore":["*.log",// Ignore all files that have .log extension in target sources directory
"**/tmp/*"// Ignore all files in all nested "tmp" directories
],// ...
}}}
Specify the list of all VHDL filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as VHDL.
If the vhdlSuffix field is not specified, files with .vhd and .vhdl extensions will be compiled as VHDL.
Specify the list of all Verilog filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as Verilog.
If the verilogSuffix field is not specified, files with .v extension will be compiled as Verilog.
Specify the list of all SystemVerilog filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as SystemVerilog.
If the systemverilogSuffix field is not specified, files with .sv extension will be compiled as SystemVerilog.
Specify what VHDL version should be used to compile VHDL sources. Supported versions: vhdl-1993, vhdl-2002, vhdl-2008, and vhdl-2019.
If the vhdlVersion field is not specified, the default (vhdl-2019) version is used.
Specify what Verilog or SystemVerilog version should be used to compile Verilog sources. Supported versions: verilog-2005 and systemverilog-2012.
If the verilogVersion field is not specified, the default (verilog-2005) version is used.
If some files should be compiled with a different VHDL or Verilog version, you can specify this in the override section.
Each key is a path inside the target sources directory.
If the path denotes a file (with any extension), you can specify VHDL or Verilog version to compile this file with as a value directly.
If the path denotes a directory, you can specify versions to use for VHDL, Verilog, or SystemVerilog files in this directory and in all nested directories,
unless the override section contains different versions for nested directories or files. You can do this by defining following fields in a value object:
Version to use for SystemVerilog files in the specified directory
Example:
{"targets":{"rtl":{// ...
"languageMapping":{"vhdlVersion":"vhdl-2008",// By default use VHDL-2008 to compile all VHDL files
"override":{"otherlib/src":{// Files in "otherlib/src" directory should be compiled differently
"vhdl":"vhdl-2019",// VHDL files should be compiled as VHDL-2019
"verilog":"systemverilog-2012"// Verilog (.v) files should be compiled as SystemVerilog files
},"otherlib/src/core/legacy.vhdp":"vhdl-1993",// This file is an exception, and should be compiled as VHDL-1993
}}}}}
Version to use for VHDL files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by vhdlVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of your VHDL files in the vhdlSuffix field.
Version to use for Verilog files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by verilogVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of Verilog files in the verilogSuffix field.
Version to use for SystemVerilog files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by systemverilogVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of SystemVerilog files in the systemverilogSuffix field.
If necessary, you can specify Verilog include directories or initial defines for all Verilog source files in the verilogPreprocessor section.
You can also configure SVH to compile each Verilog file in its own compilation unit. Following fields are available:
By default, files specified in `include "<filename>" statements are searched only in the targets sources directory.
If you would like to use paths relative to other directories in include statements, you can add these directories in includeDirectories field value.
Whenever you need to set initial defines for your design, you can do this in the define section.
Each key is a name of the macro to define. A value is its body. Value can be an empty string or null if macro should be defined without a body
Example:
{"targets":{"rtl":{// ...
"verilogPreprocessor":{"define":{"CPU":"cpu",// Equivalent to `define CPU cpu
"VCS":""// Equivalent to `define VCS
}}}}}
By default, all Verilog files are compiled in a single compilation unit, setting multiFileCompilationUnitScope to false
will configure SVH to compile each Verilog file in its own compilation unit.
Similar to verilog defines, in the vhdlConditionalAnalysis section you can define string identifiers and values
which are visible to VHDL-2019 conditional analysis directives.
Defining a dependency on another target makes HDL definitions from that target sources available in current target sources,
as well as in sources of all targets that would depend on this target. You can define dependency on:
Another target of the same project (cannot be added for the whole project, only for individual targets)
One or multiple targets of another project
Library from the Library Database
Each dependency is either a string with the name of another target of this project,
or an object with another project name as a key, and an object with the following fields as a value:
Depend on specified targets of referenced project, or libraries of referenced tool
Shortcuts:
When you want to specify only version or target, a shorter version of a dependency declaration is available:
Short version
Full version
{ "common_cells": "1.0" }
{ "common_cells": { "version": "1.0" }
{ "apb_uart": ["test"] }
{ "apb_uart": { "targets": ["test"] } }
Example:
{"dependencies":[// Dependencies for all targets of this project:
// Dependency on all targets of another project with the name "common_cells" and version "1.0"
{"common_cells":"1.0"},// Dependency on target with the name "rtl" of another project with the name "apb_uart"
{"apb_uart":["rtl"]}],"targets":{"ip1":{/*...*/},"rtl":{// ...
"dependencies":[// Dependencies only for this target:
// Dependency on another target of this project with the name "ip1"
"ip1",// Dependency on the UVM 1.2 library from the Library Database
{"UVM":"1.2"},// Dependency on highest Quartus "altera" and "lpm" libraries from the Library Database
{"Quartus":["altera","lpm"]}// Dependency on Vivado 2023.2 "unisim" library from the Library Database
{"Vivado":{"version":"2023.2","targets":["unisim"]}}]}}}
When you specify a dependency on another project or library from the Library Database, it is searched in:
VS Code workspace folders.
Paths specified in the
sigasi.dependenciesSearchPaths setting.
SVH searches for projects recursively in specified directories.
Dependency search path can also point to a Library database, allowing using multiple Library Databases if necessary.
Path To Library Database specified in the
sigasi.pathToLibraryDatabase setting.
Built-in Library Database (is shipped with SVH, and contains following UVM library versions: 1.1d, 1.2, 2017-1.1, 2020-3.1).
These locations are searched in order, and the first project or Library Database library that satisfies dependency requirements (name and version) is used.
If dependency version is not specified, the highest version found is used.
Note that currently SVH does no interpretation of version strings, so:
highest version is determined by simple comparison of version strings
currently there’s no way to specify more complex version requirements (e.g. defining version ranges), only direct match.
Because of SVH limitations, only one version of the project or library can be present in a target dependencies tree.
If the dependencies tree contains multiple versions of the same project or library,
the last specified version (in other words, a version specified closer to the current target in a dependencies tree) is used.
Specify a list of targets of referenced project that should be available in current target.
If no targets are specified, all targets from the referenced project become available.
If an empty list is specified, no targets (other than targets already specified by other dependencies) are added.
Example:
{"targets":{"common":{// ...
"dependencies":[{"Vivado":{"version":"2021.1","targets":["unisim"]}}]},"rtl":{// ...
"dependencies":["common",// Incorrect way to override version (it overrides version, but also adds all Vivado libraries):
{"Vivado":"2023.2"},// Correct way to override version (it overrides version, and does not add any new libraries):
{"Vivado":{"version":"2023.2","targets":[]}}]}}}
New Sigasi projects are an experimental feature and should be explicitly enabled by the
sigasi.project.enableSigasiProjectSupport setting.
SVH intercepts compiler invocations in Sigasi project scripted target commands and interprets their options.
Here is the list of compiler executables that are intercepted, and options that are supported by SVH:
HDL libraries are a very powerful feature of the HDL languages. Sigasi Visual HDL (SVH)
makes it easy to configure and use them. We’re assuming that
you understand the basic concepts of HDL libraries, and so this section focuses on how
they are implemented in SVH.
As with any HDL tool, SVH needs to know where the libraries are
located on your file system. Below, we describe how the library
configuration can be examined and modified using the GUI.
We’ve also presented a use case about how to set up libraries with
SVH to organize your projects.
You can examine the library configuration in the Sigasi Projects view, which
shows how VHDL or SystemVerilog files are mapped.
Each physical file or folder is annotated
with the library it belongs to between square brackets.
In the image above, you can see a mixed-language project called Sigasi-Demo, with a folder named
Common Libraries. In that folder, you see the typical standard
libraries (std and ieee) upon which all VHDL projects depend.
Lower down, you can see other folders, most of which are mapped to the library work.
One of the folders (verilog) is mapped to the library verilog.
You can modify library mapping for project files right in the Sigasi Projects view.
Select a file or a folder in the view and right-click.
Once you select Configure > Set Library in the menu, you will get the library configuration options, as you can see in the image below.
Select Exclude from Build to exclude a file or folder from any library
Select New Library… to define a new library and map a file or folder to it
If you select one or more folders, SVH automatically suggests the folder name as a library, in this case, the includes folder
Select the name of an existing library to map a file or folder to that library
When you map a file into a library, only that file is affected. However,
if you map a folder into a library, then everything in that folder
will be mapped into that library. Any previous library mapping configurations
applied to files or folders in the given folder will be overridden. When you are defining the library mapping
for a new project, you should map from top to bottom.
So, in the case of our Sigasi-Demo project, if work is not
a good default, you would change the top folder’s mapping first and then override the
mapping in the sub-folders.
To exclude any file from all libraries, you can select the Exclude from build option.
SVH will then assume that the corresponding resource is
not part of the project and will not include that resource in a
project build. This is typically useful when you have stale copies of
HDL files or folders lying around that you simply want to ignore.
SystemVerilog include files are always excluded from the build. Any
file that is included in another design file gets excluded from the
build, even if it has an extension that would normally identify it as
a design file, e.g., .v or .sv. It often doesn’t make sense to
compile include files by themselves. Instead, include files are
compiled in the context of the file in which they are included.
All library configuration information is stored in the .library_mapping.xml
file in the root of your project.
If you edit this file, the affected HDL files in your project will be rebuilt automatically.
Note that .library_mapping.xml should be checked into your version control system.
SVH only writes changes to this configuration file when you modify the library configuration.
When you do make changes, SVH first checks that all paths in the
library configuration still exist. If a path no longer exists, it will be
removed from the configuration file.
Note that the library configuration file is case-sensitive, even on Windows.
Each project has a folder called Common Libraries.
This is where reusable libraries go: whether vendor libraries, third-party IP
libraries, or your own reusable libraries. By default, the VHDL STD and IEEE
libraries are added to this folder.
The Common Libraries folder behaves like any other folder.
You can delete it, rename it, or apply a different library mapping.
In most cases, however, the default configuration is just what you need.
In any newly created Sigasi project, the Common Libraries folder
contains the VHDL files of the IEEE and STD libraries.
To add files, right-click the Common Libraries folder and select the
New Linked Folder to create a Linked Folder pointing to the actual folder location that contains the
files you wish to add to the Common Libraries.
Need to add third-party libraries? Learn how here.
Common Libraries by default is a virtual folder. This means that it is not
a real folder in the project directory and it can only contain references to
folders on your file system.
Files in Common Libraries are supposed to be error free. SVH
will not mark errors or warnings in these files.
Aside from these, a few other libraries’ errors and warnings are never marked, regardless of their location.
These libraries are: std, ieee, altera_mf, altera, XilinxCoreLib, unisim, mentor, lpm, simprim, std_developerskit, unimacro, and modelsim_lib.
While you work on your project, you don’t want to edit the files in the
Common Libraries, but you do need them to compile your project.
Using Common Libraries is recommended for files that are supposed to be error free.
This increases SVH’s performance by preventing it from analyzing files that don’t need to be analyzed.
Sigasi Visual HDL provides an easy way to add libraries from Quartus or Vivado or standalone libraries (e.g., UVVM or UVM) to your projects.
Different versions of these tools and libraries can be configured, allowing you to easily switch between them.
The Library Database stores all third-party libraries. Once libraries are extracted into the Database, they can be used in any Sigasi project.
To manage a Library Database, you can open the Tools and Libraries settings page by running the Open Tools and Libraries Settings command or clicking on the corresponding link in the SVH extension settings. On this page, you can see the location of the current Library Database, which libraries are available in this Database, as well as all configured tools and libraries that can be extracted into the Database.
Initially, the Database is empty. Adding a tool will populate the Database with libraries provided by this tool. When a standalone library is added, it will also be copied to the Database. If needed, the tool or library configuration can be changed in the right panel. If you don’t need it anymore, you can remove it from the Library Database as well.
When adding a new tool, you can find a list of detected tool paths in the drop-down menu. Use BROWSE if your tool isn’t there.
It’s good practice to use a tool or library version as its alias; however any identifying string can be used, e.g., latest, stable, etc. The Library Database is self-sufficient, so it’s possible to distribute it between SVH users to ensure everyone uses the same library versions. You can also share it between multiple Sigasi projects.
Note that extracting tool libraries may take a while. During this process, a message is shown in a notification area. If you click on it, a pop-up notification appears, where you can see extraction progress. Pressing the Cancel button will abort the extraction process.
By default, the Library Database will be located inside a workspace storage directory from VS Code. If you are planning to reuse the Library Database, you can choose a different location. When selecting an empty directory, you’ll be given the option to copy an existing Database to this new location. Otherwise, you’ll be able to manually extract added tool libraries or standalone libraries to the new location.
If you have a previously created Library Database, you can select it instead of creating a new one. In this case, if there’s no configuration added for tools and libraries available in the database, a <database> marker will be shown instead of their paths. You can see which libraries are present for a tool by selecting it. You can add more tools or libraries or remove those that are already present in the database as well.
Note: A Library Database can also be created through CLI.
The SVH extension should be running in order to open the Tools and Libraries settings page. You can open or create a project to start the extension.
VS Code provides different scopes for settings: User, Workspace, and Folder. Settings in more specific scopes can override settings in more generic scopes. Be careful if you want to specify tools or libraries manually in settings.json—they can override changes made on the Tools and Libraries settings page.
Once all libraries you need are in the Library Database, right-click your project in Sigasi Projects and click Configure > Project Settings. In the Common Libraries tab, you can select what libraries you want to use in your project. If you notice you don’t need them later on, you can deselect them here as well.
After pressing the APPLY button, selected libraries will be linked to your project in the Common Libraries folder (while deselected libraries will be removed). In a “Source” column, you can see which library or tool version is used.
Note: If project configuration for a library is out-of-sync with an intended library layout (e.g., library files mapping was manually changed), this library will be marked as (out-of-sync) and the SYNCHRONIZE button will appear. Pressing this button will fix the configuration of all libraries that are out-of-sync.
On the Active Tools and Libraries project settings page you can see which versions of libraries and tools are currently being used by your project. If there are multiple versions of tools or libraries available in the Library Database, you can change the version that should be used by a project.
This functionality to add third-party tools and libraries was first introduced in SVH 2024.1, but underwent a major overhaul in SVH 2024.2, resulting in changes to the format of the Library Database. If you’ve already added tools or libraries in SVH 2024.1 and used them in your projects, after updating to SVH 2024.2 or newer, you’ll see that corresponding library files in Common Libraries folder cannot be resolved anymore. In order to update your project setup, you have to:
Re-extract libraries on the Tools and Libraries settings page by pressing EXTRACT button for added tools and libraries. If you used automatically detected tools in SVH 2024.1 you’ll have to add them explicitly first. Learn more
Ensure project configuration for libraries is up-to-date. Go to the project settings Common Libraries page, and if there are out-of-sync libraries, press the SYNCHRONIZE button to update the project configuration. Learn more
The Sigasi Projects View offers a file browser for your projects, including external folders that are not physically part of your project.
This can be useful for including external IP in your projects.
The Projects View also offers a lot of custom Sigasi functionality, such as library mapping, version setting, and project settings.
You can add any (external) libraries and files not within an open project’s folder using the Sigasi Projects View.
In the Sigasi Projects View, right-click any file or folder and select the New Linked File… or New Linked Folder… option to add files and folders from outside the project location.
The configuration of these external files and folders will be kept in the .project file in the project root.
You can add external files and folders anywhere in a project.
If you add a large folder, for example, the unisim primitives, make sure to exclude the folder (Right-click > Configure > Exclude from Build) from being built and only include the required files.
Alternatively, you can put the library files in a folder called Common Libraries.
Then they will only be indexed and not analyzed for errors.
Files can be excluded from showing up in the Sigasi Projects View. By default, project configuration files like .project, .library-mapping.xml, and .settings are filtered.
The filtering can be customized through the following settings, accessible through the Configure Excluded Files button under More Actions:
The sigasi.projectsView.exclude setting specifies a list of glob patterns to match files that will be excluded.
The sigasi.projectsView.excludeNonHdlFiles setting ensures only HDL files are shown.
The sigasi.projectsView.inheritGlobalExclude setting determines whether the global exclusion filter from VS Code should also be applied.
Filtering can be toggled through the Hide Excluded Files toggle button under More Actions.
The Design Hierarchy View shows the hierarchy tree of the design. Initially, the Design Hierarchy View will be empty.
To populate it, click on the Select Top Level Design Unit button that is shown, to select a top level design unit in your project.
This button is also available in the toolbar ().
A Quick Pick will be shown that lists all the available top level design unit candidates.
After picking a design unit from this list, the view will be populated with the structure of your top level.
If you want the selection in the Design Hierarchy View to follow your position in the editor, make sure to enable Follow Cursor from the More Actions () menu.
The Problems View shows problems (errors, warnings, or info) related to your code.
The Problems View is located at the bottom window by default. If it is not open, you can open it by going to View > Open View… and then selecting Problems.
Using the Problems View, you can navigate to the source of a problem by double-clicking on it.
You can filter problems by using the filter icon located at the top-right.
The Libraries View shows the library mapping as well as the description style of the design units in all
projects. You can use it to navigate to a particular design unit in your project. When you click on a file, it will open in the editor.
The UVM Topology View shows the verification environment’s component topology.
When the view is empty, a button is shown that lets you set the root UVM component.
This button is also available in the toolbar ().
After selecting a root UVM component, the view will be populated with the structure of the selected component and its children, including their ports and virtual interfaces.
As you make changes to the design, the UVM Topology View will automatically refresh.
You can navigate to a topology element in an editor by double-clicking it. Right-clicking an element opens a context menu with more navigation options: you can open the type, declaration, or instantiation of a selected element in an editor.
If you want the selection in the UVM Topology View to follow your position in the editor, make sure to enable Follow Cursor from the More Actions () menu. Otherwise, you can explicitly right-click and select Show In > UVM Topology on a UVM component class, a declaration of a component property, an instantiation assignment to this property, or a port connection statement to select the corresponding element in the UVM Topology View.
To open the project, folder or file settings, right-click the project, folder, or file you want to configure in the Sigasi Projects View.
This view allows you to configure all settings for the selected project, folder, or file.
Change the severity of linting rules for your project
Tweak validation parameters
Modify conditional variables for VHDL 2019 projects
Configure include paths and initial defines for the SystemVerilog Preprocessor
Make sure to click the APPLY button at the top right after making your changes.
Changes you make here will be stored in the .settings/ folder within your project.
This way, if you commit the settings with your project, they will be available for your fellow team members.
Note: before 2025.1, project settings were called _project preferences.
You can configure linting rules per project, folder, or file by right-clicking on its name in the Projects View, selecting Configure > [Project/Folder/File] Settings and navigating to Verilog Errors/Warnings or VHDL Errors/Warnings.
The Block Diagram displays a graphical view of all architectures, modules, their instantiations, and generate constructs in your selected editor’s VHDL or SystemVerilog code.
VHDL processes and SystemVerilog always blocks are also shown in the block diagram.
This view automatically updates while you are editing your code and
offers a convenient way to visually inspect and navigate your code, even
when it’s unfinished or broken.
You can open the Block Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Block Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Block Diagram.
You can double-click blocks, ports, or wires to navigate to the corresponding HDL code. If you want to go into a block, you right-click it, and select Open Entity Declaration, Open Architecture, or Open Module.
You can also navigate from your code to the Block Diagram. To reveal a specific signal, port, process, generate, or instantiation: right-click it, select Show In… in the context menu, then select Block Diagram in the pop-up menu. Show In… can also be accessed directly from the hover of an applicable code element.
You can export the Block Diagram to an SVG with the save button on the toolbar.
The State Machines Diagram displays a graphical (bubble diagram) view of all state machines in your current VHDL or SystemVerilog editor. This viewer automatically updates while you are editing your code and offers a convenient way to visually inspect and navigate your code, even when your code is unfinished or broken.
Reset state (dashed arrow): The state that will be assigned when the state machine is reset
Unresolved state (dashed arrow to a ?): SVH found a state transition but cannot determine the end state
Dead state (red outline): States that do not have any outgoing transitions
State names: When a constant name is consistently used to refer to a state, its name will also be used in the diagram
Unused state (red): States that are fully isolated and have no transitions
You can open the State Machines Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open State Machines Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open State Machines Diagram.
If you have documented your state transitions (i.e., the assignments), the comments will be added as text to the transitions in the view.
You can double-click nodes or transitions to navigate to the corresponding HDL code.
With the hide comments button, you can toggle the display of comments on edge labels. With the hide conditions button, you can toggle the display of comments on edge labels. These labels show the code comments of the transition statements. You also have the option to Zoom In, Zoom Out, or Zoom to Fit.
The State Machines Diagram can be exported to an SVG using the save button.
The Dependencies Diagram visualizes the dependencies of your VHDL, SystemVerilog, or mixed language projects.
This view shows the relationships between your source files and makes it easy to see top levels and important packages.
The Dependencies Diagram also makes it easy to detect orphaned files.
The view is automatically updated each time you save your files.
You can open the Dependencies Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Dependencies Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Dependencies Diagram.
The Dependencies Diagram has the following options:
shows dependencies of the entire project, which you can uncheck to focus on the active editor dependencies only
groups design files per library
shows design units inside design files prefixed with an abbreviation of their kind architecture, module, package, etc.
The Dependencies Diagram can help you navigate, too. Double-click a file name in the diagram to open the corresponding editor.
You can also navigate from your code to the Dependencies Diagram. To reveal a specific design unit: right-click it, select Show In… in the context menu, then select Dependencies Diagram in the pop-up menu. Show In… can also be accessed directly from the hover of an applicable code element.
You can export this diagram for documentation by clicking the save button.
The UVM Diagram displays a graphical representation of a root UVM component structure through an intuitive graphical display.
It visualizes the relationships between components, their hierarchical arrangement in the topology, the connections between ports, and the referenced design interfaces. The dynamic expansion of the diagram allows for efficient tracking of connections throughout the UVM component structure.
You can open the UVM Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open UVM Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open UVM Diagram. To select a root UVM component, use the button in the toolbar.
Similar to the UVM Topology View, this diagram offers a set of navigation options for each element (both by double-clicking on elements and through the context menu), allowing you to access an element’s types, declarations, or instantiations. Double-clicking on a port connection line navigates to the corresponding connected method call in the source code.
Like other diagram views, you can find buttons on the toolbar to Zoom to Fit and export the UVM Diagram as an SVG.
With Net Search, you can find a net’s loads and drivers.
A net is defined as a signal or port and all other signals and ports
that are directly connected to it. The loads are where you read the
value of a net, and the drivers are where you write to it.
To find the entire signal or port net, place your cursor on the
identifier and right-click, then select Find Net. Alternatively, you
can press Ctrl+Shift+H.
The Net Search View will appear. For big designs, it might take a
while before the results appear.
From the Net Search View, you can navigate to the code by
either double-clicking a search result or using the keyboard shortcuts.
Press F4 to move to the next entry and Shift+F4 to go to the previous one,
assuming the default keybindings are in place.
You can open the Preprocessor View by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Preprocessor View. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Preprocessor View.
The Class Hierarchy View displays more information about the hierarchy of a class. It consists of a hierarchy tree
and a list of its class members. To open the Class Hierarchy of a class, right-click the class name, and select Show Class Hierarchy (or press F4).
The Documentation View gives you a live preview of the automatic documentation SVH can generate for your project.
You can open the Documentation View by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Documentation View. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Documentation View.
The VS Code Editor shows the content of files and allows you to edit
them. It has a tabbed view such that multiple files can be opened simultaneously.
The active file is the one currently selected.
The VHDL and SystemVerilog (or Verilog) editors are optimized to help
you browse and edit VHDL and SystemVerilog code.
Most browsing and editing features are similar for both languages.
The Sigasi Visual HDL (SVH) extension supports syntax and semantic highlighting.
Syntax highlighting: colors code according to lexical classification (such as keyword or string).
Semantic highlighting: colors code according to meaning (different colors for constants and signals).
Note that some VS Code themes might not support semantic highlighting. If you appear to be missing this feature, make sure you’re using one of the default VS Code themes. If the feature still doesn’t appear, get in touch with support.
In themes that support semantic highlighting, you’ll see that names like those of a port, signal, or type are a different color from language keywords.
In themes that do not support semantic highlighting, names like those of a port, signal, or type will have the default text color.
The latter might also happen when there’s no .project file in your root directory. Without this, the SVH extension will not start and only provides basic syntax highlighting.
Clicking on an identifier highlights it and all other occurrences of the identifier that refer to the same object.
Note that this occurrence highlighting is intelligent: it is not based on the identifier’s string value but on the object to which the identifier refers.
Only true references will be highlighted, not occurrences in strings, comments, or other such instances.
To look for occurrences of a given identifier throughout your design, place your cursor on the identifier and right-click. Then select Go to References.
An inline window will be shown, displaying all occurrences of the selected identifier.
You can easily navigate through all occurrences by clicking the items in the list.
Note that all occurrences are also highlighted in the editor, making them easily recognizable.
You can easily navigate to the declaration of any
port, signal, entity, etc. Place the cursor on the identifier,
right-click, and select Go to Definition. The editor immediately
jumps to the declaration.
You can also navigate your code like a web browser by clicking hyperlinks.
If you press and hold the Ctrl key, hyperlinks will appear in your editor.
If you click a link (while holding the Ctrl key), you will navigate to the target of the link.
To learn more about the declaration of a given identifier, you can hold your mouse over it. After a short time, a popup will show you the name and datatype of the signal. This technique is called hovering.
Hover pop-ups can show different kinds of information:
datatype
comments: inline documentation written for the declaration (association rules)
value: the value of constants
errors or warnings: a description of the problem, if the given identifier has an error or warning associated with it
binary/decimal conversion: for hexadecimal, octal, or binary values, the decimal equivalent
SVH provides powerful autocompletion capabilities. This means
that the tool can help you complete identifiers and constructs as you are working on the code. Like other tools, it provides
syntax-based autocompletion depending on the HDL language you’re using. However, it goes much
further: it can also provide autocompletion based on the design context because it knows everything that has been declared in the design.
Autocompletion can come from different sources, as discussed in the following sections. However, the user interface to initiate it is always the same.
SVH will suggest appropriate autocompletion options at any point as you enter code.
You can also trigger autocompletion suggestions by first placing your cursor where you want to autocomplete and then pressing Ctrl+Space.
SVH uses its knowledge of designs to provide intelligent
autocompletion that boosts your productivity tremendously.
The tool understands the current context, which identifiers are
visible, and which constructs are legal at any given point in the code.
As you start typing and ask for autocompletion, it will suggest
appropriate identifiers as autocompletion candidates.
SVH provides autocomplete suggestions for:
component declarations
component instantiations
entity instantiations
module instantiations
case statements (based on variables/signals with an enumeration type)
SystemVerilog preprocessor/macro directives, e.g., `define or `ifndef
SystemVerilog include paths ( `include ""): triggering autocomplete between the double quotes will present a list of files and folders. If you select a folder, trigger autocomplete again to get completions in this folder.
SVH can help you declare VHDL and SystemVerilog constructs, using autocomplete based on templates.
SVH comes preconfigured with templates for all common declarations and statements, including (for VHDL):
function, procedure
process
type: enum, file, range, array, record
signal, constant, variable
component
entity
architecture
entity/architecture pair
package/package body pair
and much more
Some autocompletions are templates that require further user input.
In such a case, the editor window will go into a special template editing mode after performing an autocomplete.
Use TAB to go through the items that have to be modified or completed.
When done, press ENTER to return to normal editing mode.
The cursor will be placed at an appropriate position to continue working.
Note: In other tools, this feature may be known as paste as instantiation or port translation.
SVH knows all design units (entities, components, and modules) in a design and their ports and parameters or generic interfaces, and can therefore automate much of the instantiation process.
At the point in the code where you normally enter a design unit’s name, use autocompletion instead to suggest a list of possible design units.
Upon selection, the tool will complete the instantiation with a generic or parameter list, and a port list with named associations.
As an initial suggestion, each actual parameter will have the same name as its formal parameter.
Of course, the actual parameter names need to be reviewed and edited by the user. Therefore, the editor will go into template editing mode after the autocompletion.
When you invoke a function in VHDL or Verilog, SVH will list that function’s arguments in a pop-up window that will appear once you type an open parenthesis.
The Signature Helper also activates when instantiating a VHDL entity or a Verilog module by listing the ports or generics of that entity or module.
When you press enter, SVH automatically adjusts the indentation of
the current and the new line. Depending on the content of the preceding
line, SVH will automatically increase or decrease the indentation
level. For example, it may add an extra indent after a module or an entity and remove an indent for
the matching endmodule or end entity.
Automated consistent code formatting makes code more readable and understandable for developers, whether working on their own code or when cooperating with colleagues.
In order to format your code, right-click in the editor and select Format Document.
Right-click on any identifier (VHDL or SystemVerilog) and select Rename Symbol to change the name of the associated declaration and all its references.
Once you select Rename Symbol a little dialog box will pop up.
At this point, you can type the new name and press ENTER. This will rename the declaration of that symbol and all its references.
Before renaming, you can also press CTRL+ENTER to see a preview before making changes across your files.
At the bottom, a Refactor Preview tab appears and lists the summary of the changes to be made.
Clickig any of the items in the list visualizes all changes side-by-side.
You can then click the APPLY button to accept the changes or click the DISCARD button to cancel the renaming action.
Note that this feature does not rename references in comments.
When a rename action affects a read-only file, a preview will automatically be shown. In this preview, changes to read-only files are shown, but not selected by default, ensuring that they won’t be applied unless explicitly confirmed.
You can disable this preview behavior by toggling the
sigasi.editor.previewReadonlyFileOperations setting. This can be particularly useful if you’re working with a pessimistic version control system like Perforce, where you may prefer that changes to read-only files are applied immediately without requiring additional confirmation.
Code lenses provide you with shortcuts to contextual actions, right inside the editor. For example, instead of going through the context-menu to set an architecture as Design Hierarchy Top, you can now simply click Set as Design Hierarchy Top.
Every code lens can be toggled on or off individually by changing one of the following settings:
Code Lens
Setting
Default
Export Compilation Order
sigasi.editor.codeLens.exportCompilationOrder
Export Documentation
sigasi.editor.codeLens.exportDocumentation
File is not part of any library
sigasi.editor.codeLens.fileIsNotPartOfAnyLibrary
Open Block Diagram
sigasi.editor.codeLens.openBlockDiagram
Open Class Hierarchy
sigasi.editor.codeLens.openClassHierarchy
Open State Machines Diagram
sigasi.editor.codeLens.openStateMachinesDiagram
Open UVM Diagram
sigasi.editor.codeLens.openUvmDiagram
Set as Design Hierarchy Top
sigasi.editor.codeLens.setAsDesignHierarchyTop
Set as UVM Topology Root
sigasi.editor.codeLens.setAsUvmTopologyRoot
Code lenses can also be disabled entirely by toggling the
editor.codeLens setting.
Similar to code lenses, inlay hints provide you with useful shortcuts right inside the editor. Code lenses take up a separate line, while inlay hints are displayed inline.
Inlay hints can be toggled on or of by changing the
editor.inlayHints.enabled setting.
If you work with large files, you might want to hide certain pieces of your code. This can be done with code folding.
Certain constructs, such as if-statements or process-statements, can be folded so that they are displayed as a single line in the editor view.
You can do this by clicking the little arrow symbols next to the statement or declaration.
If you select a region and press ( or [, the tool will enclose the selected region with the matching closing parenthesis, ) or ].
If you select a region and press ( or [, the tool will enclose the selected region with the matching closing parenthesis, ) or ].
This works for both regular and multi-line strings and with either single or double quotation marks.
You can configure this feature with the
editor.autoClosingQuotes setting.
The VS Code editor can be split into independent viewports that access the same file buffer.
To split the editor, go to View > Editor Layout and select the desired action.
There can be more than two horizontal or vertical splits within an editor.
You can use sticky scroll to navigate through your HDL code more easily. The stickiness is based on the code folding regions.
You can configure this feature with the
editor.stickyScroll.enabled setting.
You can customize color preferences in SVH. Open the Command Palette via Ctrl+Shift+P, type color, and select Preferences: Color Theme from the list.
You will get a list of themes from which to choose.
VS Code supports multiple cursors for simultaneous edits. Cursors can be added using Alt+Click.
If you prefer using Ctrl+Click, open the Command Palette via Ctrl+Shift+P, type multi, and select Toggle Multi-Cursor Modifier from the list to quickly toggle the modifier.
This can also be changed in the settings.
In order to open a design unit in your project, press Ctrl+P, filter the list by typing, and select the design unit that you want to open from the list.
For a quick outline of the objects in a file in the editor, press Ctrl+P, and type @. You can also type : when opening the Quick Outline to group the items by category.
In addition to the powerful features of the VS Code editor, the SVH VHDL
editor supports a number of advanced editing
features that are specifically useful for VHDL editing. These are
described below.
If you want to create an instantiation based on a component (as opposed to
a direct entity instantiation), you need to associate an entity with a component.
SVH can automatically declare a component for an existing entity. In
the place where you would normally enter the component name, use
autocomplete instead to show the list of available entities. Upon
selection, the tool will automatically complete the component
declaration.
Autocomplete suggestions automatically appear and are updated as you type.
In VHDL design, you need to do a lot of type conversions, and SVH’s
autocomplete functionality can help you here. Put a period (.)
after the element you want to convert and the autocomplete suggestions
will appear with descriptions like convert type.
Once you select the desired conversion function, SVH will insert the code.
SVH’s formatter is context-based and tries to respect the author’s style. So depending on your source style, the formatter might make different choices.
One example of this is the decision to format a conditional signal assignment on one or more lines. SVH decides based on the position of the first else keyword.
If you put the else keyword on the first line, the formatter will keep everything on one line. If you put the else keyword on a new line, the formatter will use multiple lines for the assignment.
demo<=(others=>'0')whenenable='1'else(others=>'1')wheninput='1'-- else on new lineelse(others=>'X');
Note about broken code: If your VHDL source file contains syntactical errors, the formatter cannot always figure out appropriate formatting.
For this reason, the formatter is programmed to stop applying (whitespace) changes beyond unsupported syntax errors.
In order to change your formatting settings, right-click the project name in the Sigasi Projects View and select Configure > Project Settings.
Then click VHDL Formatting and enable project formatting settings.
Preserve newlines: this option configures the formatter to not add or remove any newlines in your code.
Vertical alignment: this option configures the formatter to vertically align consecutive declarations and statements, for example <= or :.
Lowercase/Uppercase keywords: when this option is set to UPPERCASE the formatter will convert all VHDL keywords to uppercase.
When this option is set to lowercase, the keywords will be converted to lowercase.
When this option is set to ignore, the case of keywords won’t be changed by the formatter. Note: A Sigasi Visual HDL Designer Edition license is required for this option.
Alignment column for trailing comments: this setting configures what column SVH aligns trailing comments to. The default is 40, but you can choose 0 to not align trailing comments.
VHDL 2019 tool directives are a simplified version of the preprocessor found in
SystemVerilog or the C-family of languages. Tool directives allow for conditionally enabling code based on tool type,
debug mode, or any other custom variable.
In order to edit VHDL tool directives, right-click the project name in the Sigasi Projects View and select Configure > Project Settings.
Then click VHDL Conditional Variables.
Note that some keys are hardcoded as required by the VHDL Language Reference Manual.
To configure the VHDL version, right-click the project name in the Sigasi Projects View and select Configure > Set Language Version.
In the dialog box, select Set VHDL version and then select the desired VHDL version.
The VHDL version can also be set at the folder and file level, but changing the version at the project level will override all folder and file level settings.
Also note that the VHDL version of a folder or file must be greater or equal to the VHDL version of the project.
Stuttering is an editing technique popularized by Emacs that lets you
type certain things really fast. You activate it by tapping a certain
key twice which will expand it to something more complex. For example, press
the period key . twice, and the editor will expand it to a right
arrow =>. Stuttering works like double-clicking: if you type keys
slowly, the stuttering mechanism will not be triggered.
The following stuttering keys are available:
Keys
Effect
,,
<=
..
=>
;;
:=
Stuttering is enabled by default but can be toggled with the
sigasi.vhdl.stuttering setting.
In addition to the powerful features of the VS Code editor, the included SVH Verilog and SystemVerilog
editor supports a number of advanced editing
features that are specifically useful for SystemVerilog editing.
These are described below. Currently, SVH supports Verilog 2005 (IEEE 1364-2005) and SystemVerilog 2017 (IEEE 1800-2017).
Making a typo in the file name of an `include causes swarms of errors. To prevent this, you can simply press Ctrl+Space
between the double quotation marks of an include directive. You’ll be presented with all the files reachable from
your current include path.
Right-click in the editor and select Format Document to format your current Verilog or SystemVerilog file.
The default formatter implementation corrects indentation only.
You can choose whether *.v files are treated as Verilog (IEEE 1364-2005) or SystemVerilog (IEEE 1800-2017). *.sv files are always treated as SystemVerilog. To configure the Verilog version, right-click the project name in the Sigasi Projects View and select Configure > Set Language Version. In the dialog box, select Set Verilog version.
Sigasi attempts to resolve missing Include Paths automatically. However, we highly recommend you explicitly configure include paths to ensure the order is accurate.
You can configure include paths on the Verilog Preprocessor page.
Right-click the project name in the Sigasi Projects View and select Verilog Preprocessor.
Here you can set include paths. In the Initial preprocessor definitions field, you can configure definitions to be set before other files in the project are processed.
This allows you, for example, to set global defines without an explicit include statement.
When you hover over a SystemVerilog preprocessor directive (e.g. include ...), SVH shows the preprocessed text.
In the Preprocessor View, you can preview the expanded version of your preprocessed SystemVerilog source files.
In order to open the Preprocessor View, right-click in the editor and select Show In > Preprocessor.
The Sigasi Visual HDL (SVH) documentation generator makes the documentation process more manageable by automatically extracting information from your HDL source files. The biggest advantage is that there is only a single source for both your design and your documentation. While this gives no guarantee that the design stays in sync with the documentation, it certainly makes it easier.
The Sigasi documentation generator has the following advantages:
No special coding requirements: the plain comments in your code are extracted for the documentation; no need for special annotations. Sigasi uses the same comment association as the hover provider. So, to document a port, you append a comment to a port declaration. To document an architecture, you put the comment just on top of the architecture.
All included. All documentation processing is done in SVH. So you do not need to install extra tools.
Fully hyperlinked. If you export the documentation, you get a fully hyperlinked document.
Live preview. You can see what the documentation will look like while you type your code and comments.
To export documentation, right-click on a project in the Sigasi Projects View and select Export > Export Documentation. Alternatively, you can run the Sigasi: Export Documentation from the Command Palette (Ctrl+Shift+P). A wizard will be opened to customize your documentation. To simplify exporting documentation for certain design units, a code lens is also available which can be enabled by toggling the
sigasi.editor.codeLens.exportDocumentation setting.
You have to choose between Linked resources and Embedded resources when exporting documentation.
Linked resources Creates an HTML document with linked resources.
All Block Diagrams and State Machine Diagrams are in separate files that are linked from within the HTML document.
Any custom CSS file present in the project root will be referenced from the HTML document.
Embedded resources Creates an HTML document with embedded resources.
All Block Diagrams and State Machine Diagrams are embedded in the HTML document.
Any CSS from a custom CSS file present in the project root will be included in the HTML <head>.
Enabling the Split pages by elements count or Split pages by design unit count will paginate the output documentation. This is useful for very large designs that produce extensive documentation of hundreds of MBs.
Summary information about the design appears on the first page and fans out to subsequent pages containing the documentation about individual design elements.
Enabling Include problem information or Include problem markers will add a Problems section containing all the project’s Errors, Errors and warnings, or Errors, warnings, and infos. You can also have it show suppressed problems.
You can specify the folder where you want to export the documentation. If you leave the field empty, it is exported into the sigasi-doc folder of the selected project.
The given path can be relative, which is then resolved starting at the root of the selected project.
If a sigasi-doc.md file is present in the root directory of your project, Sigasi will automatically include it in the exported documentation as an introductory chapter. As usual with our documentation, this is a Markdown file. This allows you to annotate the text easily.
If the root of your project contains a sigasi-doc.css file, this file will be used to style generated HTML documentation.
Note that only the generated HTML will be affected and not the Documentation View.
For example, you can give the background and titles different colors. You can also change the font for all or parts of the document.
Entire sections for entities, architectures, and modules can have different background colors.
Likewise, process lists can have different background colors.
Comments in HDL code are used to add extra information or documentation to that code.
SVH uses certain rules to determine which comment belongs to which code.
This is important for documentation hovers, refactoring, formatting, etc.
However, which comment belongs to which exact code is subjective.
SVH associates comments with HDL declarations with the following rules:
If there is a declaration before a comment in the same line (trailing comment), the comment is associated with this declaration. This comment can span multiple single-line comments that are aligned.
If there is no trailing comment and there is a comment on the line above the declaration with the same indentation, the comment is associated with this declaration. This comment can span multiple lines if they all have the same indentation.
Empty lines break comment blocks
The association rules are illustrated in the image below:
The Formatter and Structural select respect (and fix) comments according to the association rules.
VHDL components and component instantiations: If a component (or one of its ports or generics) does not have a comment itself, SVH will use the comment of the corresponding entity. This also works for component instantiations.
VHDL and SystemVerilog comments are processed with a Markdown processor . This allows you to add markup (e.g., bold, code, paragraphs, hyperlinks, etc.) to comments, resulting in nicer hovers and documentation.
Hovers support complete Markdown syntax. For documentation generation, the following features are supported:
paragraphs (by adding an empty comment line)
line breaks (by adding two trailing spaces)
emphasis (*emphasis*)
bold (**bold**)
lists
tables (with alignment)
external links and email addresses (<https://www.sigasi.com>, [Sigasi](https://www.sigasi.com) and <sales@sigasi.com>)
SVH supports Fenced Code blocks in comments.
This enables you to add text to documentation without Markdown rendering.
To add a comment verbatim to documentation, surround it with triple backticks: ```<verbatim comment>```
You can export a list of all HDL files in your project, sorted in the correct compilation order.
You can use your own simple scripts to manipulate a list and run any EDA tool, including simulator, synthesis, and linter tools.
To export a comma-separated values (CSV) list of files in your project, right-click on a project in the Sigasi Projects View and select Export > Export Compilation Order CSV. Alternatively, you can run the Sigasi: Export Compilation Order CSV from the Command Palette (Ctrl+Shift+P). A wizard will be opened that allows you to select the project and, optionally, a top level design unit. To easily export the compilation order for a certain top level, there is also a code lens you can enable by toggling the
sigasi.editor.codeLens.exportCompilationOrder setting.
After the export has finished, a file named compilation_order.csv or toplevel_order.csv (if a top level was selected) is generated in the root of your project. The file lists the HDL files in your project in a valid compile order.
The Compilation Recipe Export command provides a standardized, machine-readable way to export the compilation order and all compilation details, such as library mapping and language levels, of your Sigasi project.
This feature is essential for integrating your Sigasi project with external tools, such as simulators, synthesis tools, linters, or any custom script that requires an ordered list of HDL files. The command generates a JSON file that precisely describes the project structure, ensuring that your external tools can compile your design in the correct order with the correct settings.
Files are grouped by their target library, language version, and other compilation settings. The order of these groups and the order of files within each group represents the recommended compilation order.
Key
Type
Description
library
String
The name of the HDL library into which the files in this group should be compiled (e.g., my_lib, work).
languageLevel
String
The HDL language version for this group. Possible values include: "VHDL-1993", "VHDL-2002", "VHDL-2008", "VHDL-2019", "Verilog-2005", "SystemVerilog-2012", "SystemVerilog-2017", and "SystemVerilog-2021".
includeDirectories
Array of Strings
(Optional) An array of paths to include directories for Verilog/SystemVerilog include directives. These paths will be absolute or relative based on the export setting.
defines
Object
(Optional) An object containing Verilog macro definitions as key-value pairs (e.g., { "MY_DEFINE": "value" }).
conditionalVariables
Object
(Optional) An object containing custom VHDL conditional analysis variables as key-value pairs.
files
Array
An array of file objects that belong to this group.
This object represents a single source file to be compiled.
Key
Type
Description
path
String
The path to the HDL source file. This will be an absolute path or a path relative to the project root, depending on the choice made during export.
sourceType
String
The origin of the file. Can be: "Project" (file is part of the user’s project), "Dependency" (file comes from a dependency), or "ExternalLibrary" (file is from an external source).
The primary purpose of the compilation recipe is to enable automation and integration with other EDA tools.
Custom Simulation Scripts: Write a Python, Tcl, or other script to parse the compilation-recipe.json file. The script can read the fileGroups, files, defines, and includeDirectories to generate a precise compilation script for your chosen simulator, e.g., ModelSim/Questa, Vivado Xsim, GHDL, VCS.
CI/CD Pipelines: This recipe is ideal for automation. In a Continuous Integration (CI/CD) environment, you can use the Sigasi CLI tool to programmatically generate the compilation-recipe.json file. This allows for seamless integration into your automated build and test pipelines, ensuring that your CI system always uses the exact file list and compilation order defined in your Sigasi project without requiring manually maintained scripts.
Third-Party Tool Integration: Use the recipe to feed your project’s file structure into linters, formal verification tools, or code formatters that require a structured input of source files and their compilation context.
It is possible to run the User Interface of Visual Studio Code on one machine and do the actual development on another machine.
For example, you can be working on a Windows laptop at home while the code lives on a Linux server in a datacenter at work.
To work remotely, you only need to install Visual Studio Code and the Remote SSH plugin.
The plugin connects with the remote server using SSH and handles any setup required on the server.
The Sigasi extension only needs to be installed on the remote server.
Your code is kept on the server; there is no need to have a copy on the remote machine. Documentation is available on the Visual Studio website .
Navigate to extensions (Ctrl+Shift+X or the icon on the left) and install the Remote - SSH extension.
From the Command Palette (Ctrl+Shift+P), select Remote-SSH: Connect Current Window to Host…. If you have an SSH config file, you can use an existing configuration here. Otherwise, select Add New SSH host and add the command to connect to your server. Note that you need to enter the full command line and not just the name of the server. Typically, the full command will look like ssh username@my.compa.ny.
To automate this, we recommend to use an SSH key-pair in combination with the SSH config file.
Once the connection is configured, connect to the server. In the bottom left corner of your VS Code window, you’ll find an indication of the remote connection.
In the connected VS Code window, navigate to extensions and install the SVH extension on the remote server.
Navigate to the Explorer (e.g. Ctrl+Shift+E) and either open an existing workspace folder or clone a repository.
Check your Sigasi license setting. From the Command Palette (Ctrl+Shift+P), select Preferences: Open Settings (UI), and look for Sigasi: Path To License. With remote development, this is the license path on the server.
Now open a VHDL, Verilog or SystemVerilog file on the remote server.
When using the SVH extension in combination with the Remote SSH extension, the Sigasi license should be available on the remote host.
If you’re also using SVH locally, the license settings might be different for local and remote development. In that case, make sure to use the proper settings, depending on whether you’re developing locally or remote.
The settings from the User level will act as the default and can be overridden for each remote by setting the Remote [<remote name>].
Semantic coloring lets you enhance the readability of your VHDL code by applying custom colors and styles to different language constructs. This guide explains how to configure the custom VHDL semantic tokens in your VS Code settings.
Open VS Code Settings:
Navigate to File > Preferences > Settings and search for
editor.semanticTokenColorCustomizations.
Edit or Add Your Rules:
Modify the existing rules or add new ones based on the semantic tokens. Use the provided example as a starting point.
Save Your Changes:
Once you’ve made your customizations, save the settings file. The new semantic coloring will be applied to your VHDL code immediately.
SAL (Sigasi AI Layer, in case you’re wondering) is the name of the integrated AI chatbot in Sigasi Visual HDL.
There are three ways to get a conversation with SAL started:
Open Chat with SAL in the Sigasi view
Toggle the Command Palette (Ctrl-Shift-P) and choose Sigasi Visual HDL: Focus on Chat with SAL View
Right-click anywhere in the editor and select SAL > Explain This Code
Note: Through SAL, you can connect to a remote model using the OpenAI API, such as OpenAI’s GPT 4 model, or a local AI model of your choice via LM Studio.
SAL is configured using up to four environment variables.
Be sure to set them before starting Sigasi Visual HDL, so they get picked up correctly.
The easiest way to get started it by connecting to the OpenAI servers, as detailed below.
If you prefer to use a model made by another company, or you’re working on an airgapped machine, you’ll have to set up a local model.
If you have a working internet connection and an OpenAI API key,
configuring the backend for SAL is as easy as setting the environment variable SIGASI_AI_API_KEY to your API key.
By default, this will use the GPT 3.5 Turbo model.
exportSIGASI_AI_API_KEY="your-openai-api-key"
You can use a different model by setting the SIGASI_AI_MODEL to e.g. gpt-4-turbo.
exportSIGASI_AI_MODEL="gpt-4-turbo"# with the GPT 4 modelexportSIGASI_AI_API_KEY="your-openai-api-key"# with this API key
This guide will help you use LM Studio to host a local Large Language Model (LLM) to work with SAL.
Currently, SAL supports the OpenAI integration API, and any deployed server utilizing this API can interface with SAL.
You need to set the correct URL endpoint and model name, and optionally provide the API key if required by the endpoint.
In addition to syntax validation, SVH also checks your code for
semantic problems. This is often referred to as Linting or Linter checks. Some of these
problems can be automatically resolved with Quick Fixes. Both syntax
checking and linting happen at type-time: problems are revealed as you are
typing your code.
A Code Linter is defined as a tool that finds code that is strictly correct according
to the language definition, but still suspicious or problematic.
Sigasi has a built-in linter, which provides info about code lint
in the design.
The Sigasi linter has reasonable defaults for the configuration
of reported problems, but the severity level of certain
linting rules is configurable for additional flexibility.
Furthermore, some linting rules, such as the VHDL maximum line width
rule, are parameterized and can be tweaked
to your preference.
For each linting rule, you can set the severity of non-conformities
in all code or RTL-specific code. For some linting rules, more
configuration options are available in the sidebar of the settings page. Look into the
documentation of a specific rule for more details on its effect.
Linting rules can be configured per project, folder, or file by right-clicking a project, folder, or file
in the Sigasi Projects view, selecting Configure > [Project/Folder/File] Settings, and clicking VHDL Errors/Warnings or Verilog Errors/Warnings.
You will then be able to change the linting rule configurations.
All configurable linting rules will also offer configure rule Quick Fixes. These can be used to quickly open the settings page corresponding to a specific linting rule.
You can suppress specific problems in your code by adding a @suppress comment (-- @suppress for VHDL and // @suppress for SystemVerilog) on the same line as the problem.
You can limit the suppression to a specific problem by adding a prefix of the problem message between quotes after @suppress. Sigasi also recommends adding a reason why the problem was suppressed by adding an extra comment after @suppress:
<line with problem> // @suppress "Problem message prefix" Reason why problem is suppressed
Changes through Sigasi version:
Since Sigasi Studio 4.2 the @suppress comment also suppresses errors.
Since Sigasi Studio 4.3 problems have a Quick Fix to automatically add the @suppress comment with a matching problem message prefix.
Since Sigasi Studio 5.4 it is possible to suppress all the problems file-, library-, or project-wide through a single Quick Fix.
Where ${path} can be <project> (literally, with brackets!) to set the severity of the entire project,
/path/to/folder to set the severity of an entire folder,
or /path/to/file.vhd to set the severity of a specific file.
The valid values for the parameters are documented on the individual linting rule pages.
They are described according to the following rules:
{value1|value2} means that either value1 or value2 must be used,
e.g., true for {true|false} or bit_vector for {enumeration|bit_vector|std_logic_vector}.
${integer} means the value must be an integral number, e.g., 5.
If the number must fall within a range, it is specified in a comment.
[keyword...] means the value is any number of keywords (or other strings) separated by tab characters,
e.g.
ENTITY PACKAGE
If any of the strings must contain a tab character or a single quote, escape it using a single quote.
For example, below is a list of 2 items, the first a<Tab>tab and the second a'quote.
a' tab a''quote
${regex} means the value must be an RE2/J regular expression, e.g., 0|1.
Whitespace in keys must be escaped with a backslash (\``). You can add comments using a #`.
In the VS Code editor, SVH marks errors, warnings, and info with red, yellow, and blue underlines, respectively.
This keeps you visually aware of the problems or info in your code.
SVH can check whether all sorts of names in the design; entities,
instances, modules, signals, variables, etc.; follow
particular patterns. This may help designers follow their
company’s or team’s coding rules. For example, coding rules may
prescribe that signal names must have a s_ prefix, that generic
names must be written in capitals, or that variable names must use
CamelCase. A naming convention rule is empty by default, which means
that the particular rule is not checked.
In addition, Sigasi can also check for header comments of files,
design units, subprograms, etc. This could, for instance, be used to
check whether a copyright notice or disclaimer has been included in
a file header comment.
Naming conventions configuration can be found in the Style Validation rule category.
At the top-right, you can set the severity of naming convention non-conformities.
Below the severity settings, you can enter validation patterns.
Patterns use the RE2/J regular expression syntax.
Note that names are not validated if the corresponding validation pattern is empty.
You can add two patterns per name: a valid pattern that the name must match (a marker will appear if it does not match) and an
invalid pattern that the name must not match (a marker will appear if
it does). You can set either or both patterns per name.
Similarly, you can also find header comment configuration in the Style Validation rule category.
Problems that have markers can be resolved automatically through a Quick Fix.
To see whether a Quick Fix is available, hover over a problem underline.
Then click Quick Fix… and select one of the Quick Fixes from the list.
You can also click on the problem marker to make a lightbulb icon appear at the beginning of that line.
Clicking the lightbulb will make the Quick Fix list appear. You can then select one of the Quick Fixes from the list.
Finally, you can also trigger Quick Fixes from the Problems View by hovering over
a problem and clicking the lightbulb icon that appears.
The templates editor allows you to define reusable code blocks encompassing frequently used elements like process blocks, signal declarations, or loop constructs. You can seamlessly insert these templates into your VHDL or Verilog code at the cursor position. This eliminates the need for manual typing of repetitive structures, saving you valuable time and reducing the potential for inconsistencies.
You can access the editor through the settings (search for sigasi.userDefinedTemplates). The setting you’ll find has a button to edit your custom templates. It is also available through Ctrl+Shift+P > Sigasi: Open Templates Editor.
In templates you can use variables whose values will be resolved at the time of insertion. Some variables have arguments that require an ID in order to be used, for example ${path:env('PATH')}.
The following is a list of all built-in variables SVH supports:
Variable
Description
${cursor}
Specifies where the cursor will end up when the template is completed.
${date} ${id:date(format[,locale])}
Evaluates to the current date in the specified format and locale. The format and locale parameters are optional.
${dollar}
Evaluates to the dollar symbol $. Alternatively, $$ can be used.
You can configure VHDL formatting settings for a project in Sigasi Visual HDL (SVH) to ensure consistent formatting
across platforms and among users working on the same project.
Sigasi Visual HDL (SVH) provides several features that help write UVM testbenches.
However, you first have to set up a project with a UVM library to use these features.
This page describes how to set up a UVM project in SVH.
The instructions described here are general; refer to the
Project Setup section for
details on project setup.
Open the folder of your UVM project and add Sigasi support to the project.
The project will have a lot of errors at this point, indicating missing declarations
and undefined macros as shown in the image below.
Make sure that UVM is added to SVH Tools and Libraries as explained in Adding Third-Party Libraries to a Project. If you don’t have UVM source files on your system yet, you can
download them here .
Use the UVM library inside your new project by opening the Project Settings, selecting UVM, and clicking the APPLY button as shown below.
At this point, most of the errors should be gone. The image below shows the linked UVM folder inside the Common Libraries in the Sigasi Projects view. You should now see UVM in your Common Libraries.
After completing the steps above, all of the problems related to UVM configuration should be gone as shown below.
You can now use all the UVM features, such as the UVM Diagram, UVM Topology View, and Preprocessor view. The latter resolves any includes automatically and allows you to view the entire UVM code after preprocessing.
Sigasi Visual HDL (SVH) offers Smart Indentation for both VHDL and Verilog. When enabled, the indentation level is automatically adjusted based on the context and the code being written.
To make use of SVH’s Smart Indentation, make sure the Editor: Auto Indent setting is set to full. To further configure the inserted indentation, the following settings can be used:
Editor: Insert Spaces: To insert spaces rather than tabs.
Editor: Indent Size: To configure the size of the indentation.
Editor: Detect Indentation: To dynamically adjust the previous two settings based on the indentation style used in the current file.
The table below lists the Verilog and SystemVerilog linting rules that SVH can check automatically.
The availability of linting rules depends on the license requirements.
Save the license that is sent to you in a file, e.g., sigasi.lic.
You can set the path to your license file through the
sigasi.pathToLicense setting.
To navigate to this setting, you can hover over the status bar item at the bottom of your window indicating SVH Disabled.
After clicking on the Configure Your License button in the hover, the license settings will be opened.
Type the path to your license file (e.g., /home/user/sigasi.lic) in the box under Sigasi: Path to License.
If you have a floating license key, you need to configure both a license server and SVH.
SVH’s license key management system is based on the well-known FlexNet (a.k.a. FlexLM) license manager.
In order to use a floating license, you should first set up a license server.
Read more about this on the Setting Up Your License Server page.
In VS Code, go to the SVH extension settings as described in the node locked licenses section.
Next, enter <portnumber>@<servername> in the Sigasi: Path to License. For example:
27000@myserver.example.com
If you have redundant license servers, enter each of the license servers separated by a comma (,).
We recommend you specify the primary server first in the list, because the first item in the list is checked first.
For example:
If you have multiple, non-redundant license servers, the servers should be separated using colons (:) on Linux and using semicolons (;) on Windows.
If you leave Sigasi: Path to License empty, SVH will try to use an environment variable
to find the license server. If this fails, it will look for a .sigasi.lic file in your home folder.
You can also set your license server via an environment variable instead of configuring it in SVH.
Both SIGASI_LM_LICENSE_FILE and LM_LICENSE_FILE are supported.
When SIGASI_LM_LICENSE_FILE is set, LM_LICENSE_FILE is ignored.
Note that if you want to use an environment variable, you cannot enter a path in Sigasi: Path to License in the extension settings.
The value in the extension settings has priority over environment variables.
For redundant license servers, the servers should be separated using commas (,).
We recommend you specify the primary server first in the list.
For example:
Sigasi Visual HDL will automatically upgrade the license to the
edition that is required for the used feature,
e.g., when first using the Block Diagram, SVH will bump your license from Designer to Professional.
We will hold on to the acquired license after upgrading, unless you manually downgrade the license again.
You can downgrade the license through the Downgrade to ... Edition button in the license status bar item.
The license status bar item can be found at the bottom of the window, indicating the current edition that is in use.
After downgrading, all views that require a higher edition will be disabled. These views will show buttons to upgrade the license again.
For some features, like the UVM linting rules,
there is no automatic upgrading. To activate and use UVM linting rules, you need to explicitly enable them, even if you’ve already checked out the required license.
The way to do so depends on the SVH version you are using.
When using SVH 2024.2.1 or newer versions, UVM linting rules can be enabled through the
sigasi.enableUvmLinting setting.
When using SVH 2024.1, 2024.1.1, 2024.1.2, or 2024.1.3, the UVM linting rules can be enabled by configuring the
sigasi.licenseToCheckOut setting to either Professional or Enterprise. When you configure a license to
check out, SVH will immediately check out that license on startup. Note that we might still upgrade the license to a
higher edition; for example, when a Sigasi Visual HDL Professional Edition license is configured as the license to check out, but
a documentation export is performed, SVH will upgrade to an Sigasi Visual HDL Enterprise Edition license.
If you are having trouble setting up your license, you can open a page that will show diagnostic information about the current license configuration.
This page can be opened by clicking on the license status bar item at the bottom of your window.
The main purpose of HDL languages is to describe a design to be synthesized and implemented in hardware. However, both VHDL and Verilog also provide additional features for writing verification code to check a design by simulating its behavior. In order to do so, you can write testbenches that provide stimulus to DUT inputs and assert whether their outputs have unexpected values. More sophisticated language constructs can be used to do more complex checks. The problem with such verification code is that it’s not synthesizable.
You should not use this verification subset of language features in an actual design. For better synthesis Quality of Results (QoR), you should also follow many other rules. However, since these rules only apply to a synthesizable design, there’s usually no need to restrict oneself to following them in verification code.
To provide better feedback, Sigasi Visual HDL (SVH) detects what parts of the code are supposed to be synthesizable and verifies synthesis rules for that code. In order to do so, it detects a description style for design units as one of the following:
Testbench - top level verification module
Behavioral - additional design units that are supposed to be used for verification purposes
RTL - design units that are part of an actual design to be synthesized
SVH allows you to specify a different severity for rules in RTL and non-RTL (testbench or behavioral) code.
It’s also possible to disable some checks for RTL or non-RTL code by setting the corresponding severity to ignore.
In VHDL, a description style is detected for every architecture, either by detecting verification code or based on architecture names.
The detecting verification code method is the default. In this case, an architecture is detected as:
Testbench, if the corresponding entity does not have any ports, otherwise
Behavioral, if it
contains non-synthesizable processes, e.g., no sensitivity list or multiple wait statements
uses the std.textio package or declares file types
RTL, in all other cases
This mechanism provides good results in most cases. However, if you require more fine-grained control, you can choose to detect the description style based on architecture names, in which case you have to specify name patterns to be matched against them. An architecture is then detected as:
RTL, if its name matches the valid pattern and does not match the invalid pattern, otherwise
Testbench, if the corresponding entity does not have any ports, or
Sigasi Visual HDL (SVH) license key management system is based on the well known FlexNet (a.k.a. FlexLM) license manager.
SVH supports both node-locked and floating license keys.
The SVH edition is controlled by the license key.
This section details the set-up of the license server when working with floating licenses.
The version of the FlexNet daemons must be equal or higher than the FlexLM version of SVH.
To find the required version in SVH, click on the SVH Disabled notification icon at the bottom right of the VS Code window.
Once you click that icon, a page named License will be opened. You can then check the required FlexNet version.
If you don’t see the SVH Disabled notification, right-click the same location at the bottom right of the VS Code Window,
and check the Sigasi for VHDL, Verilog & SystemVerilog (Extension) option.
By default, Sigasi license files use ports 27000 and 27001 on your license server.
If these ports are already in use on the server, you can change the port numbers in the license file.
The port of the Sigasi daemon is set on the DAEMON line. For example: DAEMON sigasi port=27001, forces the Sigasi daemon to use port 27001.
The port of the FlexNet daemon is set on the SERVER line For example: SERVER your_server_name1 BD41FCF5DE27 27000, forces FlexNet to use port 27000. This is the port clients need to use to check out a license.
You can change the port numbers and your_server_name1 without breaking the signature.
If you have a firewall, remember to open these ports for access.
Create a folder to hold the license manager software, in this example we will use D:\Sigasi\license.
Unpack the zip file into the license folder (D:\Sigasi\license)
Run the license configuration tool lmtools.exe as administrator.
Save the license file supplied for SVH to the license folder
Using a text editor, edit the license file and replace your_server_name1 with the name of the machine you are using, for example, from: SERVER your_server_name1 74e50bb0911e to: SERVER Maple 74e50bb0911e.
Note: If you are not sure of the name of the machine you are using, click on the System Settings tab of lmtools, where it is shown, see below:
Click on the Config Services tab and fill in the following, use the browse button when available:
Service Name: Sigasi License Manager
Path to lmgrd.exe: D:\sigasi\license\lmgrd.exe
Path to license file: D:\sigasi\license\sigasi.lic
Path to the debug log file: D:\sigasi\license\debug.logNote: You will probably need to type the “Path to the debug log file” in full as the file will not exist, so you cannot browse to it.
Ensure both the following boxes are checked:
Use Services
Start Server at Power Up
Now click the Save Service button, and click yes on the confirmation dialog.
Switch to the Start/Stop/Reread tab and start the server.
The license server should now be configured correctly and look a bit like this
If your floating license server does not function properly, try the following steps:
Start the FlexLM daemon with the -z option to see what is going wrong
Check that the FlexNet daemon is running as expected by following these steps:
Download the daemon zip file on the client machine
Run lmutil[.exe] lmdiag -c "<port>@<server>" -n
If the server is running correctly, you should see a description of the valid FlexNet features served by your license server.
Make sure the server name in the license key file is correct.
Make sure both the Sigasi and FlexNet daemon are the same version (i.e., from the same zip-file from the Sigasi download server). If you need to mix versions, the FlexNet daemon version should be equal to or higher than the Sigasi daemon version.
Firewall problems:
make sure that the port for the Sigasi FlexLM license daemon is open
you can force the port for the Sigasi license daemon by adding USE_SERVER and DAEMON sigasi port=<port number> to your license key
On Linux you might have to install lsb to avoid No such file or directory errors when starting lmgrd or other flexlm tools:
sudo apt-get install lsb-core
zypper in lsb
yum install lsb
yum install redhat-lsb.i686
If the installation of lsb-core fails (e.g., on Debian Linux 10), try this workaround (as root):
cd /lib64
ln -s ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
The lmgrd license manager needs to have write access to the /usr/tmp/ path. If your system doesn’t have a directory /usr/tmp, you can make a link to /tmp (as root):
ln -s /tmp /usr/tmp
Make sure there are no spaces in the daemon path.
Some users have reported that specifying an arbitrary absolute path for the Sigasi daemon on Windows (e.g., DAEMON sigasi C:\\sigasi.exe port=27021) does not work. It only works if the Sigasi daemon is in the C:\Sigasi folder.
Other users have reported that you are not allowed to have the directory name be the same as the daemon name. For example: c:\flexlm\sigasi\sigasi.exe is invalid, but c:\flexlm\vhdl_editor\sigasi.exe works fine.
Make sure the environment variable is correct: SIGASI_LM_LICENSE_FILE=<port number>@<servername>
Verify that your server meets the License Server System Requirements.
If you try to run the daemon on an unsupported version of Windows, you will typically see this error message: CreateProcess error code: 0xc1 File= sigasi.exe.
Check the status of your license via the License diagnostic page by clicking on the SVH Edition Status Bar item on the bottom of the window. At the bottom of this page, you can see the type and expiration date of your license.
If you are accessing your license server through an SSH tunnel, try using 127.0.0.1 instead of localhost.
SVH pre-emptively tries to check out certain license features. As a result, you might see warning messages like the one below in your server log. These messages can be safely ignored.
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.custom" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.preview" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
If the steps above do not help, feel free to send us an email
and send us a screenshot of the license dialog with the error message.
Did you correct the server name to the actual server name in the (floating) license key file?
Internal Flexlm Error
Check the version number of the FlexNet daemon, it is probably outdated. If not, check the daemon log on the license server.
Invalid Message Received From License Server
Check the daemon log on the license server
Updating DACL Failed: “Service has been created but failed to update the DACL settings of FlexNet Licensing Service. Accessing TS features will be problematic. Check whether FlexNet Licensing Service is correctly installed and delete and create this service again.”
There seems to be a bug in lmtools.exe version 11 on some systems. You can work around this issue by configuring the (latest) Sigasi daemon with an older version of lmtools. (Download here ).
(lmgrd) license manager: can’t initialize:No SERVER lines in license file.
(lmgrd) License Path: “C:\FlexLM\sigasi\license.dat”
(lmgrd) FlexNet Licensing error:-13,66
If you see this error message, double check whether your license file contains a line with USE_SERVER.
FLEXnet Error: “Exiting due to signal 32” (Exited because another server was running)
This error seems to be caused by running multiple instances of the same license server. If this is the case, first make sure to stop lmtools.exe, lmgrd.exe, and sigasi.exe. If the error continues to occur after stopping these processes, the real cause might be the name of the FlexLM folder.
If you installed the licensing software under the custom folder C:\FlexLM\, rename the folder to something else, such as C:\LMFlex\. After renaming the folder, also update the path that you set in the lmtools “Config Services” tab.
SystemVerilog has three specific always procedures: always_comb, always_latch and always_ff. These should be used in favor of general purpose always in synthesizable designs because:
they describe the intent of the always procedure
they provide semantics that improve readability
tools can additionally check for correctness concerning their behavior
Sigasi Visual HDL (SVH) reports generic always procedures as a warning.
module m (input clk);
always @(clk) begin
end
endmodule
SVH offers Quick Fixes to use a specific always procedure instead.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
VHDL bit strings include a base specifier followed by a string value.
The characters allowed in the value depend on the base specifier, with only a specific set permitted.
This linting rule detects string literals that are incorrectly defined.
The example below shows an incorrect value, the decimal bit string can only contain numerical characters.
entity alu is
port (
op : in std_logic_vector(3 downto 0) := D"1_1";
A, B : in std_logic_vector(3 downto 0);
result : out std_logic_vector(3 downto 0)
);
end alu;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Although VHDL is not case-sensitive, it is recommended to always use the same capitalization when referring to the same declaration. Sigasi Visual HDL warns when the capitalization of a reference differs from the capitalization of the declaration. Because external libraries can have different code styles, this linting only checks references in the same library as its declaration.
Capitalization can easily be fixed with a Quick Fix. All capitalization issues in a file can be fixed in one click.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check that each choice is specified only once in case and case generate statements as well as selected signal and variable assignments.
process is
variable state : std_logic_vector(2 downto 0) := "000";
constant IDLE : std_logic_vector := "110";
begin
case state is
when "000" => state := IDLE;
when "110" => state := "000";
when IDLE => state := "100";
end case;
end process;
Sigasi Visual HDL gives a warning if a component declaration is not equal to its matching entity. You can easily fix this by applying the Quick Fix.
entity dut is
port(
clk : in std_logic;
rst : in std_logic
);
end entity;
architecture RTL of dut is
component dut
port(
clk : in std_logic;
rst : in std_logic;
dbg : in std_logic
);
end component;
begin
end architecture;
component dut
port(
clk : in std_logic;
rst : in std_logic
);
end component;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check that header comments match specified patterns.
A header comment is a comment associated with a declaration or file.
A file header comment starts at the first character of the file (no leading whitespace).
Documentation Generation details how comments are associated with declaration.
For VHDL, Sigasi supports checking header comments on files, architectures, concurrent blocks,
configurations, contexts, entities, functions, package bodies, packages, package instantiations,
procedures, and processes.
For Verilog and SystemVerilog, only header comments on files are currently supported.
More information on header comment checking and naming conventions is available on the general Linting and Quick Fixes page.
Note that the entire comment is checked, including comment characters (-- or /* */).
These characters have to be handled by your patterns too.
Since Sigasi Studio 4.4, the raw string of the header comment is checked to allow for maximum compliance checking.
This means that when a new line is matched, users should use \r?\n or the newly introduced \R to make sure the naming conventions work on all platforms.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# Note: two patterns can be specified. These patterns are separated by a tab
# character. The first pattern specifies a *valid* pattern (something that must
# match), and the second pattern specifies an *invalid* pattern (something that
# can not match). If only a valid pattern is required, the tab character can
# be left out. If only an invalid pattern is required, the pattern should be
# specified after a (backslash-escaped) tab character.
# In the VHDL linting preferences file
188/severity/${path}={error|warning|info|ignore}
188/params/architecture_header_comment/${path}=${regex} ${regex}
188/params/comment_header/${path}=${regex} ${regex}
188/params/configuration_header_comment/${path}=${regex} ${regex}
188/params/context_header_comment/${path}=${regex} ${regex}
188/params/entity_header_comment/${path}=${regex} ${regex}
188/params/function_header_comment/${path}=${regex} ${regex}
188/params/package_body_header_comment/${path}=${regex} ${regex}
188/params/package_header_comment/${path}=${regex} ${regex}
188/params/package_instantiation_header_comment/${path}=${regex} ${regex}
188/params/procedure_header_comment/${path}=${regex} ${regex}
188/params/process_header_comment/${path}=${regex} ${regex}
188/params/concurrent_block_header_comment/${path}=${regex} ${regex}
# In the Verilog/SystemVerilog linting preferences file
22/severity/${path}={error|warning|info|ignore}
22/params/comment_header/${path}=${regex} ${regex}
To prevent issues during synthesis or static timing analysis, it’s important to use a signal that is used as a clock exclusively for that purpose, and not as e.g. reset or data. Sigasi Visual HDL will mark all instances where a clock signal is incorrectly used in this manner.
p : process (clk) is
variable data : std_logic_vector(15 downto 0);
begin
if rising_edge(clk) then
if rst = '1' then
...
else
data(8) := clk;
end if;
end if;
end process p;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Comparing vectors of different sizes can result in unexpected behavior, and should therefore be avoided. Sigasi Visual HDL will flag all comparisons of vectors whose ranges do not match. Note that potential mismatches will also be flagged when generics are used in one or both of the ranges, more information about such cases can be found in this article.
...
s_in : in std_logic_vector(WIDTH downto 0);
s_out : out std_logic_vector(7 downto 0);
...
if (s_in > s_out) then
...
...
s_in : in std_logic_vector(WIDTH downto 0);
s_out : out std_logic_vector(WIDTH downto 0);
...
if (s_in > s_out) then
...
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
You cannot have inheritance cycles with class declarations:
class A extends B; endclass
class B extends A; endclass
// this would introduce an infinite loop: A -> B -> A -> B ...
class A#(type T=int) extends T; endclass
class B extends A#(A#(B)); endclass
// this would introduce an infinite loop: B -> A#(A#(B)) -> A#(B) -> B ...
Dead code is code that does not have any effect on your simulation or
synthesis. Examples of dead code are signals that are never used or
conditions that are never triggered.
Dead code does not bother the simulator or the synthesis tool. However,
it consumes mental energy of anybody reading the code. People will try
to figure out the purpose of a given statement and it may take a while
before they realize that they are dealing with dead code. This makes it
more expensive to review code and reuse code. In general, dead code
is a form of technical debt that should be avoided.
Sigasi Visual HDL (SVH) flags some kinds of dead code:
Unused declarations (signals, constants …):
architecture RTL of empty is
signal unused_s : bit;
constant unused_c : bit := '0';
begin end;
A Quick Fix is available to help you remove unused declarations fast.
Unused ports and generics:
entity empty is
generic(unused_g : bit);
port (unused_p : in bit);
end entity;
architecture RTL of empty is begin end;
Unreachable statements: if the SVH analyzer can determine that a condition is always false,
it will mark the if-statement because it contains dead code:
if true then
v := v + 1;
elsev := v - 1;
end if;
Dead states in a state machine: a state is considered dead if it has no outgoing transitions:
type t_state is (IDLE, START, RUN, DONE);
signal state: t_state;
-- [omitted code]
case state is
when IDLE => -- do something
state <= RUN;
when RUN => -- do something
state <= DONE;
when DONE => -- do something
state <= IDLE;
when others => -- do nothing
end case;
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
55/severity/${path}={error|warning|info|ignore} # Unused declaration
67/severity/${path}={error|warning|info|ignore} # Unused ports
68/severity/${path}={error|warning|info|ignore} # Unused generics
71/severity/${path}={error|warning|info|ignore} # Dead states
79/severity/${path}={error|warning|info|ignore} # Dead code
Deeply nested conditional and loop statements reduce code readability. Restructuring code or extracting logic to functions can help to keep code in a maintainable state.
Another problem is that deep nesting can result in complicated prioritized logic being synthesized increasing circuit size significantly.
Sigasi Visual HDL can report deeply nested sequential loops and conditions. Note that this rule has the maximum nested depth set to 5 and is ignored by default. You can enable it in the Verilog Errors/Warnings settings page (Style Validation > Deep nesting of conditional and loop statements).
Example with a nesting limit of 2:
module m;
int x;
task foo();
x = 5;
if (x > 0) begin
if (x > 1) begin
if (x > 2) begin // nesting depth 2
if (x > 3) begin
$display("x is greater than 3");
end
end
end
end
endtask
endmodule
Example of conditional generate constructs with a nesting limit of 1:
module m;
if (0)
if (1)
begin
// do something
end
else if (2)
begin
// do something
end
else ; // empty
endmodule
Example A long chain of else-if constructs does not count as nesting even though it technically is, because it’s very readable and commonly used:
module m;
always_comb
begin
if (1) $display(1);
else if (2) $display(2);
else if (3) $display(3);
else if (4) $display(4);
else if (5) $display(5);
else if (6) $display(6);
else if (7) $display(7);
end
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Deeply nested conditional and loop statements reduce code readability. Restructuring code or extracting logic to functions can help to keep code in a maintainable state.
Another problem is that deep nesting can result in complicated prioritized logic being synthesized increasing circuit size significantly.
Sigasi Visual HDL can report deeply nested sequential loops and conditions. Note that this rule has the maximum nested depth set to 5 and is ignored by default. You can enable it in the VHDL Errors/Warnings settings page (Style Validation > Deep nesting of conditional and loop statements).
Example with a nesting limit of 2:
procedure nested(a : natural) is
begin
if a >= 1 then -- nesting depth 0
if a < 42 then -- nesting depth 1
for I in 0 to 1 loop -- nesting depth 2
case a is -- Statement exceeds conditional and loop nesting limit of 2
when 21 => report integer'image(a) severity note;
when others => null;
end case;
end loop;
end if;
end if;
end procedure nested;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
239/severity/${path}={error|warning|info|ignore}
239/params/limit/${path}=${integer} # at least 1
Deprecated IEEE Packages and Non-Standard Packages
Some packages are widely spread but were never standardized by IEEE.
Different vendors have shipped different versions, with incompatible
implementations. These packages should not be used and are flagged as
Deprecated IEEE packages.
use ieee.std_logic_arith.all
use ieee.std_logic_signed.all
use ieee.std_logic_unsigned.all
Instead, use the standard ieee.numeric_std package.
use ieee.numeric_std.all
The package ieee.std_logic_misc has the same problem of not being standardized by IEEE. Contrary to the packages above, there is no consensus on how to replace this package. Sigasi Visual HDL flags this package as Non-standard package.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# For deprecated IEEE packages
8/severity/${path}={error|warning|info|ignore}
# For Non-standard packages
37/severity/${path}={error|warning|info|ignore}
The UVM library evolves and while new features are added to its API, some other features are marked as deprecated. Using deprecated features is discouraged as they are supposed to be removed in future UVM versions. Sigasi Visual HDL marks all usages of deprecated API: macros, classes, methods, public fields, etc:
class my_sequence extends uvm_sequence #(my_sequence_item);
`uvm_object_utils(my_sequence)
function new(string name = "my_sequence");
super.new(name);
do_not_randomize = 1; // UVM declaration 'uvm_pkg::uvm_sequence_base::do_not_randomize' is deprecated
endfunction
task body();
`uvm_do_with(req, {req.size < 32;}) // UVM macro 'uvm_do_with' is deprecated
endtask
endclass
By default, API features deprecated in the UVM library version you are using are reported. However, it’s possible to configure the rule to report features deprecated in future UVM versions as well.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Verilog allows specifying the same signal multiple times in a sensitivity list, but in most cases this is an oversight and the duplicate should be removed.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
End names are a feature introduced with SystemVerilog. In Verilog files (files that have a .v suffix or that are explicitly configured to be treated as Verilog), using end names is not allowed.
In a verilog file:
module main;
endmodule : main
A Quick Fix is offered for this error which can remove the illegal end name.
Sigasi Visual HDL can check that the filename contains the name of at least one of the design unit names inside that file. Note that this check is ignored by default. You can enable it in the VHDL Errors/Warnings settings page (Style Validation > Filename must contain primary name).
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
SystemVerilog function prototypes (pure virtual functions) should have a return type. SVH warns for function prototypes without return type (rule 10).
virtual class badclass;
pure virtual function myfunc(input bit[31:0] data); // return type missing
endclass
virtual class goodclass;
pure virtual function integer myfunc(input bit[31:0] data);
endclass
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
10/severity/${path}={error|warning|info|ignore} # Function prototype with implicit return type
When a vector signal is used as a conditional expression or as an argument to logical operators (e.g. &&, ||, !) it’s implicitly converted to scalar value 0 (false) if all vector bits are zero or to 1 (true) otherwise. It’s not clear in this case if such conversion was intentional or by mistake, and a scalar type or bitwise operator, such as &, |, or ~ was expected.
module ff(input clk, [7:0] d, rst, output [7:0] q);
always_ff @(posedge clk) begin
if (rst) // Implicit conversion of 'logic [7:0]' to boolean
q <= 0;
else
q <= !d; // Implicit conversion of 'logic [7:0]' to boolean
end
endmodule
It may be better to explicitly compare the vector with zero (vec == 0 or vec != 0) if that’s your intent.
Note that this rule is disabled (set to IGNORE) by default.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog, it is discouraged to include files that have globally scoped top-level declarations (e.g. modules, user-defined primitives).
Given the files f1.sv and f2.sv, whose content is, respectively, as follows:
module f1();
endmodule : f1
class f2;
endclass : f2
Includes of f1.sv would be marked.
`include "f1.sv"
`include "f2.sv"
Transitive includes are not highlighted. If there is a file f3.sv that includes f1.sv, the include of f1.sv in f3.sv would be highlighted, but includes of f3.sv would show no warnings.
By default, included files that contain top-level packages are not reported. However, it’s possible to configure the rule to report such include statements.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL (SVH) warns about incomplete port maps, generic maps, and parameters in an argument list:
Port map uses default values. Missing optional actuals: yourport
Input ports, generics and parameters need to be assigned in your instantiation
statement if they don’t already have a default value. If you don’t do
this, you are writing illegal VHDL. SVH will mark an error, and so
will all other tools.
Input ports, generics and parameters with a default value, as well as output ports,
do not need to be assigned explicitly. However, this is often not
intended. For that reason, SVH can warn you about this.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
A reset branch should always reset all registers modified by the corresponding clocked block. An incomplete reset branch could cause unexpected enable or clock gating logic to be synthesized for the registers that were not reset. Sigasi will let you know if a reset branch is incomplete, and what registers are missing.
p : process (clk) is
variable a: integer;
variable b: integer;
variable c: integer;
begin
if rising_edge(clk) then
if rst = '1' then -- c is not reset
a := 0;
b := 0;
else
a := a + 1;
b := b + 2;
c := c + 3;
end if;
end if;
end process p;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check that the same clock edge is used throughout the entire design. It provides a clean coding style simplifying maintainability and enhancing safety. If using a single edge is too restrictive, this rule can be configured to check the clock edge usage consistency for each design file. This rule consists of three check types:
rising, ensures that all clock edges are rising edges
falling, ensures that all clock edges are falling edges
consistent, adapts the rule to the most used edge per design file. If there are equal amounts of rising and falling edges, the first encountered edge will be chosen
The default configured type is consistent, but this can be changed in the Errors/Warnings project settings.
Example with rising edge selected
process(clk) is
variable count : natural := 0;
begin
if rising_edge(clk) then
count := count + 1;
end if;
if falling_edge(clk) then -- Inconsistent!
count := count - 1;
end if;
end process;
Note that this rule also works with the old-school clock edge condition:
process(clk) is
variable count : natural := 0;
begin
if clk'event and clk = '1' then
count := count + 1;
end if;
if clk'event and clk = '0' then -- Inconsistent!
count := count - 1;
end if;
end process;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
There are two types of resets for a synchronous design, synchronous resets and asynchronous resets. It can be good practice to consistently use only one of these throughout a project. This rule can be configured to prefer either a synchronous or asynchronous reset style and will mark all reset branches that do not follow the selected style.
For example, if the validation is configured to prefer a synchronous reset style:
async_p : process (clk, rst) is
begin
if rst = '1' then
...
elsif rising_edge(clk) then
...
end if;
end process async_p;
sync_p : process (clk) is
begin
if rising_edge(clk) then
if rst = '1' then
...
else
...
end if;
end if;
end process sync_p;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
UVM objects and components must declare an explicit constructor that follows a certain format:
for UVM objects the first argument of the constructor must be string name, and all arguments must be optional.
for UVM components the first two arguments of the constructor must be string name and uvm_component parent, and all additional arguments must be optional.
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
// The following incorrect constructor will be implied:
// function new();
// super.new();
// endfunction
endclass
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
// The constructor does not have the correct arguments
function new(int parent, string name);
super.new(name, parent);
endfunction
endclass
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
// The additional argument is not optional
function new(string name, uvm_object parent, int i);
super.new(name, parent);
endfunction
endclass
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
function new(string name, uvm_object parent, int i = 0);
super.new(name, parent);
endfunction
endclass
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When overriding UVM objects or components, the original type shall be a superclass of the override type. Sigasi Visual HDL warns you on attempts to override UVM objects by type when this condition is not met:
class base_object extends uvm_object;
`uvm_object_utils(base_object);
// ...
endclass
class my_object extends base_object;
`uvm_object_utils(my_object);
// ...
endclass
class my_component extends uvm_component;
`uvm_component_utils(my_component)
virtual function void build_phase(input uvm_phase phase);
// Incorrect override of UVM object 'class base_object': expected derived class but was 'class my_component'
uvm_factory::get().set_type_override_by_type(base_object::get_type(), my_component::get_type());
uvm_factory::get().set_type_override_by_type(base_object::get_type(), my_object::get_type());
// Incorrect override of UVM object 'class my_object': expected derived class but was 'class base_object'
my_object::type_id::set_type_override(base_object::get_type());
base_object::type_id::set_type_override(my_object::get_type());
endfunction
endclass
Note, that overrides by name (e.g. set_type_override("packet", "huge_packet")) are not checked by this rule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Using the factory to create UVM objects and components instead of allocating them directly (via new) allows the type of an object to be determined at run time rather than at compile time and hence to be overridden without modifying the requesting class.
Instantiations should take the form:
my_obj=my_type::type_id::create("my_obj");
This increases reusability of your verification components:
class my_agent extends uvm_agent;
`uvm_component_utils(my_agent)
my_sequencer m_sequencer;
my_driver m_driver;
my_monitor m_monitor;
function void build_phase(uvm_phase phase);
// Incorrect instantiation of UVM object 'my_sequencer', use the factory instead
m_sequencer = new("m_sequencer", this);
// Incorrect instantiation of UVM object 'my_driver', use the factory instead
m_driver = my_driver::new("m_driver", this);
m_monitor = my_monitor::type_id::create("m_monitor", this);
endfunction
endclass
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
VHDL allows arrays with both ascending (to) and descending ranges (downto). For vectors (one-dimensional arrays of scalars, e.g. bit or (u)logic) using a descending range is recommended. In this case leftmost bit is the MSB and the rightmost bit is the LSB, and that is what is assumed by the VHDL standard library’s arithmetic operators. Using an ascending range for vectors is also possible, however, it’s recommended to use a consistent style.
entity Downto_vectors is
port(
G0_g : bit_vector(0 to 7);
G1_g : bit_vector(7 downto 0);
);
end entity Downto_vectors;
This rule can be configured by setting the desired vector range direction, either ascending or descending.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Attributes can be restricted using a list of attributes that cannot be used (rule 244). These attributes can be configured in two modes: deny and allow, and can also include checks for user-defined attributes. For example:
Check attributes in deny mode (event and value denied)
architecture RTL of prohibited_attribute is
begin
a : process is
type myEnum is (a, b, c, d);
constant constB : myEnum := myEnum'value("b"); -- Attribute 'value' is prohibited
begin
if clk'event then -- Attribute 'event' is prohibited
report "event" severity note;
end if;
if clk'low = '1' then -- Attribute 'low' is allowed
report "low" severity note;
end if;
end process a;
end architecture RTL;
Check attributes in allow mode (event allowed)
architecture RTL of allowed_attribute is
begin
a : process is
type myEnum is (a, b, c, d);
constant constB : myEnum := myEnum'value("b"); -- Attribute 'value' is prohibited
begin
if clk'event then -- Attribute 'event' is allowed
report "event" severity note;
end if;
end process a;
end architecture RTL;
Libraries can be restricted using a list of denied or allowed libraries that will be reported in the use clause (rule 248). Using the current work library is always allowed regardless of configuration. For example:
Packages can be restricted using a list of denied or allowed packages that will be reported in the use clause (rule 246). Using packages from the work library or the current work library is always allowed regardless of configuration. For example:
Check packages in deny mode (ieee.numeric_std and work.user_package denied)
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all; -- Package 'numeric_std' is prohibited
use work.user_package.all; -- Ignored because work
Check packages in allow mode (ieee.numeric_std and work.user_package allowed)
library ieee;
use ieee.std_logic_1164.all; -- Package 'std_logic_1164' is prohibited
use ieee.numeric_std.all;
use work.user_package.all; -- Ignored because work
Check packages in denied mode, with the current file mapped to the library memory(memory.ram_cell denied)
library ieee, memory;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use memory.ram_cell.all; -- Ignored because mapped to the same library
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
When SVH encounters a reference to a library that is not available in the working environment, perhaps owing to a typo in the library name or a missing configuration, a problem is reported.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check for a number of array / vector index-related problems:
Index out of range (rule 210).
architecture RTL of array_range_check is
signal foo: bit_vector(7 downto 0);
signal bar, baz: bit;
begin
bar <= foo(8); -- 8 is out of range "7 downto 0"
baz <= foo(7);
end architecture RTL;
Slice has wrong direction (rule 211).
Slice ranges must use the same direction as the vector.
architecture RTL of array_range_check is
constant iterations : integer := 8;
signal foo: bit_vector(7 downto 0);
signal bar, baz: bit_vector(0 to 7);
begin
bar <= foo(0 to 7); -- foo has a downto range
baz <= foo;
end architecture RTL;
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
A deferred constant cannot reassign its initial value to a different value (rule 54).
package pkg is
constant foo : integer := 2;
constant bar : boolean;
end package;
package body pkg is
constant foo : integer := 3; -- foo was already assigned a value
constant bar : boolean := false;
end package body;
If a constant declaration in a package has no initial value, it shall have a deferred constant declaration in the package body with a matching initial value (rule 233).
package pkg is
constant a : integer;
constant b, c : boolean;
end package;
package body pkg is
constant a : integer := 3;
constant b : boolean := false; -- c was not assigned a value
end package body;
The type of a deferred constant declaration in the package body must match the type of the constant declaration in the package (rule 234).
package pkg is
constant foo : boolean;
constant bar : integer;
end package;
package body pkg is
constant foo : integer := 8; -- foo was declared as a boolean in the package
constant bar : integer := 7;
end package body;
It can be good practice to separate the primary units in a design and declare them in separate files.
Similarly, guidelines exist for where secondary units should be declared in relation to other secondary units or to their corresponding primary unit.
Sigasi Visual HDL can enforce where design units are defined in relation to other design units.
Secondary units are more flexible. Sigasi can suggest to put them either
in the same file as their corresponding primary unit, or in a separate
file (or not check them at all). You can configure this separately
for the architecture of entities with a single architecture, for the
architectures of an entity with multiple architectures, and for package
bodies.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# Primary unit location
242/severity/${path}={error|warning|info|ignore}
# Secondary unit location
243/severity/${path}={error|warning|info|ignore}
243/params/single_architecture/${path}={same_file_as_primary|separate_file|ignore}
243/params/multiple_architectures/${path}={separate_file|same_file_as_primary|ignore}
243/params/package_body/${path}={separate_file|same_file_as_primary|ignore}
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
Locally unused port, argument or parameter declaration
A port, parameter or argument declaration that is never used locally, does not contribute anything to a design and can be an indication of a coding error.
module my_module#(parameter A = 10, B = 20)(logic input unused_port, logic input used_port);
initial $display(B);
wire logic p = (used_port);
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Missing include path in preprocessor configuration
Sigasi attempts to automatically resolve missing Include Paths.
The `include directives that include files that are not explicitly in the Include Paths are marked with a warning.
module hello_world;
import uvm_pkg::*;
`include "uvm_macros.svh" // Preprocessor include paths are not configured correctly
class packet extends uvm_transaction;
int addr;
`uvm_object_utils_begin(packet)
`uvm_field_int(addr, UVM_ALL_ON)
`uvm_object_utils_end
constraint c { addr >= 0 && addr < 'h100; }
function new(string name="packet");
super.new(name);
endfunction
endclass
endmodule
It is highly recommended that you fix these problems to ensure a correct include path order.
This can easily be done by the accompanying Quick Fix Add include path '[...]' to configuration.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check the presence of labels, end names, and end labels in the code for all kinds of statements. While labels add a distinctive identity to statements and improve readability, end names and end labels make it easier to determine which declaration or statement is closed when bodies are long or when multiple nested constructs are ending simultaneously.
Example with a small register bank where every statement needs a label, end name, and end label
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity register_bank is
port(
clk : in std_logic;
write : in std_logic;
reg_addr : in natural;
reg_load : in std_logic_vector(7 downto 0);
reg_out : out std_logic_vector(7 downto 0)
);
end entity; -- Missing end name
architecture RTL of register_bank is
type reg_bank_t is array (15 downto 0) of std_logic_vector(7 downto 0);
signal reg_bank : reg_bank_t;
begin
process(clk) is -- Missing label (and end label)
begin
if rising_edge(clk) and write = '1' then -- Missing label (and end label)
reg_bank(reg_addr) <= reg_load; -- Missing label
end if;
end process;
reg_out <= reg_bank(reg_addr); -- Missing label
end architecture; -- Missing end name
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity register_bank is
port(
clk : in std_logic;
write : in std_logic;
reg_addr : in natural;
reg_load : in std_logic_vector(7 downto 0);
reg_out : out std_logic_vector(7 downto 0)
);
end entity register_bank;
architecture RTL of register_bank is
type reg_bank_t is array (15 downto 0) of std_logic_vector(7 downto 0);
signal reg_bank : reg_bank_t;
begin
reg_write : process(clk) is
begin
check_clk_write : if rising_edge(clk) and write = '1' then
write_reg : reg_bank(reg_addr) <= reg_load;
end if check_clk_write;
end process reg_write;
read_reg : reg_out <= reg_bank(reg_addr);
end architecture RTL;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When declaring a mode view, all elements of the associated record must be given a mode. If any are missing, Sigasi Visual HDL will flag this as an error (rule 257). A quickfix will be offered to add the missing elements as in, out, or inout.
type data_record is record
data_a : std_logic_vector(1 downto 0);
data_b : std_logic_vector(3 downto 0);
data_c : std_logic_vector(7 downto 0);
end record data_record;
view incomplete_view of data_record is
data_a : in;
data_b : out;
-- no mode for data_c
end view incomplete_view;
view complete_view of data_record is
data_a : in;
data_b : out;
data_c : out;
end view complete_view;
It is advised not to use multiple-object declarations. It’s better to split declared objects into an equivalent sequence of single-object declarations instead. This practice enhances readability and makes it easier to manage and maintain your code.
Sigasi Visual HDL warns the user when multiple objects are declared within a single declaration.
entity t is
generic(
DATA_WIDTH, ADDR_WIDTH: integer
);
port(
a: in std_logic(DATA_WIDTH - 1 downto 0); -- first operand
b: in std_logic(DATA_WIDTH - 1 downto 0) -- second operand
);
end entity t;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Using names that differ only by case is not desirable, even if this is valid in Verilog. This can be confusing, or it may have been a mistake on the part of the original developer.
Avoiding such mistakes improves readability, prevents potential issues, and encourages a good style.
Sigasi Visual HDL can report this as a warning.
class my_class;
// class definition
endclass
class MY_CLASS;
// class definition
endclass
module m;
int abc = 1;
int Abc = 1;
int ABC = 1;
int s = abc + Abc + ABC;
$display("Sum = %0d", s);
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Naming Conventions allow you to configure
patterns to check the correct naming of your VHDL, Verilog, and SystemVerilog identifiers.
Two patterns can be set for an identifier: a valid pattern that the name of the identifier should match, and an invalid pattern that the name shouldn’t match.
An identifier has to fulfill both conditions, so a name that matches both patterns is not valid.
Patterns are configured using regex syntax .
Only names with a specified pattern are checked. Empty patterns are omitted.
Example: to enforce a style where all variables have a _v suffix, and don’t contain numbers,
you would specify .*_v for the valid pattern and .*[0-9].* for the invalid pattern in the Variable name field.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# Note: two patterns can be specified. These patterns are separated by a tab
# character. The first pattern specifies a *valid* pattern (something that must
# match), and the second pattern specifies an *invalid* pattern (something that
# can not match). If only a valid pattern is required, the tab character can
# be left out. If only an invalid pattern is required, the pattern should be
# specified after a (backslash-escaped) tab character.
# In the VHDL linting preferences file
92/severity/${path}={error|warning|info|ignore}
92/params/alias_name/${path}=${regex} ${regex}
92/params/architecture_name/${path}=${regex} ${regex}
92/params/comment_header/${path}=${regex} ${regex}
92/params/concurrent_assignment_name/${path}=${regex} ${regex}
92/params/configuration_name/${path}=${regex} ${regex}
92/params/constant_name/${path}=${regex} ${regex}
92/params/context_declaration/${path}=${regex} ${regex}
92/params/entity_name/${path}=${regex} ${regex}
92/params/enumeration_literal_name/${path}=${regex} ${regex}
92/params/file_name/${path}=${regex} ${regex}
92/params/fsm_enumeration_literal_name/${path}=${regex} ${regex}
92/params/fsm_state_name/${path}=${regex} ${regex}
92/params/function_name/${path}=${regex} ${regex}
92/params/generate_statement_name/${path}=${regex} ${regex}
92/params/generic_name/${path}=${regex} ${regex}
92/params/instantiation_statement_name/${path}=${regex} ${regex}
92/params/label/${path}=${regex} ${regex}
92/params/package_name/${path}=${regex} ${regex}
92/params/procedure_name/${path}=${regex} ${regex}
92/params/port_name/${path}=${regex} ${regex}
92/params/input_port_name/${path}=${regex} ${regex}
92/params/output_port_name/${path}=${regex} ${regex}
92/params/inout_port_name/${path}=${regex} ${regex}
92/params/process_statement_name/${path}=${regex} ${regex}
92/params/signal_name/${path}=${regex} ${regex}
92/params/type_name/${path}=${regex} ${regex}
92/params/variable_name/${path}=${regex} ${regex}
# In the Verilog linting preferences file
2/severity/${path}={error|warning|info|ignore}
2/params/class_name/${path}=${regex} ${regex}
2/params/comment_header/${path}=${regex} ${regex}
2/params/macro_name/${path}=${regex} ${regex}
2/params/instantiation/${path}=${regex} ${regex}
2/params/interface_class_name/${path}=${regex} ${regex}
2/params/interface_name/${path}=${regex} ${regex}
2/params/module_name/${path}=${regex} ${regex}
2/params/package_name/${path}=${regex} ${regex}
2/params/program_name/${path}=${regex} ${regex}
2/params/subprogram_name/${path}=${regex} ${regex}
2/params/function_name/${path}=${regex} ${regex}
2/params/task_name/${path}=${regex} ${regex}
2/params/port_name/${path}=${regex} ${regex}
2/params/input_name/${path}=${regex} ${regex}
2/params/output_name/${path}=${regex} ${regex}
2/params/inout_name/${path}=${regex} ${regex}
2/params/parameter_name/${path}=${regex} ${regex}
2/params/parameter_type_name/${path}=${regex} ${regex}
2/params/struct_name/${path}=${regex} ${regex}
2/params/union_name/${path}=${regex} ${regex}
2/params/net_name/${path}=${regex} ${regex}
2/params/var_name/${path}=${regex} ${regex}
2/params/ud_nettype_name/${path}=${regex} ${regex}
2/params/typedef_name/${path}=${regex} ${regex}
2/params/enum_typedef_name/${path}=${regex} ${regex}
2/params/enum_member_name/${path}=${regex} ${regex}
2/params/generate_block_name/${path}=${regex} ${regex}
2/params/fsm_state_name/${path}=${regex} ${regex}
2/params/constraint_name/${path}=${regex} ${regex}
A manual VHDL configuration where all ports must start with p_
except inout ports which must start with b_,
and where input ports cannot contain numbers.
We mark the ports with error markers if they don’t comply.
Non-blocking assignments are not allowed in functions
A non-blocking assignment (<=) is not allowed in Verilog (2005) functions.
SystemVerilog (2017) does allow non-blocking assignments in functions, but only in specific contexts.
A function with non-blocking assignments can only be called in initial procedures, always procedures, and in a context
where a side effect is allowed. Ensuring these conditions are met is not straightforward.
On top of this, they can make the design harder to understand.
Sigasi Visual HDL (SVH) flags an error if a non-blocking assignment is used in a Verilog function (rule 41), and can optionally
flag a problem for the same issue in SystemVerilog functions (rule 171, disabled by default).
A good fix to correct the problem is to replace non-blocking assignments (<=) with blocking assignments (=)
module badcode;
function plus_one;
input integer a;
begin
plus_one <= a + 1; // Incorrect: non-blocking assignment
end
endfunction
endmodule
module goodcode;
function plus_one;
input integer a;
begin
plus_one = a + 1; // Correct: blocking assignment
end
endfunction
endmodule
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
171/severity/${path}={error|warning|info|ignore} # Non-blocking assignments in functions
Each VHDL component must be matched with a corresponding entity, either based on its name and interface or through a configuration.
When SVH encounters a component that cannot be linked to any entity, or a component that is linked to multiple entities, an issue is reported.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# For ascending ranges
1/severity/${path}={error|warning|info|ignore}
# For descending ranges
26/severity/${path}={error|warning|info|ignore}
Sigasi Visual HDL gives a warning when the order of generics, ports, or parameters in a map or subprogram argument list differs from their original declaration order.
architecture RTL of dut is
component my_comp port (
clk : in std_logic;
rst : in std_logic;
inp : in std_logic;
outp : out std_logic);
end component;
begin
assert iterations <= MAX_COUNT;
i_comp_1: my_comp port map( -- associations should be kept in the same order as the declaration
rst => rst,clk => clk,
inp => data_in(0),
outp => open
);
i_comp_1: my_comp port map(
clk => clk,rst => rst,
inp => data_in(0),
outp => open
);
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Most VHDL designers prefer using named associations in port maps, generic maps, and parameter lists in instantiations. This makes it a lot easier to spot wrong connections.
Sigasi Visual HDL provides a linting rule that checks whether positional associations are used. This rule is disabled by default, but you can change the severity of this check on the Errors/Warnings settings page in the Style validation section.
architecture RTL of dut is
component my_comp port (
clk : in std_logic;
rst : in std_logic;
inp : in std_logic;
outp : out std_logic);
end component;
begin
i_comp_1: my_comp port map( -- positional associations not recommended
clk,rst,data_in(0),open
);
i_comp_2: my_comp port map( -- named associations recommended
clk => clk,rst => rst,inp => data_in(0),outp => open
);
end architecture RTL;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When using both Linux and Windows for design development, it’s easy to end up with files that have different end of line sequences:
CRLF in HDL files created on Windows
LF in HDL files created on Linux
You can change the configuration of this rule to enforce a style throughout your Verilog code base.
A similar rule exists for VHDL files as well.
Whenever SVH detects a file with line endings that are not allowed by this rule, a corresponding issue is reported.
SVH also provides a Quick Fix to change end of line sequences in this file, or in all Verilog files in the project.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When using both Linux and Windows for design development, it’s easy to end up with files that have different end of line sequences:
CRLF in HDL files created on Windows
LF in HDL files created on Linux
You can change the configuration of this rule to enforce a style throughout your VHDL code base.
A similar rule exists for Verilog files as well.
Whenever SVH detects a file with line endings that are not allowed by this rule, a corresponding issue is reported.
SVH also provides a Quick Fix to change end of line sequences in this file, or in all VHDL files in the project.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Some macros might be deprecated, or their use might be discouraged by certain guidelines. This check can be configured with a list of prohibited macros, all uses of these macros will be flagged as a warning.
For example, if the size macro is configured to be prohibited:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
If a case statement contains all the possible choices (usually in an
enumerated datatype), you can safely remove the when others clause.
Sigasi Visual HDL warns about this:
Unexpected ‘others’ choice, case statement covers all choices explicitly
case bits is
when "00" => -- code
when "01" => -- code
when "10" => -- code
when "11" => -- code
when others => -- never reached: all cases are covered
end case;
There is some debate on this coding rule. However, the vast majority of
synthesis tools do not take the others into account if all choices are
enumerated. If the synthesis tool is set up to generate fault-tolerant
hardware, the fallback state is the same as the reset state (for most
synthesis tools). Check the manual of your synthesis tools and run some
experiments.
For more information, see VHDL case statements can do without the “others”.
If you still prefer to always have an others choice for case statements, the validation can be configured to Always require 'others' choice. When configured this way, there will be warnings on all case statements that do not have an others choice, even if that choice would be redundant.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
A sensitivity list should only contain signals the process is sensitive to. Adding duplicate signals is likely a typo and doesn’t have any practical effect.
process(a, b, b)
begin
c <= a and b;
end process;
A sensitivity list should contain all signals that are read
asynchronously in the process. For a combinatorial process, all
signals read by the process should be in the sensitivity list. For a
synchronous or clocked process, only the clock signal and an
asynchronous reset signal (if present) should be in the sensitivity
list. In synthesizable code, an incomplete sensitivity list will
likely cause a synthesis-simulation mismatch. Even in test benches and
purely behavioral code, an incomplete sensitivity list is often
unintended and may lead to an unexpected simulation result. Most
synthesis tools ignore the sensitivity list. In traditional workflows,
only the synthesis warnings will give you a hint that your sensitivity
list is incomplete. This report will be available only hours or even
days after you have finished typing your code. Flagging this problem
early can save a lot of time.
Since VHDL-2008, you can write process (all) to make sure you have
all the necessary signals in the sensitivity list.
process(a, b)
begin
c <= a and b;
end process;
process(clk)
begin
if rising_edge(clk) then
-- code
end if;
end process;
process(clk, rst)
begin
if rst = '1' then
-- reset code
elsif rising_edge(clk) then
-- code
end if;
end process;
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
38/severity/${path}={error|warning|info|ignore} # Neither sensitivity nor wait
72/severity/${path}={error|warning|info|ignore} # Incomplete sensitivity list
73/severity/${path}={error|warning|info|ignore} # Superfluous signals
85/severity/${path}={error|warning|info|ignore} # Duplicate signals
Signals and variables that are written but never read are indicative of redundant code, potential logic errors, or inefficiencies in the design. This linting rule detects signals or variables that are never read, as illustrated in the example below.
architecture rtl of example is
signal unread_signal : std_logic;
begin
process (clk)
begin
if rising_edge(clk) then
unread_signal <= '1'; -- Written, but never read
end if;
end process;
end architecture;
architecture rtl of example is
begin
process (clk)
variable unread_variable : integer := 0;
begin
if rising_edge(clk) then
unread_variable := 42; -- Assigned, but never used
end if;
end process;
end architecture;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Signals and variables that are read but never assigned a value are indicative of bugs, incomplete logic, or inefficiencies in the implementation. This linting rule detects signals or variables that are never written, as illustrated in the example below.
architecture rtl of example is
signal unwritten_signal : std_logic;
begin
process(unwritten_signal)
begin
if unwritten_signal = '1' then -- Read but never assigned
report "Signal is high";
end if;
end process;
end architecture;
architecture rtl of example is
begin
process (clk)
variable unwritten_variable : integer;'
begin
if rising_edge(clk) then
if unwritten_variable = 10 then -- Read but never assigned
report "Variable is 10";
end if;
end if;
end process;
end architecture;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
If you type a numeric literal with a physical unit, there should be a
space between the number and the unit.
T := 25ns; -- ILLEGAL, but accepted by ModelSim
T := 25 ns; -- OK; according to VHDL language standard
Mentor Graphics’ ModelSim and QuestaSim accept the former (illegal)
version. As a result, some VHDL designers got used to writing the
incorrect version, producing code that is not portable to other
simulators. Sigasi Visual HDL accepts the ModelSim-style physical literals
but warns about this (rule 47).
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Every design unit except package STANDARD is assumed to contain the following implicit context items as part of its context clause:
librarySTD,WORK;useSTD.STANDARD.all;
Hence, any extra library statement in your VHDL code that includes
STD or WORK is pointless, as is any use clause that includes
std.standard.all. Hardly anybody would type the use clause, but
quite some people start all of their files with two extra library
clauses.
It is good practice not to include use clauses for libraries STD and WORK. Sigasi Visual HDL flags as warning if they appear.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Clocked processes in VHDL are primarily used to describe registers. However, it’s also possible to describe combinational logic in front of these registers. While it is beneficial to reset registers, there is no need to reset signals and variables that describe combinational logic. By default, Sigasi Visual HDL reports superfluous resets in RTL code only.
In the following example, the combinational variable nd is reset together with reg register:
inv : process(clk, rst) is
variable d_reg, nd : std_logic;
begin
if rst = '1' then
reg := '0';
nd := '0';
else
if rising_edge(clk) then
nd := not d;
reg := nd;
end if;
end if;
q <= reg;
end process inv;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Using tab characters (\t) for indentation or spacing in source files can cause inconsistency in the style of formatting. When enabled, this linting rule reports the use of tab characters.
entity example is
port(
clk : in std_logic;
rst : in std_logic
);
end entity example;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When using booleans, it is unnecessary to test whether they’re equal to true (rule 185) or false (rule 186). Simply testing the boolean results in cleaner code.
signal valid: boolean;
-- some code omitted
if valid then
-- ...
end if;
if valid = true then
-- ...
end if;
if not valid then
-- ...
end if;
if valid = false then
-- ...
end if;
if valid /= true then
-- ...
end if;
Note that the equals-false rule (186) is disabled (set to IGNORE) by default.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
Different EDA tools have extended the Verilog and SystemVerilog
standard in diverging ways. To maximize tool compatibility, Sigasi
allows some constructs not included in the standards. The linting rules
listed below mark the usage of such constructs as a warning, which can
be disabled individually if you use a tool that allows a particular
construct.
Some directives and escape sequences such as `` and
`" can only be used inside the body of a macro definition.
Some tools are however more lenient, allowing them also elsewhere.
var asdf = `"asdf"; // Unexpected `" directive outside macro body
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
117/severity/${path}={error|warning|info|ignore} # Whitespace following a backtick
121/severity/${path}={error|warning|info|ignore} # Invalid preprocessor syntax
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL flags an error if a type is used in an expression (rule 209).
architecture RTL of type_in_expr is
type t_foo is (one, two);
begin
p : process is
begin
case t_foo is -- a type cannot be used in an expression e.g. a case expression
when one =>
end case;
end process p;
end architecture RTL;
architecture RTL of type_in_expr is
type t_foo is (one, two);
signal s_foo: t_foo;
begin
p : process is
begin
case s_foo is -- use a signal or variable of the required type in expressions
when one =>
end case;
end process p;
end architecture RTL;
Omitting explicit bindings for component instantiations in VHDL configurations can introduce ambiguity and errors into your design, making the source code harder to read and maintain. Explicitly binding component instantiations clarifies the intended design hierarchy and helps ensure correct component usage.
This linting rule identifies component instantiations in VHDL configurations that do not have explicit bindings.
architecture rtl of processor is
component alu is
port (
op : in std_logic_vector(1 downto 0);
A, B : in std_logic_vector(7 downto 0);
result : out std_logic_vector(7 downto 0)
);
end component;
begin
U1: alu port map (
op => op,
A => A,
B => B,
result => result
);
end rtl;
configuration cfg_processor_behavioral of processor is
for rtl
end for;
end cfg_processor_behavioral;
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In VHDL, it is good practice to constrain integer types (or types derived from integer types) when they are used for signals. Doing so will allow the synthesis tool to optimize the number of bits used for this signal. If this rule is enabled, Sigasi will report all unconstrained integer types used for signals.
...
signal sig_a : integer;
signal sig_b : integer range 0 to 100;
...
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL can check that the same clock edge specification style is used throughout the entire design. This standard rule provides a clean coding style guaranteeing consistency in clock checks. This rule consists of three configurable options:
event attribute, ensures that all clock conditions are using the event attribute, for example, clk'event and clk = '1'
stable attribute, ensures that all clock conditions are using the stable attribute, for example, not clk'stable and clk = '1'
edge function (the default), ensures that all clock conditions are using an edge function, for example, rising_edge(clk)falling_edge(clk)
Example with “edge function” selected
process(clk) is
variable count : natural := 0;
begin
if clk'event and clk='0' then -- Wrong clock style!
count := count + 1;
end if;
end process;
process(clk) is
variable count : natural := 0;
begin
if falling_edge(clk) then
count := count - 1;
end if;
end process;
Note that using clock attributes is deprecated since VHDL 93 by the IEEE 1164 standard, use edge functions instead.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Even though the Verilog specification does not allow additional trailing content on lines with preprocessor directives, many tools allow this.
The non-standard compliant content is marked with a warning.
`include "warning.svh"; // Trailing content in directive line
`include "ok.svh"
; // Insert a newline after the directive to comply with the specification
It is recommended that you fix these problems since they are not covered by the Verilog standard.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
It is recommended to declare the FSM states as enumerated data types. Enumerated state types make HDL code generally more readable. It also facilitates increased flexibility in the synthesis implementation as you can select the encoding style used without modifying the HDL code. These aspects support greater design portability and support FSM error detection and recovery.
In safety-critical designs though, std_logic_vector can still be preferred.
Sigasi Visual HDL can ensure one of the following types is used for FSM state signals or variables:
enumeration
arrays of (u)logic, e.g., std_logic_vector
arrays of bit, e.g., bit_vector
The type that is configured by default is “enumeration”.
Example with “array of logic” as expected FSM state type:
process is
variable state : bit_vector(1 downto 0) := "00"; -- Unexpected FSM state type: expected array of (u)logic but was 'bit_vector'
variable state2 : std_logic_vector(1 downto 0) := "00";
begin
case state is
when "00" => state := "11";
when "11" => state := "00";
end case;
end process;
Note that this rule is set to
ignore by default. You can enable it in the VHDL Errors/Warnings settings page (Style Validation > Unexpected FSM state type).
You can also configure the FSM state type that is checked on this page.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
VHDL is mostly a case-insensitive language, so keywords can be written in any case: lowercase, uppercase, or any combination of those. Using a consistent casing for keywords throughout the project may improve readability.
signal lower: boolean;
Signal mixed: boolean;
SIGNAL upper: boolean;
This rule can be configured by setting the desired default capitalization: either lowercase, uppercase, or consistent in file. The latter will look at the majority of casing in the file. Some specific keyword capitalization exceptions can also be added.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Reporting in UVM classes should always be done with one of the eight standard reporting macros `uvm_info, `uvm_info_context, and so forth, rather than ad hoc $display statements or similar. Simulation run time can be dominated by I/O operations, so it is important to use the reporting features of UVM, such as message verbosity, to control the number of messages being generated.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In general, the name of the UVM object should be the same as the variable name it’s assigned to. This makes it easier to associate UVM object path names with SystemVerilog variables names while debugging.
class my_agent extends uvm_agent;
`uvm_component_utils(my_agent)
my_sequencer m_sequencer;
my_driver m_driver;
my_monitor m_monitor;
function void build_phase(uvm_phase phase);
// UVM object name 'my_sequencer' does not match variable name 'm_sequencer'
m_sequencer = my_sequencer::type_id::create("my_sequencer", this);
// UVM object name 'bus_driver' does not match variable name 'm_driver'
m_driver = my_driver::type_id::create("bus_driver", this);
m_monitor = my_monitor::type_id::create("m_monitor", this);
endfunction
endclass
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
SystemVerilog allows the use of vector types as edge event expressions. However, in this case, the transition would be detected only for the least significant bit of the vector. Edge detection is usually used for clocks and asynchronous reset signals which are supposed to be scalar. Sigasi Visual HDL reports usages of vectors in edge event controls, as they’re most likely an indication of signal name typo or an incorrect data type of a control signal.
module ff(input [7:0] d, clk, output [7:0] q);
always_ff @(posedge clk) begin // Edge event detection on 'logic [7:0]'. Only changes to the LSB of the vector will be detected
q <= d;
end
endmodule
If detecting the edge on a single bit of the vector signal is intentional, using bit-selection can show this decision explicitly:
module ffs#(WIDTH = 8) (input [WIDTH-1:0] d, clk, output [WIDTH-1:0] q);
for (genvar i = 0; i < WIDTH; i++) begin
always_ff @(posedge clk[i]) begin
q[i] <= d[i];
end
end
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL (SVH) checks the vector size in assignments and port maps. This check works at type-time and takes the (symbolic) value of generics into account.
SVH will not take into account the value assigned to a generic in instantiations. The reasoning behind this is explained here.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog, it is possible to reference identifiers from different files. However, if multiple files are declaring the same identifier there is no way to know which one should be used. Such cases will be marked as ambiguous references (rule 93).
A possible reason you might be seeing these errors is that your project defines multiple top levels that have been mapped to the same library. More information about library mappings can be found here.
SVH warns about duplicate type member keys in assignment patterns (rule 30). This is not an error according to the language reference manual,
but the last used type key overwrites previously matched members, making the code confusing and hard to maintain.
module uglycode;
struct { int x, y; } a = '{int: 0, int: 1};
int b[10] = '{int: 0, int: 1};
endmodule
module goodcode;
struct { int x, y; } a = '{int: 1};
int b[10] = '{int: 1};
endmodule
SVH flags an error when an assignment contains a mix of ordered and named elements (rule 32).
module badcode;
// Mix of ordered and named associations: not correct
struct { int x, y; } a = '{0, y: 1};
int b[4] = '{0, 1, 2:5, 3:7};
endmodule
module ok_code;
// Place binding: correct but may be harder to read, particularly with many elements
struct { int x, y; } a = '{0, 1};
int b[4] = '{0, 1, 5, 7};
endmodule
module goodcode;
// Name binding: esay to understand and maintain
struct { int x, y; } a = '{x: 0, y: 1};
int b[4] = '{0: 0, 1: 1, 2: 5, 3: 7};
endmodule
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
28/severity/${path}={error|warning|info|ignore} # default member must be last
30/severity/${path}={error|warning|info|ignore} # overwritten type key in assignment pattern
31/severity/${path}={error|warning|info|ignore} # duplicate member key in structure assignment pattern
32/severity/${path}={error|warning|info|ignore} # mixed named and ordered notation in assignment pattern
A case statement should cover all options, either enumerating all options explicitly or with a default
clause (rule 8). This rule is checked for enum types only, not for scalar or vector types.
module badcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state) // Error: case `INIT` is missing
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
endcase
end
endmodule
module bettercode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
endcase
end
endmodule
The default clause should be at the end after all the other options (rule 15). SVH warns if that is not the case.
module badcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
default : state = IDLE ; // The `default` clause must be at the end
READY : state = IDLE ;
endcase
end
endmodule
module goodcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ;
endcase
end
endmodule
This rule also applies to generate case statements, e.g.
module bad_example#(parameter WIDTH=8);
generate
case (WIDTH)
default: // The `default` clause must be at the end begin // others - carry look-ahead adder
adder_cla #(WIDTH) x3(co, sum, a, b, ci); end
1: begin // 1-bit adder implementation
adder_1bit x1(co, sum, a, b, ci);
end
// other cases
endcase
endgenerate
endmodule
SVH warns for case statements without a default clause (rule 40). While a case statement without a default branch is syntactically correct, many guidelines recommend attaching a default branch, even if the case statement is completely defined. This ensures no latch would be inferred during synthesis if the case is incomplete (sometimes difficult to judge, esp with casex/casez semantics or larger widths).
module rather_ok_code(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
// no default branch
endcase
end
endmodule
module goodcode(input clk);
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
INIT : state = IDLE ;
IDLE : state = START;
START : state = READY;
READY : state = IDLE ;
default : state = IDLE ;
endcase
end
endmodule
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
8/severity/${path}={error|warning|info|ignore} # Missing cases
15/severity/${path}={error|warning|info|ignore} # Default clause must be last
16/severity/${path}={error|warning|info|ignore} # Multiple default clauses
40/severity/${path}={error|warning|info|ignore} # Missing default clause
Initializing registers at the point of declaration may be tricky. If your (System)Verilog code is not going
to be synthesized (e.g. testbench), it is completely acceptable. FPGA synthesis tools may also take initialization
into account, so depending on your FPGA project, initializing registers when they are declared in the code may be
a viable (or even preferred) option.
ASIC synthesis tools however will ignore initialization as in the first example, which may lead to a mismatch between
synthesis and simulation. In such a case, initialization should be done using resets, as in the second example.
By default, Sigasi Visual HDL warns for register initialization at the point of the declaration. For FPGA projects
it may be desirable to turn the warning off, whereas for ASIC projects one may want to raise the severity to error.
module fpga_only(input clk, input rst, input ii, output logic oo = 1'b0);
logic sig = 1'b0;
// ...
endmodule
module asic_fpga(input clk, input rst, input ii, output logic oo);
logic sig;
always @(posedge clk) begin
if (rst == 1) beginsig = 1'b0;oo = 1'b0;end
else begin
// ...
end
end
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog class methods and class properties can be declared as local or protected to restrict their access. Sigasi Visual HDL will flag attempted accesses that violate these restrictions as errors (rule 61).
local methods and properties can only be accessed from within the class itself.
class my_class;
local int secret = 42;
function int get_secret();
return secret;
endfunction
endclass
module bad_code;
my_class inst = new();
int x = inst.secret;
endmodule
protected methods and properties can only be accessed from within the class itself, or from any of its subclasses.
class my_class;
protected int secret = 42;
endclass
class my_sub_class extends my_class;
function int get_secret();
return secret;
endfunction
endclass
module bad_code;
my_sub_class inst = new();
int x = inst.secret;
endmodule
While occasionally intended, this construction is confusing, and often
the result of a typo. Sigasi will flag a warning if an empty block is
found (rule 1). In RTL code for synthesis, empty conditional branches
in sequential code can cause unwanted latch generation. There may
be a couple of reasons why an empty block is present in your code:
It is an unintentional omission and should be fixed to prevent unexpected behavior.
Some functionality is not yet, or never will be, supported. In this case, a $fatal (or similar) system task should be called.
It is intentionally blank. In this case, a comment should clarify the reason why.
It is recommended that the base name of the filename is the same as the name of the design unit (e.g. module) in the file (rule 17). SVH warns if that is not the case.
For example, module my_module should be in a file named my_module.v or my_module.sv .
In a file with multiple design units (which is not recommended), this rule is not active.
For legibility, it is recommended to keep lines of code short (rule 20). SVH warns if a code line is longer
than a certain length. The maximum length is set to 120 characters by default, but this can be changed in the
project linting settings.
While this may potentially be controversial, TABs are forbidden in the majority of coding standards in the HDL domain with the motivation
of code not looking the same regardless of the editor/settings used. This check is set to
ignore by default but it can be enabled in
the workspace or project linting settings (rule 21).
Starting with Verilog 2005, regions of Verilog and SystemVerilog files
may be encrypted to protect intellectual property. Sigasi obviously
won’t check the content of these regions. Optionally, Sigasi can flag
the presence of encrypted regions in your code (rule 44). This rule is
off by default (i.e. set to IGNORE) but can be enabled (as info,
warning, or error) as required.
For readability, each statement should be on a separate line. Sigasi
Studio will flag a warning if a line of code contains multiple
statements (rule 47).
module rule47;
reg A, B, C, D, K, M;
reg EN;
assign A = B & C, D = K & M; // multiple statements in one line: less readable
assign A = B & C; // one statement per line: more readable
assign D = K & M;
always@(*)
if(EN==1'b1) begin
A = B & C; D = K & M; // multiple statements in one line: less readable
A = B & C; // one statement per line: more readable
D = K & M;
end
endmodule
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
1/severity/${path}={error|warning|info|ignore} # Empty loops and conditional branches
17/severity/${path}={error|warning|info|ignore} # File name does not match design unit
18/severity/${path}={error|warning|info|ignore} # File contains multiple design unit
# Verilog code line too long
20/severity/${path}={error|warning|info|ignore}
20/params/max_line_length/${path}=${integer} # at least 1
21/severity/${path}={error|warning|info|ignore} # Tabs are not allowed
44/severity/${path}={error|warning|info|ignore} # Report encrypted regions
47/severity/${path}={error|warning|info|ignore} # Multiple statements per line
58/severity/${path}={error|warning|info|ignore} # Regular expressions compatibility
Duplicate conditions decrease readability and could lead to unused code. Duplicate conditions are often an unintended result of copy-pasting. Sigasi marks these duplicates as warnings (rule 98).
module bad_code(input clk);
if(clk && clk) begin
// Do something
end
endmodule
module good_code(input clk);
if(clk) begin
// Do something
end
endmodule
This is also the case for if-else chains or switch cases.
module bad_code(input clk);
if(clk) begin
// Do something
end else if(clk) begin
// Never called
end
typedef enum {INIT, IDLE, START, READY} t_state;
t_state state;
always @(posedge clk) begin
case (state)
IDLE : state = START;
IDLE : state = READY; // Never called
READY : state = IDLE ;
endcase
end
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
Sigasi Visual HDL warns if a signal is assigned a value in
multiple continuous assignments (rule 101). Duplicate continuous assignments are
optimized away during synthesis. Having duplicates decreases the
readability of the code and may lead to mistakes.
module bad_sumff(input clk, rst_n, logic[31:0] d1, d2, output logic[31:0] q);
wire logic[31:0] sum = d1 + d2;
assign sum = d1 + d2;
always @(posedge clk or negedge rst_n)
if (~rst_n)
q <= 32'b0;
else
q <= sum;
assign sum = d1 + d2;
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog and SystemVerilog, you are not allowed to declare the same identifier multiple times within the same scope. All duplicate declarations are marked as errors (rule 95).
module bad_code;
parameter p = 0;
parameter p = 1;
endmodule
parameter p = 0;
module good_code;
parameter p = 1;
endmodule
When using the non-ANSI style, it is legal to have duplicate ports in the port list. However, such duplicate ports are often the result of a coding error and can cause unintended behavior. Duplicate ports are marked as warnings by Sigasi (rule 140).
module discouraged_code(
a,
a,
b
);
input a;
output b;
...
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
A SystemVerilog queue or dynamic array can be initialized by using an empty assignment pattern. Though other constructs, such as structs and associative arrays, cannot be initialized this way.
module empty_assignment_pattern;
int waiting[$];
int clients[];
string names[int];
typedef struct { int fruit; } fruit_basket;
fruit_basket basket;
initial begin
waiting = '{};
clients = '{};
names = '{};
basket = '{};
end
endmodule
A SystemVerilog queue or dynamic array can be initialized by using an empty queue concatenation. Though other constructs, such as structs and associative arrays, cannot be initialized this way.
module empty_concatenations;
int waiting[$];
int clients[];
string names[int];
typedef struct { int fruit; } fruit_basket;
fruit_basket basket;
initial begin
waiting = {};
clients = {};
names = {};
basket = {};
end
endmodule
In Verilog and SystemVerilog, it is legal to have empty ports or port connections to indicate unused ports. However, this is not allowed for parameters or parameter overrides. Such errors are detected and marked by Sigasi (rules 53 and 54).
When using the non-ANSI style, it is legal to have empty ports in the port list. An empty port will be translated to an anonymous port that nullifies anything connected to it. Such empty ports are usually the result of superfluous commas and rarely reflect the intended design. Empty ports are marked as warnings by Sigasi (rule 142).
module discouraged_code(
a,
,
b
);
input a;
output b;
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
For a class method to override a method, the corresponding method in the superclass must be virtual. If the method in the superclass is not virtual, it will be hidden instead. Hiding methods instead of overriding them is often unintentional and may indicate a missing virtual keyword (rule 132).
class Parent;
function void f();
...
endfunction
virtual function void g();
...
endfunction
endclass
class Child extends Parent;
function void f();
...
endfunction
function void g();
...
endfunction
endclass
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
The use of VHDL keywords as a (System)Verilog module name is not recommended. In mixed-language projects in particular it
could lead to unexpected results. Sigasi Visual HDL (SVH) warns when a VHDL keyword is used as a module name (rule 7).
The following naming cases should be avoided in Verilog identifiers:
module or port name ending with an underscore: bad_
any name having consecutive underscores: very__bad
The recommendation is mainly based on tool and library compatibility issues.
This is a typical unofficial convention to reserve those types of names as internal to tools.
SVH warns for consecutive underscores (rule 42) and trailing underscores (rule 43) in module and port names.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
7/severity/${path}={error|warning|info|ignore} # VHDL keywords as module name
42/severity/${path}={error|warning|info|ignore} # Consecutive underscores
43/severity/${path}={error|warning|info|ignore} # Trailing underscores
When a previously undeclared name is used in a port connection, a continuous assignment, or an alias, it will be implicitly declared as a scalar net of the default nettype. Such implicit declarations often arise from coding errors, such as a typo in the name or an attempt to reference something that is not available in the current scope. For this reason, all implicit net declarations will be marked as warnings.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog, there are two ways to declare a port list:
ANSI style: The ports are fully declared in the port list.
Non-ANSI style: The declarations of the ports are placed inside the body of the design unit.
module correct_ansi(input a, b, output c);
endmodule
module correct_non_ansi(a, b, c);
input a, b;
output c;
endmodule
When using the ANSI style, the first port of the port list must have either a direction, port type, or data type. If none of these are provided, the code is invalid (rule 135).
Although the input direction is taken by default, it is preferable to explicitly specify the direction to improve readability and make the code self-documenting.
module bad_example;
function int my_func(int a, b); // bad: direction of a and b omitted
return a+b;
endfunction
task my_task(int a, b); // bad: direction of a and b omitted
begin
$display(a);
$display(b);
end
endtask
endmodule
module good_example;
function int my_func(input int a, b); // good: direction of a and b specified
return a+b;
endfunction
task my_task(input int a, b); // good: direction of a and b specified
begin
$display(a);
$display(b);
end
endtask
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
When choosing entity and port names in VHDL, it is recommended not to use (System)Verilog keywords.
This will prevent problems if the VHDL entity ever has to be integrated into a mixed VHDL/Verilog project.
Sigasi Visual HDL will warn if a (System)Verilog keyword is used as an entity name.
entity always is port( -- always is a Verilog keyword: not recommended!
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
An out-of-block method declaration signature should match its prototype declaration’s signature.
Sigasi Visual HDL flags an error if the prototype and the implementation signatures have a:
different subroutine form (task or function)
different return type, if it is a function
different arity or any argument has a:
different name
different direction
mismatched type
If an argument default value is present in an out-of-block method declaration but is missing in the prototype, or default values are not syntactically identical, a warning message is reported (rules 90, 91).
Errors are also reported for a missing prototype for out-of-bound definitions and missing or duplicated definitions for an extern method prototype.
class C;
extern task proto_only(); // missing definition
extern task who_am_i();
extern function bit bad(input int a, b, c, d, e = 2 + 3);
extern function int good(input int a, output string b);
endclass
function C::who_am_i(); // should be a task
// ...
endfunction
function C::no_proto(); // missing prototype
// ...
endfunction
function logic C::bad( // should return bit
output int a, // should be input
input integer b, // should be int
input int si, // should be 'c'
input int d = 4, // should have no default value
input int e = 5 // should be same value as prototype: 2 + 3
);
// ...
endfunction
function bit C::bad(ref x, y); // completely different signature, duplicate definition
// ...
endfunction
function int C::good(input int a, output string b);
// ...
endfunction
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
A virtual method signature should match the overridden method signature in the superclass.
Sigasi Visual HDL flags an error if the signatures have a:
different subroutine form (task or function)
different return type, if it’s a function
different arity or any argument with a:
different name
different direction
mismatched type
If an argument default value is present in one method and is missing in the other one, an info message is reported (rule 67).
interface class A;
pure virtual task who_am_i();
pure virtual function bit bad(input int a, b, c, d);
pure virtual task too_bad(input int a, b, c, d);
pure virtual function A good(input int a, output string b);
endclass
class B implements A;
virtual function who_am_i(); // should be a task
// ...
endfunction
virtual function logic bad( // should return bit
output int a, // should be input
input integer b, // should be int
input int si, // should be 'c'
input int d = 4 // should have no default value
);
// ...
endfunction
virtual task too_bad(ref x, y); // completely different signature
// ...
endtask
virtual function B good(input int a, output string b);
// ...
endfunction
endclass
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
SVH warns if a parameter is declared without a default value (rule 19). Syntactically this is allowed since the instantiating modules should provide the value to the instance parameter.
However, it is undesirable since it makes the definition dependent on a particular hierarchy and limits code reusability.
In addition, it is creating elaboration errors when attempting to use such modules as a top-level.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
19/severity/${path}={error|warning|info|ignore} # parameter without default value
48/severity/${path}={error|warning|info|ignore} # parameter width mismatch
69/severity/${path}={error|warning|info|ignore} # local parameter not initialized
70/severity/${path}={error|warning|info|ignore} # local parameter overridden
A long list of positional parameters or port connections is difficult to read and maintain. Therefore, SVH warns if a
list of positional connections is longer than 3 items (rules 24 and 26). If the number of associations is larger than 3, named connections should be used.
module sub(input clk, arst, enable, data, output reg data_out);
always @(posedge clk or negedge arst)
if (~arst)
data_out <= 1'b0;
else if (enable)
data_out <= data;
endmodule
module badtop;
logic clk, arst, en, a, b;
sub sub_inst(clk, arst, en, a, b); // 5 ordered associations: difficult to read and maintain
endmodule
module goodtop;
logic clk, arst, en, a, b;
sub sub_instance (
.clk(clk),
.arst(arst),
.enable(enable),
.data(a),
.data_out(b)
);
endmodule
SVH flags an error when attempting to mix named and positional port or parameter associations (rule 25).
module sub#(PARAM_1=2, PARAM_2=3) ();
endmodule
module badtop;
// Syntax error: mix of named (`PARAM_1`) and positional (`3`) association
sub#(.PARAM_1(2), 3) sub_inst();
endmodule
module ok_top;
// All associations are positional: OK but harder to understand and maintain
sub#(2, 3) sub_inst();
endmodule
module goodtop;
// All associations are named: best practice
sub#(.PARAM_1(2), .PARAM_2(3)) sub_inst();
endmodule
SVH warns about missing port or parameter connections if the ports or parameters don’t have a default value (rule 38).
module sub
#(LHS, RHS=0)
(input[LHS:RHS] i1=1'b0, i2, output[LHS:RHS] o1);
endmodule
module badtop;
logic[7:0] x;
// parameter `LHS` and port `i2` don't have a default value so they must be connected
sub sub_inst(.o1(x));
endmodule
module goodtop;
logic[7:0] x;
wire[7:0] y;
sub#(.LHS(7)) sub_inst(
.i2(y),
.o1(x)
);
endmodule
SVH flags an error if the number of positional parameters or port connections is larger than the number of parameters or ports of the instantiated module (rule 39).
module sub#(WIDTH=8) (input[WIDTH-1:0] i1=1'b0, i2, output[WIDTH-1:0] o1);
endmodule
module badtop;
logic a, b, c, d;
// Expecting 1 parameter connection and 3 port connections instead of 2 and 4
sub#(4, 6) sub_inst(a, b, c, d);
endmodule
module goodtop;
logic a, b, c;
sub#(4) sub_inst(a, b, c);
endmodule
Note that if there are too few positional parameters or port connections, an error for missing connections will be flagged.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# Whitespace following a backtick
24/severity/${path}={error|warning|info|ignore}
24/params/max_ordered_port_connections/${path}=${integer}
# Invalid preprocessor syntax
26/severity/${path}={error|warning|info|ignore}
26/params/max_ordered_parameter_overrides/${path}=${integer}
Verilog and SystemVerilog always constructs without an event control statement at the top cannot be synthesized.
Additionally, they would activate in random order at the moment 0 at the beginning of a simulation.
Sigasi Visual HDL warns about always blocks without an event control statement at the start.
A good way to correct this description is to place the timing control statement at the top.
module test(clk, data_in, data_out);
input clk;
input[3:0] data_in;
output reg[3:0] data_out;
always
begin
data_out <= data_in;
@(posedge clk); // Timing control not at the top of 'always'
end
endmodule
module test(clk, data_in, data_out);
input clk;
input[3:0] data_in;
output reg[3:0] data_out;
always @(posedge clk)
data_out <= data_in;
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
In Verilog and SystemVerilog there are dozens of places where an expression or identifier of a specific type is required, e.g., operators have expectations on operand types, there are limitations on what a class can extend or implement, etc. It may not be obvious at first glance if a variable or net type complies with these requirements. Such non-compliances will be detected and marked by Sigasi (rules 78, 79, 100 and 131).
Interface classes can only extend other interface classes, while classes can only extend classes and only implement interface classes:
class Foo;
endclass
interface class Bar extends Foo; // Expected interface class but got 'class Foo'
endclass
class Baz
extends Bar // Expected class but got 'interface class Bar'
implements Foo; // Expected interface class but got 'class Foo'
endclass
While let declarations are advertised as a replacement to preprocessor macros and they can have untyped arguments, you still cannot pass types as arguments (unlike selected system functions):
module test;
let my_typename(expr) = {$typename(expr), "!"};
initial $display(
"my: %s\nsys: %s",
my_typename(int), // Expected value expression but got type: int
$typename(int)
);
endmodule
You can unpack a stream of bits into an unpacked struct if all its fields are of bit-stream types. Here, one of the struct fields is shortreal which makes the whole struct non-streamable:
package pkg;
typedef struct {
shortreal data; // shortreal is not a bit-stream type
logic [6:0] unused;
logic parity;
} real_payload;
endpackage
module test (logic [39:0] data);
pkg::real_payload payload;
assign {>>{payload}} = data; // Expected bit-stream data expression but got 'struct pkg::real_payload'
endmodule
These are but a few examples. Sigasi Visual HDL checks numerous other expression expectations in different contexts in SystemVerilog, immediately showing incorrect types and variables usages.
Verilog and SystemVerilog’s type compatibility rules can be obscure, especially considering implicit type conversion and complex expression evaluation rules. To help you avoid any pitfalls, the type checker ensures that assigning ports, nets, or variables is done safely.
Here are a few examples where Sigasi Visual HDL would report an error:
String variables cannot be assigned to int variables because they are dynamically sized ordered collections of characters that are not assignment compatible to int.
However, string literals can be used to initialize ints as they are treated as unsigned integer constants.
Subclasses can be assigned to superclasses, but not vice-versa. Every Apple is a fruit, but not every Fruit is an Apple. Similarly, classes unrelated to one another (Fruit and Vegetable) are not assignment compatible.
The type of the actual value should be equivalent to the formal ref port type (rule 94).
module test;
task automatic inc(ref [3:0] value, input [3:0] amount);
value += amount;
endtask
bit [3:0] value = 10;
initial begin
// Expected expression type to be equivalent to target type 'logic [3:0]' but got 'bit [3:0]'
inc(value, 5);
$display(value);
end
endmodule
Some tools permit implicit type conversions that are not specified by the Verilog or SystemVerilog standards. Making use of such non-standard conversions will reduce the portability of the design. SVH will mark these non-standard implicit conversions as warnings (rule 173).
module test;
logic [31:0] a = '0, b = '0;
initial begin
b = 32'h12345678;
// The SystemVerilog standard does not allow streaming concatenations to be used as expression operands without an explicit type cast.
// However, certain tools still allow it and will perform an implicit type cast.
a = cond ? {<<4 {b}} : b;
end
endmodule
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
A declaration that is never used does not contribute anything to a design and can be an indication of a coding error. Unused declarations will be marked as warnings.
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
This rule can be disabled for your project, or its severity
and parameters can be modified in the project linting
settings.
Alternatively, it can be manually configured with the following template:
SVH flags an info message when using extended identifiers
that contain whitespace. Particularly in mixed-language
designs, these identifiers may cause problems in
Verilog and SystemVerilog as they use whitespace to mark the end of
an extended identifier.
signal \foo bar\ : std_logic -- identifier with spaces: not recommended!
For legibility, it is recommended to keep lines of code short. SVH warns if a code line is longer
than a certain length. The maximum length is set to 120 characters by default, but this can be configured on
the Errors/warnings page of the project settings.
A design often requires certain constant numbers, bitstrings, or string literals. To optimize code maintainability, it is recommended to use generics or define such literals in constants rather than hardcoding them directly into statements. If this rule is enabled, SVH will flag all magic numbers, bitstrings, and strings used in statements.
The rule can be configured to work on numbers, bitstrings, and/or strings. It is also possible to configure a set of literal values that are allowed in statements, this is done using a regular expression .
When writing an expression containing a sequence of operators the order of execution might not always be obvious. For this reason, it is recommended to add sufficient parentheses to expressions that include multiple non-associative operators. If this rule is enabled, SVH will flag all such expressions.
To optimize code maintainability and portability, it is not recommended to assign vectors of constant width to signals. If this rule is enabled, SVH will flag all signal assignments that use constant width vector literals.
These rules can be disabled for your project, or their severity
and parameters can be modified in the project linting
settings.
Alternatively, they can be manually configured with the following template:
# Extended identifier contains whitespace
228/severity/${path}={error|warning|info|ignore}
# Line is too long
97/severity/${path}={error|warning|info|ignore}
97/params/max_line_length/${path}=${integer} # at least 1
# Magic number, bitstring, or string
235/severity/${path}={error|warning|info|ignore}
235/params/check_number/${path}={true|false}
235/params/check_bitstring/${path}={true|false}
235/params/check_string/${path}={true|false}
235/params/allow_literal_pattern/${path}=${regex}
# Sequence of operators without parentheses
230/severity/${path}={error|warning|info|ignore}
# Constant width vector assigned to signal
231/severity/${path}={error|warning|info|ignore}
Sigasi Visual HDL (SVH) flags an error if a mismatch exists between the selected
VHDL language versions of a project, VHDL common libraries,
and individual design files (rule 170).
Applying the associated Quick Fix will upgrade the version of the project,
or - if it’s already set up correctly - it’ll upgrade the version of the file with the outdated version.
The Common Libraries will automatically be updated to the upgraded version.
In SVH, you can set the version of the VHDL
language for
your project and individual files. The setting for individual
files is only intended for compatibility with legacy code. Setting a
higher VHDL version on a design file than the VHDL version of the
project is not supported and will cause this error to appear.
VS Code supports automatic extension updates.
Since VS Code version 1.85, fine-grained control about which extensions to auto-update is available.
If your Extensions: Auto Update setting is set to _Selected Extensions, you can right-click the Sigasi extension in the Extensions pane and select the Auto Update option.
Doing so ensures that your Sigasi extension will be updated even when other extensions are not auto-updating.
You can reach the settings for the Sigasi extension as follows.
Open the Command Palette using Ctrl+Shift+P
Start typing and select Preferences: Open Settings (UI)
In the Search field on top, type Sigasi.
Optionally, configure the JRE location in Sigasi > Java: Path. Make sure to add the java executable name to the configured value.
First, configure the
sigasi.pathToLicense setting. It can be a local node-locked license file or a floating license server, e.g., 27000@myserver.example.com.
Alternatively, you can access the Sigasi extension settings through the Manage icon (
) in the extensions overview.
You can help improve the Sigasi extension for VS Code by enabling automatic submission of usage statistics and error stack traces through Talkback and telemetry.
More information about these features is available on the Talkback page.
Talkback is disabled by default.
To enable Talkback in the VS Code extension, enable the
sigasi.enableTalkback setting.
The messages sent to Sigasi are logged locally. You can view these messages using the Sigasi: Open Talkback Log Folder command.
Disk caching is enabled by default in the Sigasi extension for VS Code. We recommend leaving it enabled as the cache will significantly speed up the extension by preserving the state from an earlier moment.
However, if you’d like to disable it, you can turn off the
sigasi.server.caching.enableOnDiskCaching setting.
The Sigasi Visual HDL (SVH) extension will start once a .project file is detected in the root of the open folder. Make sure that you configure your license before trying to work on a project.
Follow the steps below to set up your project to be used with SVH.
Once set up, SVH will fully start, indicated by the Sigasi Logo appearing in the Activity Bar. Clicking on this item will show the Sigasi View, where you can manage your Sigasi project, view your project files and libraries, and much more.
From then on, you should use the Sigasi Projects View instead of the VS Code file explorer.
Every Sigasi project has mixed-language support.
To create a new project, use the Add Project... button in the empty Sigasi or Explorer View. Alternatively, the command Sigasi: Add Project… can be run from the command palette.
You can import a project from another tool (e.g., a Quartus project) by first it converting into an SVH project using scripts. Find the scripts and documentation at https://github.com/sigasi/SigasiProjectCreator .
The tutorial project covers most of Sigasi’s features.
Press Ctrl+Shift+P and start typing Sigasi: New Tutorial Project… to open the tutorial.
When the extension has finished building the project, you will see a number of issues for some files pop-up in the Projects View.
There will also be several errors and warnings in the status bar, which you can click to open the Problems View. Within that view, you can navigate through the error and warning markers for the project.
VHDL libraries are fully supported. For Verilog/SystemVerilog, Sigasi reuses the VHDL library concept (just work in practice) to distinguish between design files that should and shouldn’t be analyzed.
To change library mappings, you can use the right-click menu in the Sigasi Projects View and select Configure > Set Library as shown in the image below.
Then, you can select an existing library or choose New Library… to type a new library name.
Once you type a new library name, the file/folder you selected will be added to the library you created.
If you want to add a file/folder to an existing library, you can choose one of the existing ones from the list (such as work).
If you want to exclude files/folders from a Sigasi project, select Exclude from Build.
Note that the excluded resource(s) will still be visible in the Sigasi Projects View, and you can still add them (Set Library) to the project.
Creating new libraries, adding a file/folder to an existing library, or excluding files/folders from the build will modify your project’s .library_mapping.xml file.
To change the VHDL or Verilog version, right-click on a project, folder, or file in the Sigasi Projects View and click Configure > Set Language Version.
Then, select whether you want to set the VHDL or Verilog version. If you only see one of the two, you might need to add language support through Configure > Add [VHDL / Verilog/SystemVerilog] Support. Be sure to select the version you want.
Linked resources are a convenient way to link to a file/folder in the Sigasi ecosystem. They work without having to create symlinks or copy content.
To add a linked resource, you can right-click on the node where you want to add it, then click Add Linked File/Add Linked Folder. A file open dialog will pop-up and you can select the file(s)/folder(s) you want to link.
SVH supports environment variables in its project configuration.
This helps to avoid absolute paths in the .project file.
To use environment variables, you have to prefix the environment variable with ENV-.
For example, to refer to the home directory, you can use ENV-HOME.
Any directory with a valid project description file (project.sigasi) is considered to be a Sigasi project.
Sigasi project description is a JSONC (JSON with comments) file. At the top level, it’s a JSON object with the following fields:
A project can be given a logical name that is used to identify it. If the name field is not specified,
the name of the directory containing this project.sigasi file is used as the project name.
You may want to work with multiple versions of the same design or library. In this case, you can use the version field to differentiate between them.
The version of the project can be any string value. No interpretation of the version string is made, e.g., 1.2, 2020-3.1, and latest are all valid versions.
If a version is not specified, default is used as a value. The project’s version can be used when specifying a project target dependencies.
A project target defines how to compile project HDL source files. A project should define at least one target.
You can define multiple targets as well. In this case, a target can correspond to a specific part or configuration of your project.
The sources of each target are compiled and analyzed independently, unless dependencies are explicitly defined.
If necessary, same sources can be safely compiled into multiple targets.
Targets are defined in the targets section. Each target consists of a name and a definition.
A target name is an arbitrary string that is used to identify it.
You can use supported compiler commands (or scripts that invoke these commands) to define a target.
SVH executes specified commands in a target shell, intercepts, records, and analyzes compiler invocations to extract information
on what files should be compiled in this target and how it should be done.
A scripted target definition can have the following fields:
One or multiple compilation commands. If multiple commands are specified, they are executed in their own shells.
You can use any valid shell command or script, or even use your build system command line interface that invokes
one of the supported compiler commands.
Specified commands should run full compilation. SVH considers files that were compiled during the last run to be the only project files.
If commands perform an incremental build, SVH will see only part of the design.
SVH executes compilation commands as is, and thus don’t have an understanding of what build files contribute to a project structure
in case of complex build scripts. To ensure the project structure is up-to-date, SVH detects changes in project directories and re-runs target commands.
If compilation commands create or change files in one of the project directories, it may result in a refresh loop.
While SVH tries to avoid them, if you experience a refresh loop, you may want to update your build scripts
not to make filesystem changes or disable the
sigasi.project.enableAutomaticTargetRefresh setting.
In addition to system environment variables, SVH makes the following environment variables available in the target shell:
Environment Variable
Description
SIGASI_TARGET_SHELL
Shell that is used to run the target’s commands, e.g., /bin/bash -c or cmd.exe /c
SIGASI_COMPILATION_LOG
Absolute path of the compilation.log file that is being populated
SIGASI_PROJECT_DIRECTORY
Absolute path of the directory that contains the project.sigasi JSON file
SIGASI_COMPILER_STUBS_DIRECTORY
Absolute path of the directory that contains the tool stubs
SIGASI_TCL_SHELL
Absolute path of the TCL shell that is used to run the Questa vsim -doTCL commands
If you need more environment variables for your commands or scripts, or you want to override their value, you can do this in the
environment section. Values can use other environment variables (supported formats: $ENV_VAR, ${ENV_VAR}, ${ENV_VAR:default_value})
When you use existing compilation scripts, they may fail because SVH intercepts compiler command invocations.
If these invocations are supposed to produce artifacts that are required by follow-up commands that are not intercepted by SVH,
these commands may fail.
In such cases, you may set ignoreReturnCode to true in the target definition to ignore such failures. It’s recommended to adapt such scripts
for SVH, so they don’t fail during normal operation. You can look at environment variables, to check if your script is executed by SVH.
Commands are executed in one of the following shells:
bash -c <command> on Linux
cmd.exe /c <command> on Windows
A different shell to use can be configured by defining SIGASI_TARGET_SHELL environment variable.
The value should contain a command prefix, e.g: powershell -command, or /usr/bin/zsh -c.
Target commands will be appended to the specified prefix before execution.
A directory with supported compiler executable stubs is prepended to shell’s PATH,
so no actual compiler invocations are performed by Sigasi. All other commands are executed as is.
Additional environment variables are also set before executing commands.
If you don’t have compilation scripts, or would like to use a declarative way to define target sources, you can use the following fields in a target definition:
Object whose property names are path prefixes (relative to the project directory) and whose values are library names. If this property is omitted or empty, no files will be mapped to a library (Required)
A directory that should contain all HDL sources of this target.
If the directory field is not specified, a project directory is considered to be a target sources directory.
All other paths specified in this target definition are relative to this directory.
It’s recommended to use project directory (default behavior) or specify a path relative to the project directory.
If you need to use a directory that is located somewhere else, you can use environment variables in the directory field value to make it portable.
Supported formats: $ENV_VAR, ${ENV_VAR}, ${ENV_VAR:default_value}.
Using absolute paths is not recommended, as it makes it harder to use such project files on different systems.
In order for SVH to compile HDL sources, they have to be mapped to a library. This can be done in libraryMapping section.
Each key is a path inside the target sources directory. A value is a logical name of a library this path should be mapped to, or a list of library names.
Note that the order of specified paths is not relevant, instead, mappings for longer paths have higher priority.
You can map individual files, or whole directories. If you map a directory, each HDL file in this directory and in all nested directories
will be mapped to the specified library, unless the libraryMapping section contains different mappings for nested directories or files.
You can unmap an HDL file or directory by specifying an empty library names list as a value. In this case, specified file or files in specified directory will not be compiled.
Example:
{"targets":{"UVM":{"libraryMapping":{"":[],// don't map any source file in project directory
"src/uvm.sv":"UVM"// other than this one
}}}}
Target sources directory can contain files generated by your toolchains. If there are a lot of such files, it may negatively affect SVH performance.
If that’s the case, or you want to see and use only relevant source files, you can specify what files in the sources directory should be ignored by SVH.
One or multiple pattens can be specified. Each pattern follows .gitignore format.
Example:
{"targets":{"rtl":{"ignore":["*.log",// Ignore all files that have .log extension in target sources directory
"**/tmp/*"// Ignore all files in all nested "tmp" directories
],// ...
}}}
Specify the list of all VHDL filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as VHDL.
If the vhdlSuffix field is not specified, files with .vhd and .vhdl extensions will be compiled as VHDL.
Specify the list of all Verilog filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as Verilog.
If the verilogSuffix field is not specified, files with .v extension will be compiled as Verilog.
Specify the list of all SystemVerilog filename suffixes. Files with names that end with specified suffixes (or extensions) will be compiled as SystemVerilog.
If the systemverilogSuffix field is not specified, files with .sv extension will be compiled as SystemVerilog.
Specify what VHDL version should be used to compile VHDL sources. Supported versions: vhdl-1993, vhdl-2002, vhdl-2008, and vhdl-2019.
If the vhdlVersion field is not specified, the default (vhdl-2019) version is used.
Specify what Verilog or SystemVerilog version should be used to compile Verilog sources. Supported versions: verilog-2005 and systemverilog-2012.
If the verilogVersion field is not specified, the default (verilog-2005) version is used.
If some files should be compiled with a different VHDL or Verilog version, you can specify this in the override section.
Each key is a path inside the target sources directory.
If the path denotes a file (with any extension), you can specify VHDL or Verilog version to compile this file with as a value directly.
If the path denotes a directory, you can specify versions to use for VHDL, Verilog, or SystemVerilog files in this directory and in all nested directories,
unless the override section contains different versions for nested directories or files. You can do this by defining following fields in a value object:
Version to use for SystemVerilog files in the specified directory
Example:
{"targets":{"rtl":{// ...
"languageMapping":{"vhdlVersion":"vhdl-2008",// By default use VHDL-2008 to compile all VHDL files
"override":{"otherlib/src":{// Files in "otherlib/src" directory should be compiled differently
"vhdl":"vhdl-2019",// VHDL files should be compiled as VHDL-2019
"verilog":"systemverilog-2012"// Verilog (.v) files should be compiled as SystemVerilog files
},"otherlib/src/core/legacy.vhdp":"vhdl-1993",// This file is an exception, and should be compiled as VHDL-1993
}}}}}
Version to use for VHDL files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by vhdlVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of your VHDL files in the vhdlSuffix field.
Version to use for Verilog files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by verilogVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of Verilog files in the verilogSuffix field.
Version to use for SystemVerilog files in the target sources directory specified in the override section.
If not specified, a default VHDL version, version specified by systemverilogVersion field,
or version specified for the parent directory in the override section will be used.
If necessary, you can specify non-default filename suffixes of SystemVerilog files in the systemverilogSuffix field.
If necessary, you can specify Verilog include directories or initial defines for all Verilog source files in the verilogPreprocessor section.
You can also configure SVH to compile each Verilog file in its own compilation unit. Following fields are available:
By default, files specified in `include "<filename>" statements are searched only in the targets sources directory.
If you would like to use paths relative to other directories in include statements, you can add these directories in includeDirectories field value.
Whenever you need to set initial defines for your design, you can do this in the define section.
Each key is a name of the macro to define. A value is its body. Value can be an empty string or null if macro should be defined without a body
Example:
{"targets":{"rtl":{// ...
"verilogPreprocessor":{"define":{"CPU":"cpu",// Equivalent to `define CPU cpu
"VCS":""// Equivalent to `define VCS
}}}}}
By default, all Verilog files are compiled in a single compilation unit, setting multiFileCompilationUnitScope to false
will configure SVH to compile each Verilog file in its own compilation unit.
Similar to verilog defines, in the vhdlConditionalAnalysis section you can define string identifiers and values
which are visible to VHDL-2019 conditional analysis directives.
Defining a dependency on another target makes HDL definitions from that target sources available in current target sources,
as well as in sources of all targets that would depend on this target. You can define dependency on:
Another target of the same project (cannot be added for the whole project, only for individual targets)
One or multiple targets of another project
Library from the Library Database
Each dependency is either a string with the name of another target of this project,
or an object with another project name as a key, and an object with the following fields as a value:
Depend on specified targets of referenced project, or libraries of referenced tool
Shortcuts:
When you want to specify only version or target, a shorter version of a dependency declaration is available:
Short version
Full version
{ "common_cells": "1.0" }
{ "common_cells": { "version": "1.0" }
{ "apb_uart": ["test"] }
{ "apb_uart": { "targets": ["test"] } }
Example:
{"dependencies":[// Dependencies for all targets of this project:
// Dependency on all targets of another project with the name "common_cells" and version "1.0"
{"common_cells":"1.0"},// Dependency on target with the name "rtl" of another project with the name "apb_uart"
{"apb_uart":["rtl"]}],"targets":{"ip1":{/*...*/},"rtl":{// ...
"dependencies":[// Dependencies only for this target:
// Dependency on another target of this project with the name "ip1"
"ip1",// Dependency on the UVM 1.2 library from the Library Database
{"UVM":"1.2"},// Dependency on highest Quartus "altera" and "lpm" libraries from the Library Database
{"Quartus":["altera","lpm"]}// Dependency on Vivado 2023.2 "unisim" library from the Library Database
{"Vivado":{"version":"2023.2","targets":["unisim"]}}]}}}
When you specify a dependency on another project or library from the Library Database, it is searched in:
VS Code workspace folders.
Paths specified in the
sigasi.dependenciesSearchPaths setting.
SVH searches for projects recursively in specified directories.
Dependency search path can also point to a Library database, allowing using multiple Library Databases if necessary.
Path To Library Database specified in the
sigasi.pathToLibraryDatabase setting.
Built-in Library Database (is shipped with SVH, and contains following UVM library versions: 1.1d, 1.2, 2017-1.1, 2020-3.1).
These locations are searched in order, and the first project or Library Database library that satisfies dependency requirements (name and version) is used.
If dependency version is not specified, the highest version found is used.
Note that currently SVH does no interpretation of version strings, so:
highest version is determined by simple comparison of version strings
currently there’s no way to specify more complex version requirements (e.g. defining version ranges), only direct match.
Because of SVH limitations, only one version of the project or library can be present in a target dependencies tree.
If the dependencies tree contains multiple versions of the same project or library,
the last specified version (in other words, a version specified closer to the current target in a dependencies tree) is used.
Specify a list of targets of referenced project that should be available in current target.
If no targets are specified, all targets from the referenced project become available.
If an empty list is specified, no targets (other than targets already specified by other dependencies) are added.
Example:
{"targets":{"common":{// ...
"dependencies":[{"Vivado":{"version":"2021.1","targets":["unisim"]}}]},"rtl":{// ...
"dependencies":["common",// Incorrect way to override version (it overrides version, but also adds all Vivado libraries):
{"Vivado":"2023.2"},// Correct way to override version (it overrides version, and does not add any new libraries):
{"Vivado":{"version":"2023.2","targets":[]}}]}}}
New Sigasi projects are an experimental feature and should be explicitly enabled by the
sigasi.project.enableSigasiProjectSupport setting.
SVH intercepts compiler invocations in Sigasi project scripted target commands and interprets their options.
Here is the list of compiler executables that are intercepted, and options that are supported by SVH:
HDL libraries are a very powerful feature of the HDL languages. Sigasi Visual HDL (SVH)
makes it easy to configure and use them. We’re assuming that
you understand the basic concepts of HDL libraries, and so this section focuses on how
they are implemented in SVH.
As with any HDL tool, SVH needs to know where the libraries are
located on your file system. Below, we describe how the library
configuration can be examined and modified using the GUI.
We’ve also presented a use case about how to set up libraries with
SVH to organize your projects.
You can examine the library configuration in the Sigasi Projects view, which
shows how VHDL or SystemVerilog files are mapped.
Each physical file or folder is annotated
with the library it belongs to between square brackets.
In the image above, you can see a mixed-language project called Sigasi-Demo, with a folder named
Common Libraries. In that folder, you see the typical standard
libraries (std and ieee) upon which all VHDL projects depend.
Lower down, you can see other folders, most of which are mapped to the library work.
One of the folders (verilog) is mapped to the library verilog.
You can modify library mapping for project files right in the Sigasi Projects view.
Select a file or a folder in the view and right-click.
Once you select Configure > Set Library in the menu, you will get the library configuration options, as you can see in the image below.
Select Exclude from Build to exclude a file or folder from any library
Select New Library… to define a new library and map a file or folder to it
If you select one or more folders, SVH automatically suggests the folder name as a library, in this case, the includes folder
Select the name of an existing library to map a file or folder to that library
When you map a file into a library, only that file is affected. However,
if you map a folder into a library, then everything in that folder
will be mapped into that library. Any previous library mapping configurations
applied to files or folders in the given folder will be overridden. When you are defining the library mapping
for a new project, you should map from top to bottom.
So, in the case of our Sigasi-Demo project, if work is not
a good default, you would change the top folder’s mapping first and then override the
mapping in the sub-folders.
To exclude any file from all libraries, you can select the Exclude from build option.
SVH will then assume that the corresponding resource is
not part of the project and will not include that resource in a
project build. This is typically useful when you have stale copies of
HDL files or folders lying around that you simply want to ignore.
SystemVerilog include files are always excluded from the build. Any
file that is included in another design file gets excluded from the
build, even if it has an extension that would normally identify it as
a design file, e.g., .v or .sv. It often doesn’t make sense to
compile include files by themselves. Instead, include files are
compiled in the context of the file in which they are included.
All library configuration information is stored in the .library_mapping.xml
file in the root of your project.
If you edit this file, the affected HDL files in your project will be rebuilt automatically.
Note that .library_mapping.xml should be checked into your version control system.
SVH only writes changes to this configuration file when you modify the library configuration.
When you do make changes, SVH first checks that all paths in the
library configuration still exist. If a path no longer exists, it will be
removed from the configuration file.
Note that the library configuration file is case-sensitive, even on Windows.
Each project has a folder called Common Libraries.
This is where reusable libraries go: whether vendor libraries, third-party IP
libraries, or your own reusable libraries. By default, the VHDL STD and IEEE
libraries are added to this folder.
The Common Libraries folder behaves like any other folder.
You can delete it, rename it, or apply a different library mapping.
In most cases, however, the default configuration is just what you need.
In any newly created Sigasi project, the Common Libraries folder
contains the VHDL files of the IEEE and STD libraries.
To add files, right-click the Common Libraries folder and select the
New Linked Folder to create a Linked Folder pointing to the actual folder location that contains the
files you wish to add to the Common Libraries.
Need to add third-party libraries? Learn how here.
Common Libraries by default is a virtual folder. This means that it is not
a real folder in the project directory and it can only contain references to
folders on your file system.
Files in Common Libraries are supposed to be error free. SVH
will not mark errors or warnings in these files.
Aside from these, a few other libraries’ errors and warnings are never marked, regardless of their location.
These libraries are: std, ieee, altera_mf, altera, XilinxCoreLib, unisim, mentor, lpm, simprim, std_developerskit, unimacro, and modelsim_lib.
While you work on your project, you don’t want to edit the files in the
Common Libraries, but you do need them to compile your project.
Using Common Libraries is recommended for files that are supposed to be error free.
This increases SVH’s performance by preventing it from analyzing files that don’t need to be analyzed.
Sigasi Visual HDL provides an easy way to add libraries from Quartus or Vivado or standalone libraries (e.g., UVVM or UVM) to your projects.
Different versions of these tools and libraries can be configured, allowing you to easily switch between them.
The Library Database stores all third-party libraries. Once libraries are extracted into the Database, they can be used in any Sigasi project.
To manage a Library Database, you can open the Tools and Libraries settings page by running the Open Tools and Libraries Settings command or clicking on the corresponding link in the SVH extension settings. On this page, you can see the location of the current Library Database, which libraries are available in this Database, as well as all configured tools and libraries that can be extracted into the Database.
Initially, the Database is empty. Adding a tool will populate the Database with libraries provided by this tool. When a standalone library is added, it will also be copied to the Database. If needed, the tool or library configuration can be changed in the right panel. If you don’t need it anymore, you can remove it from the Library Database as well.
When adding a new tool, you can find a list of detected tool paths in the drop-down menu. Use BROWSE if your tool isn’t there.
It’s good practice to use a tool or library version as its alias; however any identifying string can be used, e.g., latest, stable, etc. The Library Database is self-sufficient, so it’s possible to distribute it between SVH users to ensure everyone uses the same library versions. You can also share it between multiple Sigasi projects.
Note that extracting tool libraries may take a while. During this process, a message is shown in a notification area. If you click on it, a pop-up notification appears, where you can see extraction progress. Pressing the Cancel button will abort the extraction process.
By default, the Library Database will be located inside a workspace storage directory from VS Code. If you are planning to reuse the Library Database, you can choose a different location. When selecting an empty directory, you’ll be given the option to copy an existing Database to this new location. Otherwise, you’ll be able to manually extract added tool libraries or standalone libraries to the new location.
If you have a previously created Library Database, you can select it instead of creating a new one. In this case, if there’s no configuration added for tools and libraries available in the database, a <database> marker will be shown instead of their paths. You can see which libraries are present for a tool by selecting it. You can add more tools or libraries or remove those that are already present in the database as well.
Note: A Library Database can also be created through CLI.
The SVH extension should be running in order to open the Tools and Libraries settings page. You can open or create a project to start the extension.
VS Code provides different scopes for settings: User, Workspace, and Folder. Settings in more specific scopes can override settings in more generic scopes. Be careful if you want to specify tools or libraries manually in settings.json—they can override changes made on the Tools and Libraries settings page.
Once all libraries you need are in the Library Database, right-click your project in Sigasi Projects and click Configure > Project Settings. In the Common Libraries tab, you can select what libraries you want to use in your project. If you notice you don’t need them later on, you can deselect them here as well.
After pressing the APPLY button, selected libraries will be linked to your project in the Common Libraries folder (while deselected libraries will be removed). In a “Source” column, you can see which library or tool version is used.
Note: If project configuration for a library is out-of-sync with an intended library layout (e.g., library files mapping was manually changed), this library will be marked as (out-of-sync) and the SYNCHRONIZE button will appear. Pressing this button will fix the configuration of all libraries that are out-of-sync.
On the Active Tools and Libraries project settings page you can see which versions of libraries and tools are currently being used by your project. If there are multiple versions of tools or libraries available in the Library Database, you can change the version that should be used by a project.
This functionality to add third-party tools and libraries was first introduced in SVH 2024.1, but underwent a major overhaul in SVH 2024.2, resulting in changes to the format of the Library Database. If you’ve already added tools or libraries in SVH 2024.1 and used them in your projects, after updating to SVH 2024.2 or newer, you’ll see that corresponding library files in Common Libraries folder cannot be resolved anymore. In order to update your project setup, you have to:
Re-extract libraries on the Tools and Libraries settings page by pressing EXTRACT button for added tools and libraries. If you used automatically detected tools in SVH 2024.1 you’ll have to add them explicitly first. Learn more
Ensure project configuration for libraries is up-to-date. Go to the project settings Common Libraries page, and if there are out-of-sync libraries, press the SYNCHRONIZE button to update the project configuration. Learn more
The Sigasi Projects View offers a file browser for your projects, including external folders that are not physically part of your project.
This can be useful for including external IP in your projects.
The Projects View also offers a lot of custom Sigasi functionality, such as library mapping, version setting, and project settings.
You can add any (external) libraries and files not within an open project’s folder using the Sigasi Projects View.
In the Sigasi Projects View, right-click any file or folder and select the New Linked File… or New Linked Folder… option to add files and folders from outside the project location.
The configuration of these external files and folders will be kept in the .project file in the project root.
You can add external files and folders anywhere in a project.
If you add a large folder, for example, the unisim primitives, make sure to exclude the folder (Right-click > Configure > Exclude from Build) from being built and only include the required files.
Alternatively, you can put the library files in a folder called Common Libraries.
Then they will only be indexed and not analyzed for errors.
Files can be excluded from showing up in the Sigasi Projects View. By default, project configuration files like .project, .library-mapping.xml, and .settings are filtered.
The filtering can be customized through the following settings, accessible through the Configure Excluded Files button under More Actions:
The sigasi.projectsView.exclude setting specifies a list of glob patterns to match files that will be excluded.
The sigasi.projectsView.excludeNonHdlFiles setting ensures only HDL files are shown.
The sigasi.projectsView.inheritGlobalExclude setting determines whether the global exclusion filter from VS Code should also be applied.
Filtering can be toggled through the Hide Excluded Files toggle button under More Actions.
The Design Hierarchy View shows the hierarchy tree of the design. Initially, the Design Hierarchy View will be empty.
To populate it, click on the Select Top Level Design Unit button that is shown, to select a top level design unit in your project.
This button is also available in the toolbar ().
A Quick Pick will be shown that lists all the available top level design unit candidates.
After picking a design unit from this list, the view will be populated with the structure of your top level.
If you want the selection in the Design Hierarchy View to follow your position in the editor, make sure to enable Follow Cursor from the More Actions () menu.
The Problems View shows problems (errors, warnings, or info) related to your code.
The Problems View is located at the bottom window by default. If it is not open, you can open it by going to View > Open View… and then selecting Problems.
Using the Problems View, you can navigate to the source of a problem by double-clicking on it.
You can filter problems by using the filter icon located at the top-right.
The Libraries View shows the library mapping as well as the description style of the design units in all
projects. You can use it to navigate to a particular design unit in your project. When you click on a file, it will open in the editor.
The UVM Topology View shows the verification environment’s component topology.
When the view is empty, a button is shown that lets you set the root UVM component.
This button is also available in the toolbar ().
After selecting a root UVM component, the view will be populated with the structure of the selected component and its children, including their ports and virtual interfaces.
As you make changes to the design, the UVM Topology View will automatically refresh.
You can navigate to a topology element in an editor by double-clicking it. Right-clicking an element opens a context menu with more navigation options: you can open the type, declaration, or instantiation of a selected element in an editor.
If you want the selection in the UVM Topology View to follow your position in the editor, make sure to enable Follow Cursor from the More Actions () menu. Otherwise, you can explicitly right-click and select Show In > UVM Topology on a UVM component class, a declaration of a component property, an instantiation assignment to this property, or a port connection statement to select the corresponding element in the UVM Topology View.
To open the project, folder or file settings, right-click the project, folder, or file you want to configure in the Sigasi Projects View.
This view allows you to configure all settings for the selected project, folder, or file.
Change the severity of linting rules for your project
Tweak validation parameters
Modify conditional variables for VHDL 2019 projects
Configure include paths and initial defines for the SystemVerilog Preprocessor
Make sure to click the APPLY button at the top right after making your changes.
Changes you make here will be stored in the .settings/ folder within your project.
This way, if you commit the settings with your project, they will be available for your fellow team members.
Note: before 2025.1, project settings were called _project preferences.
You can configure linting rules per project, folder, or file by right-clicking on its name in the Projects View, selecting Configure > [Project/Folder/File] Settings and navigating to Verilog Errors/Warnings or VHDL Errors/Warnings.
The Block Diagram displays a graphical view of all architectures, modules, their instantiations, and generate constructs in your selected editor’s VHDL or SystemVerilog code.
VHDL processes and SystemVerilog always blocks are also shown in the block diagram.
This view automatically updates while you are editing your code and
offers a convenient way to visually inspect and navigate your code, even
when it’s unfinished or broken.
You can open the Block Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Block Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Block Diagram.
You can double-click blocks, ports, or wires to navigate to the corresponding HDL code. If you want to go into a block, you right-click it, and select Open Entity Declaration, Open Architecture, or Open Module.
You can also navigate from your code to the Block Diagram. To reveal a specific signal, port, process, generate, or instantiation: right-click it, select Show In… in the context menu, then select Block Diagram in the pop-up menu. Show In… can also be accessed directly from the hover of an applicable code element.
You can export the Block Diagram to an SVG with the save button on the toolbar.
The State Machines Diagram displays a graphical (bubble diagram) view of all state machines in your current VHDL or SystemVerilog editor. This viewer automatically updates while you are editing your code and offers a convenient way to visually inspect and navigate your code, even when your code is unfinished or broken.
Reset state (dashed arrow): The state that will be assigned when the state machine is reset
Unresolved state (dashed arrow to a ?): SVH found a state transition but cannot determine the end state
Dead state (red outline): States that do not have any outgoing transitions
State names: When a constant name is consistently used to refer to a state, its name will also be used in the diagram
Unused state (red): States that are fully isolated and have no transitions
You can open the State Machines Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open State Machines Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open State Machines Diagram.
If you have documented your state transitions (i.e., the assignments), the comments will be added as text to the transitions in the view.
You can double-click nodes or transitions to navigate to the corresponding HDL code.
With the hide comments button, you can toggle the display of comments on edge labels. With the hide conditions button, you can toggle the display of comments on edge labels. These labels show the code comments of the transition statements. You also have the option to Zoom In, Zoom Out, or Zoom to Fit.
The State Machines Diagram can be exported to an SVG using the save button.
The Dependencies Diagram visualizes the dependencies of your VHDL, SystemVerilog, or mixed language projects.
This view shows the relationships between your source files and makes it easy to see top levels and important packages.
The Dependencies Diagram also makes it easy to detect orphaned files.
The view is automatically updated each time you save your files.
You can open the Dependencies Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Dependencies Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Dependencies Diagram.
The Dependencies Diagram has the following options:
shows dependencies of the entire project, which you can uncheck to focus on the active editor dependencies only
groups design files per library
shows design units inside design files prefixed with an abbreviation of their kind architecture, module, package, etc.
The Dependencies Diagram can help you navigate, too. Double-click a file name in the diagram to open the corresponding editor.
You can also navigate from your code to the Dependencies Diagram. To reveal a specific design unit: right-click it, select Show In… in the context menu, then select Dependencies Diagram in the pop-up menu. Show In… can also be accessed directly from the hover of an applicable code element.
You can export this diagram for documentation by clicking the save button.
The UVM Diagram displays a graphical representation of a root UVM component structure through an intuitive graphical display.
It visualizes the relationships between components, their hierarchical arrangement in the topology, the connections between ports, and the referenced design interfaces. The dynamic expansion of the diagram allows for efficient tracking of connections throughout the UVM component structure.
You can open the UVM Diagram by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open UVM Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open UVM Diagram. To select a root UVM component, use the button in the toolbar.
Similar to the UVM Topology View, this diagram offers a set of navigation options for each element (both by double-clicking on elements and through the context menu), allowing you to access an element’s types, declarations, or instantiations. Double-clicking on a port connection line navigates to the corresponding connected method call in the source code.
Like other diagram views, you can find buttons on the toolbar to Zoom to Fit and export the UVM Diagram as an SVG.
With Net Search, you can find a net’s loads and drivers.
A net is defined as a signal or port and all other signals and ports
that are directly connected to it. The loads are where you read the
value of a net, and the drivers are where you write to it.
To find the entire signal or port net, place your cursor on the
identifier and right-click, then select Find Net. Alternatively, you
can press Ctrl+Shift+H.
The Net Search View will appear. For big designs, it might take a
while before the results appear.
From the Net Search View, you can navigate to the code by
either double-clicking a search result or using the keyboard shortcuts.
Press F4 to move to the next entry and Shift+F4 to go to the previous one,
assuming the default keybindings are in place.
You can open the Preprocessor View by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Preprocessor View. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Preprocessor View.
The Class Hierarchy View displays more information about the hierarchy of a class. It consists of a hierarchy tree
and a list of its class members. To open the Class Hierarchy of a class, right-click the class name, and select Show Class Hierarchy (or press F4).
The Documentation View gives you a live preview of the automatic documentation SVH can generate for your project.
You can open the Documentation View by clicking the Sigasi logo in the editor toolbar (top right) and selecting Open Documentation View. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing Sigasi: Open Documentation View.
The VS Code Editor shows the content of files and allows you to edit
them. It has a tabbed view such that multiple files can be opened simultaneously.
The active file is the one currently selected.
The VHDL and SystemVerilog (or Verilog) editors are optimized to help
you browse and edit VHDL and SystemVerilog code.
Most browsing and editing features are similar for both languages.
The Sigasi Visual HDL (SVH) extension supports syntax and semantic highlighting.
Syntax highlighting: colors code according to lexical classification (such as keyword or string).
Semantic highlighting: colors code according to meaning (different colors for constants and signals).
Note that some VS Code themes might not support semantic highlighting. If you appear to be missing this feature, make sure you’re using one of the default VS Code themes. If the feature still doesn’t appear, get in touch with support.
In themes that support semantic highlighting, you’ll see that names like those of a port, signal, or type are a different color from language keywords.
In themes that do not support semantic highlighting, names like those of a port, signal, or type will have the default text color.
The latter might also happen when there’s no .project file in your root directory. Without this, the SVH extension will not start and only provides basic syntax highlighting.
Clicking on an identifier highlights it and all other occurrences of the identifier that refer to the same object.
Note that this occurrence highlighting is intelligent: it is not based on the identifier’s string value but on the object to which the identifier refers.
Only true references will be highlighted, not occurrences in strings, comments, or other such instances.
To look for occurrences of a given identifier throughout your design, place your cursor on the identifier and right-click. Then select Go to References.
An inline window will be shown, displaying all occurrences of the selected identifier.
You can easily navigate through all occurrences by clicking the items in the list.
Note that all occurrences are also highlighted in the editor, making them easily recognizable.
You can easily navigate to the declaration of any
port, signal, entity, etc. Place the cursor on the identifier,
right-click, and select Go to Definition. The editor immediately
jumps to the declaration.
You can also navigate your code like a web browser by clicking hyperlinks.
If you press and hold the Ctrl key, hyperlinks will appear in your editor.
If you click a link (while holding the Ctrl key), you will navigate to the target of the link.
To learn more about the declaration of a given identifier, you can hold your mouse over it. After a short time, a popup will show you the name and datatype of the signal. This technique is called hovering.
Hover pop-ups can show different kinds of information:
datatype
comments: inline documentation written for the declaration (association rules)
value: the value of constants
errors or warnings: a description of the problem, if the given identifier has an error or warning associated with it
binary/decimal conversion: for hexadecimal, octal, or binary values, the decimal equivalent
SVH provides powerful autocompletion capabilities. This means
that the tool can help you complete identifiers and constructs as you are working on the code. Like other tools, it provides
syntax-based autocompletion depending on the HDL language you’re using. However, it goes much
further: it can also provide autocompletion based on the design context because it knows everything that has been declared in the design.
Autocompletion can come from different sources, as discussed in the following sections. However, the user interface to initiate it is always the same.
SVH will suggest appropriate autocompletion options at any point as you enter code.
You can also trigger autocompletion suggestions by first placing your cursor where you want to autocomplete and then pressing Ctrl+Space.
SVH uses its knowledge of designs to provide intelligent
autocompletion that boosts your productivity tremendously.
The tool understands the current context, which identifiers are
visible, and which constructs are legal at any given point in the code.
As you start typing and ask for autocompletion, it will suggest
appropriate identifiers as autocompletion candidates.
SVH provides autocomplete suggestions for:
component declarations
component instantiations
entity instantiations
module instantiations
case statements (based on variables/signals with an enumeration type)
SystemVerilog preprocessor/macro directives, e.g., `define or `ifndef
SystemVerilog include paths ( `include ""): triggering autocomplete between the double quotes will present a list of files and folders. If you select a folder, trigger autocomplete again to get completions in this folder.
SVH can help you declare VHDL and SystemVerilog constructs, using autocomplete based on templates.
SVH comes preconfigured with templates for all common declarations and statements, including (for VHDL):
function, procedure
process
type: enum, file, range, array, record
signal, constant, variable
component
entity
architecture
entity/architecture pair
package/package body pair
and much more
Some autocompletions are templates that require further user input.
In such a case, the editor window will go into a special template editing mode after performing an autocomplete.
Use TAB to go through the items that have to be modified or completed.
When done, press ENTER to return to normal editing mode.
The cursor will be placed at an appropriate position to continue working.
Note: In other tools, this feature may be known as paste as instantiation or port translation.
SVH knows all design units (entities, components, and modules) in a design and their ports and parameters or generic interfaces, and can therefore automate much of the instantiation process.
At the point in the code where you normally enter a design unit’s name, use autocompletion instead to suggest a list of possible design units.
Upon selection, the tool will complete the instantiation with a generic or parameter list, and a port list with named associations.
As an initial suggestion, each actual parameter will have the same name as its formal parameter.
Of course, the actual parameter names need to be reviewed and edited by the user. Therefore, the editor will go into template editing mode after the autocompletion.
When you invoke a function in VHDL or Verilog, SVH will list that function’s arguments in a pop-up window that will appear once you type an open parenthesis.
The Signature Helper also activates when instantiating a VHDL entity or a Verilog module by listing the ports or generics of that entity or module.
When you press enter, SVH automatically adjusts the indentation of
the current and the new line. Depending on the content of the preceding
line, SVH will automatically increase or decrease the indentation
level. For example, it may add an extra indent after a module or an entity and remove an indent for
the matching endmodule or end entity.
Automated consistent code formatting makes code more readable and understandable for developers, whether working on their own code or when cooperating with colleagues.
In order to format your code, right-click in the editor and select Format Document.
Right-click on any identifier (VHDL or SystemVerilog) and select Rename Symbol to change the name of the associated declaration and all its references.
Once you select Rename Symbol a little dialog box will pop up.
At this point, you can type the new name and press ENTER. This will rename the declaration of that symbol and all its references.
Before renaming, you can also press CTRL+ENTER to see a preview before making changes across your files.
At the bottom, a Refactor Preview tab appears and lists the summary of the changes to be made.
Clickig any of the items in the list visualizes all changes side-by-side.
You can then click the APPLY button to accept the changes or click the DISCARD button to cancel the renaming action.
Note that this feature does not rename references in comments.
When a rename action affects a read-only file, a preview will automatically be shown. In this preview, changes to read-only files are shown, but not selected by default, ensuring that they won’t be applied unless explicitly confirmed.
You can disable this preview behavior by toggling the
sigasi.editor.previewReadonlyFileOperations setting. This can be particularly useful if you’re working with a pessimistic version control system like Perforce, where you may prefer that changes to read-only files are applied immediately without requiring additional confirmation.
Code lenses provide you with shortcuts to contextual actions, right inside the editor. For example, instead of going through the context-menu to set an architecture as Design Hierarchy Top, you can now simply click Set as Design Hierarchy Top.
Every code lens can be toggled on or off individually by changing one of the following settings:
Code Lens
Setting
Default
Export Compilation Order
sigasi.editor.codeLens.exportCompilationOrder
Export Documentation
sigasi.editor.codeLens.exportDocumentation
File is not part of any library
sigasi.editor.codeLens.fileIsNotPartOfAnyLibrary
Open Block Diagram
sigasi.editor.codeLens.openBlockDiagram
Open Class Hierarchy
sigasi.editor.codeLens.openClassHierarchy
Open State Machines Diagram
sigasi.editor.codeLens.openStateMachinesDiagram
Open UVM Diagram
sigasi.editor.codeLens.openUvmDiagram
Set as Design Hierarchy Top
sigasi.editor.codeLens.setAsDesignHierarchyTop
Set as UVM Topology Root
sigasi.editor.codeLens.setAsUvmTopologyRoot
Code lenses can also be disabled entirely by toggling the
editor.codeLens setting.
Similar to code lenses, inlay hints provide you with useful shortcuts right inside the editor. Code lenses take up a separate line, while inlay hints are displayed inline.
Inlay hints can be toggled on or of by changing the
editor.inlayHints.enabled setting.
If you work with large files, you might want to hide certain pieces of your code. This can be done with code folding.
Certain constructs, such as if-statements or process-statements, can be folded so that they are displayed as a single line in the editor view.
You can do this by clicking the little arrow symbols next to the statement or declaration.
If you select a region and press ( or [, the tool will enclose the selected region with the matching closing parenthesis, ) or ].
If you select a region and press ( or [, the tool will enclose the selected region with the matching closing parenthesis, ) or ].
This works for both regular and multi-line strings and with either single or double quotation marks.
You can configure this feature with the
editor.autoClosingQuotes setting.
The VS Code editor can be split into independent viewports that access the same file buffer.
To split the editor, go to View > Editor Layout and select the desired action.
There can be more than two horizontal or vertical splits within an editor.
You can use sticky scroll to navigate through your HDL code more easily. The stickiness is based on the code folding regions.
You can configure this feature with the
editor.stickyScroll.enabled setting.
You can customize color preferences in SVH. Open the Command Palette via Ctrl+Shift+P, type color, and select Preferences: Color Theme from the list.
You will get a list of themes from which to choose.
VS Code supports multiple cursors for simultaneous edits. Cursors can be added using Alt+Click.
If you prefer using Ctrl+Click, open the Command Palette via Ctrl+Shift+P, type multi, and select Toggle Multi-Cursor Modifier from the list to quickly toggle the modifier.
This can also be changed in the settings.
In order to open a design unit in your project, press Ctrl+P, filter the list by typing, and select the design unit that you want to open from the list.
For a quick outline of the objects in a file in the editor, press Ctrl+P, and type @. You can also type : when opening the Quick Outline to group the items by category.
In addition to the powerful features of the VS Code editor, the SVH VHDL
editor supports a number of advanced editing
features that are specifically useful for VHDL editing. These are
described below.
If you want to create an instantiation based on a component (as opposed to
a direct entity instantiation), you need to associate an entity with a component.
SVH can automatically declare a component for an existing entity. In
the place where you would normally enter the component name, use
autocomplete instead to show the list of available entities. Upon
selection, the tool will automatically complete the component
declaration.
Autocomplete suggestions automatically appear and are updated as you type.
In VHDL design, you need to do a lot of type conversions, and SVH’s
autocomplete functionality can help you here. Put a period (.)
after the element you want to convert and the autocomplete suggestions
will appear with descriptions like convert type.
Once you select the desired conversion function, SVH will insert the code.
SVH’s formatter is context-based and tries to respect the author’s style. So depending on your source style, the formatter might make different choices.
One example of this is the decision to format a conditional signal assignment on one or more lines. SVH decides based on the position of the first else keyword.
If you put the else keyword on the first line, the formatter will keep everything on one line. If you put the else keyword on a new line, the formatter will use multiple lines for the assignment.
demo<=(others=>'0')whenenable='1'else(others=>'1')wheninput='1'-- else on new lineelse(others=>'X');
Note about broken code: If your VHDL source file contains syntactical errors, the formatter cannot always figure out appropriate formatting.
For this reason, the formatter is programmed to stop applying (whitespace) changes beyond unsupported syntax errors.
In order to change your formatting settings, right-click the project name in the Sigasi Projects View and select Configure > Project Settings.
Then click VHDL Formatting and enable project formatting settings.
Preserve newlines: this option configures the formatter to not add or remove any newlines in your code.
Vertical alignment: this option configures the formatter to vertically align consecutive declarations and statements, for example <= or :.
Lowercase/Uppercase keywords: when this option is set to UPPERCASE the formatter will convert all VHDL keywords to uppercase.
When this option is set to lowercase, the keywords will be converted to lowercase.
When this option is set to ignore, the case of keywords won’t be changed by the formatter. Note: A Sigasi Visual HDL Designer Edition license is required for this option.
Alignment column for trailing comments: this setting configures what column SVH aligns trailing comments to. The default is 40, but you can choose 0 to not align trailing comments.
VHDL 2019 tool directives are a simplified version of the preprocessor found in
SystemVerilog or the C-family of languages. Tool directives allow for conditionally enabling code based on tool type,
debug mode, or any other custom variable.
In order to edit VHDL tool directives, right-click the project name in the Sigasi Projects View and select Configure > Project Settings.
Then click VHDL Conditional Variables.
Note that some keys are hardcoded as required by the VHDL Language Reference Manual.
To configure the VHDL version, right-click the project name in the Sigasi Projects View and select Configure > Set Language Version.
In the dialog box, select Set VHDL version and then select the desired VHDL version.
The VHDL version can also be set at the folder and file level, but changing the version at the project level will override all folder and file level settings.
Also note that the VHDL version of a folder or file must be greater or equal to the VHDL version of the project.
Stuttering is an editing technique popularized by Emacs that lets you
type certain things really fast. You activate it by tapping a certain
key twice which will expand it to something more complex. For example, press
the period key . twice, and the editor will expand it to a right
arrow =>. Stuttering works like double-clicking: if you type keys
slowly, the stuttering mechanism will not be triggered.
The following stuttering keys are available:
Keys
Effect
,,
<=
..
=>
;;
:=
Stuttering is enabled by default but can be toggled with the
sigasi.vhdl.stuttering setting.
In addition to the powerful features of the VS Code editor, the included SVH Verilog and SystemVerilog
editor supports a number of advanced editing
features that are specifically useful for SystemVerilog editing.
These are described below. Currently, SVH supports Verilog 2005 (IEEE 1364-2005) and SystemVerilog 2017 (IEEE 1800-2017).
Making a typo in the file name of an `include causes swarms of errors. To prevent this, you can simply press Ctrl+Space
between the double quotation marks of an include directive. You’ll be presented with all the files reachable from
your current include path.
Right-click in the editor and select Format Document to format your current Verilog or SystemVerilog file.
The default formatter implementation corrects indentation only.
You can choose whether *.v files are treated as Verilog (IEEE 1364-2005) or SystemVerilog (IEEE 1800-2017). *.sv files are always treated as SystemVerilog. To configure the Verilog version, right-click the project name in the Sigasi Projects View and select Configure > Set Language Version. In the dialog box, select Set Verilog version.
Sigasi attempts to resolve missing Include Paths automatically. However, we highly recommend you explicitly configure include paths to ensure the order is accurate.
You can configure include paths on the Verilog Preprocessor page.
Right-click the project name in the Sigasi Projects View and select Verilog Preprocessor.
Here you can set include paths. In the Initial preprocessor definitions field, you can configure definitions to be set before other files in the project are processed.
This allows you, for example, to set global defines without an explicit include statement.
When you hover over a SystemVerilog preprocessor directive (e.g. include ...), SVH shows the preprocessed text.
In the Preprocessor View, you can preview the expanded version of your preprocessed SystemVerilog source files.
In order to open the Preprocessor View, right-click in the editor and select Show In > Preprocessor.
The Sigasi Visual HDL (SVH) documentation generator makes the documentation process more manageable by automatically extracting information from your HDL source files. The biggest advantage is that there is only a single source for both your design and your documentation. While this gives no guarantee that the design stays in sync with the documentation, it certainly makes it easier.
The Sigasi documentation generator has the following advantages:
No special coding requirements: the plain comments in your code are extracted for the documentation; no need for special annotations. Sigasi uses the same comment association as the hover provider. So, to document a port, you append a comment to a port declaration. To document an architecture, you put the comment just on top of the architecture.
All included. All documentation processing is done in SVH. So you do not need to install extra tools.
Fully hyperlinked. If you export the documentation, you get a fully hyperlinked document.
Live preview. You can see what the documentation will look like while you type your code and comments.
To export documentation, right-click on a project in the Sigasi Projects View and select Export > Export Documentation. Alternatively, you can run the Sigasi: Export Documentation from the Command Palette (Ctrl+Shift+P). A wizard will be opened to customize your documentation. To simplify exporting documentation for certain design units, a code lens is also available which can be enabled by toggling the
sigasi.editor.codeLens.exportDocumentation setting.
You have to choose between Linked resources and Embedded resources when exporting documentation.
Linked resources Creates an HTML document with linked resources.
All Block Diagrams and State Machine Diagrams are in separate files that are linked from within the HTML document.
Any custom CSS file present in the project root will be referenced from the HTML document.
Embedded resources Creates an HTML document with embedded resources.
All Block Diagrams and State Machine Diagrams are embedded in the HTML document.
Any CSS from a custom CSS file present in the project root will be included in the HTML <head>.
Enabling the Split pages by elements count or Split pages by design unit count will paginate the output documentation. This is useful for very large designs that produce extensive documentation of hundreds of MBs.
Summary information about the design appears on the first page and fans out to subsequent pages containing the documentation about individual design elements.
Enabling Include problem information or Include problem markers will add a Problems section containing all the project’s Errors, Errors and warnings, or Errors, warnings, and infos. You can also have it show suppressed problems.
You can specify the folder where you want to export the documentation. If you leave the field empty, it is exported into the sigasi-doc folder of the selected project.
The given path can be relative, which is then resolved starting at the root of the selected project.
If a sigasi-doc.md file is present in the root directory of your project, Sigasi will automatically include it in the exported documentation as an introductory chapter. As usual with our documentation, this is a Markdown file. This allows you to annotate the text easily.
If the root of your project contains a sigasi-doc.css file, this file will be used to style generated HTML documentation.
Note that only the generated HTML will be affected and not the Documentation View.
For example, you can give the background and titles different colors. You can also change the font for all or parts of the document.
Entire sections for entities, architectures, and modules can have different background colors.
Likewise, process lists can have different background colors.
Comments in HDL code are used to add extra information or documentation to that code.
SVH uses certain rules to determine which comment belongs to which code.
This is important for documentation hovers, refactoring, formatting, etc.
However, which comment belongs to which exact code is subjective.
SVH associates comments with HDL declarations with the following rules:
If there is a declaration before a comment in the same line (trailing comment), the comment is associated with this declaration. This comment can span multiple single-line comments that are aligned.
If there is no trailing comment and there is a comment on the line above the declaration with the same indentation, the comment is associated with this declaration. This comment can span multiple lines if they all have the same indentation.
Empty lines break comment blocks
The association rules are illustrated in the image below:
The Formatter and Structural select respect (and fix) comments according to the association rules.
VHDL components and component instantiations: If a component (or one of its ports or generics) does not have a comment itself, SVH will use the comment of the corresponding entity. This also works for component instantiations.
VHDL and SystemVerilog comments are processed with a Markdown processor . This allows you to add markup (e.g., bold, code, paragraphs, hyperlinks, etc.) to comments, resulting in nicer hovers and documentation.
Hovers support complete Markdown syntax. For documentation generation, the following features are supported:
paragraphs (by adding an empty comment line)
line breaks (by adding two trailing spaces)
emphasis (*emphasis*)
bold (**bold**)
lists
tables (with alignment)
external links and email addresses (<https://www.sigasi.com>, [Sigasi](https://www.sigasi.com) and <sales@sigasi.com>)
SVH supports Fenced Code blocks in comments.
This enables you to add text to documentation without Markdown rendering.
To add a comment verbatim to documentation, surround it with triple backticks: ```<verbatim comment>```
You can export a list of all HDL files in your project, sorted in the correct compilation order.
You can use your own simple scripts to manipulate a list and run any EDA tool, including simulator, synthesis, and linter tools.
To export a comma-separated values (CSV) list of files in your project, right-click on a project in the Sigasi Projects View and select Export > Export Compilation Order CSV. Alternatively, you can run the Sigasi: Export Compilation Order CSV from the Command Palette (Ctrl+Shift+P). A wizard will be opened that allows you to select the project and, optionally, a top level design unit. To easily export the compilation order for a certain top level, there is also a code lens you can enable by toggling the
sigasi.editor.codeLens.exportCompilationOrder setting.
After the export has finished, a file named compilation_order.csv or toplevel_order.csv (if a top level was selected) is generated in the root of your project. The file lists the HDL files in your project in a valid compile order.
The Compilation Recipe Export command provides a standardized, machine-readable way to export the compilation order and all compilation details, such as library mapping and language levels, of your Sigasi project.
This feature is essential for integrating your Sigasi project with external tools, such as simulators, synthesis tools, linters, or any custom script that requires an ordered list of HDL files. The command generates a JSON file that precisely describes the project structure, ensuring that your external tools can compile your design in the correct order with the correct settings.
Files are grouped by their target library, language version, and other compilation settings. The order of these groups and the order of files within each group represents the recommended compilation order.
Key
Type
Description
library
String
The name of the HDL library into which the files in this group should be compiled (e.g., my_lib, work).
languageLevel
String
The HDL language version for this group. Possible values include: "VHDL-1993", "VHDL-2002", "VHDL-2008", "VHDL-2019", "Verilog-2005", "SystemVerilog-2012", "SystemVerilog-2017", and "SystemVerilog-2021".
includeDirectories
Array of Strings
(Optional) An array of paths to include directories for Verilog/SystemVerilog include directives. These paths will be absolute or relative based on the export setting.
defines
Object
(Optional) An object containing Verilog macro definitions as key-value pairs (e.g., { "MY_DEFINE": "value" }).
conditionalVariables
Object
(Optional) An object containing custom VHDL conditional analysis variables as key-value pairs.
files
Array
An array of file objects that belong to this group.
This object represents a single source file to be compiled.
Key
Type
Description
path
String
The path to the HDL source file. This will be an absolute path or a path relative to the project root, depending on the choice made during export.
sourceType
String
The origin of the file. Can be: "Project" (file is part of the user’s project), "Dependency" (file comes from a dependency), or "ExternalLibrary" (file is from an external source).
The primary purpose of the compilation recipe is to enable automation and integration with other EDA tools.
Custom Simulation Scripts: Write a Python, Tcl, or other script to parse the compilation-recipe.json file. The script can read the fileGroups, files, defines, and includeDirectories to generate a precise compilation script for your chosen simulator, e.g., ModelSim/Questa, Vivado Xsim, GHDL, VCS.
CI/CD Pipelines: This recipe is ideal for automation. In a Continuous Integration (CI/CD) environment, you can use the Sigasi CLI tool to programmatically generate the compilation-recipe.json file. This allows for seamless integration into your automated build and test pipelines, ensuring that your CI system always uses the exact file list and compilation order defined in your Sigasi project without requiring manually maintained scripts.
Third-Party Tool Integration: Use the recipe to feed your project’s file structure into linters, formal verification tools, or code formatters that require a structured input of source files and their compilation context.
It is possible to run the User Interface of Visual Studio Code on one machine and do the actual development on another machine.
For example, you can be working on a Windows laptop at home while the code lives on a Linux server in a datacenter at work.
To work remotely, you only need to install Visual Studio Code and the Remote SSH plugin.
The plugin connects with the remote server using SSH and handles any setup required on the server.
The Sigasi extension only needs to be installed on the remote server.
Your code is kept on the server; there is no need to have a copy on the remote machine. Documentation is available on the Visual Studio website .
Navigate to extensions (Ctrl+Shift+X or the icon on the left) and install the Remote - SSH extension.
From the Command Palette (Ctrl+Shift+P), select Remote-SSH: Connect Current Window to Host…. If you have an SSH config file, you can use an existing configuration here. Otherwise, select Add New SSH host and add the command to connect to your server. Note that you need to enter the full command line and not just the name of the server. Typically, the full command will look like ssh username@my.compa.ny.
To automate this, we recommend to use an SSH key-pair in combination with the SSH config file.
Once the connection is configured, connect to the server. In the bottom left corner of your VS Code window, you’ll find an indication of the remote connection.
In the connected VS Code window, navigate to extensions and install the SVH extension on the remote server.
Navigate to the Explorer (e.g. Ctrl+Shift+E) and either open an existing workspace folder or clone a repository.
Check your Sigasi license setting. From the Command Palette (Ctrl+Shift+P), select Preferences: Open Settings (UI), and look for Sigasi: Path To License. With remote development, this is the license path on the server.
Now open a VHDL, Verilog or SystemVerilog file on the remote server.
When using the SVH extension in combination with the Remote SSH extension, the Sigasi license should be available on the remote host.
If you’re also using SVH locally, the license settings might be different for local and remote development. In that case, make sure to use the proper settings, depending on whether you’re developing locally or remote.
The settings from the User level will act as the default and can be overridden for each remote by setting the Remote [<remote name>].
Semantic coloring lets you enhance the readability of your VHDL code by applying custom colors and styles to different language constructs. This guide explains how to configure the custom VHDL semantic tokens in your VS Code settings.
Open VS Code Settings:
Navigate to File > Preferences > Settings and search for
editor.semanticTokenColorCustomizations.
Edit or Add Your Rules:
Modify the existing rules or add new ones based on the semantic tokens. Use the provided example as a starting point.
Save Your Changes:
Once you’ve made your customizations, save the settings file. The new semantic coloring will be applied to your VHDL code immediately.
SAL (Sigasi AI Layer, in case you’re wondering) is the name of the integrated AI chatbot in Sigasi Visual HDL.
There are three ways to get a conversation with SAL started:
Open Chat with SAL in the Sigasi view
Toggle the Command Palette (Ctrl-Shift-P) and choose Sigasi Visual HDL: Focus on Chat with SAL View
Right-click anywhere in the editor and select SAL > Explain This Code
Note: Through SAL, you can connect to a remote model using the OpenAI API, such as OpenAI’s GPT 4 model, or a local AI model of your choice via LM Studio.
SAL is configured using up to four environment variables.
Be sure to set them before starting Sigasi Visual HDL, so they get picked up correctly.
The easiest way to get started it by connecting to the OpenAI servers, as detailed below.
If you prefer to use a model made by another company, or you’re working on an airgapped machine, you’ll have to set up a local model.
If you have a working internet connection and an OpenAI API key,
configuring the backend for SAL is as easy as setting the environment variable SIGASI_AI_API_KEY to your API key.
By default, this will use the GPT 3.5 Turbo model.
exportSIGASI_AI_API_KEY="your-openai-api-key"
You can use a different model by setting the SIGASI_AI_MODEL to e.g. gpt-4-turbo.
exportSIGASI_AI_MODEL="gpt-4-turbo"# with the GPT 4 modelexportSIGASI_AI_API_KEY="your-openai-api-key"# with this API key
This guide will help you use LM Studio to host a local Large Language Model (LLM) to work with SAL.
Currently, SAL supports the OpenAI integration API, and any deployed server utilizing this API can interface with SAL.
You need to set the correct URL endpoint and model name, and optionally provide the API key if required by the endpoint.
In addition to syntax validation, SVH also checks your code for
semantic problems. This is often referred to as Linting or Linter checks. Some of these
problems can be automatically resolved with Quick Fixes. Both syntax
checking and linting happen at type-time: problems are revealed as you are
typing your code.
A Code Linter is defined as a tool that finds code that is strictly correct according
to the language definition, but still suspicious or problematic.
Sigasi has a built-in linter, which provides info about code lint
in the design.
The Sigasi linter has reasonable defaults for the configuration
of reported problems, but the severity level of certain
linting rules is configurable for additional flexibility.
Furthermore, some linting rules, such as the VHDL maximum line width
rule, are parameterized and can be tweaked
to your preference.
For each linting rule, you can set the severity of non-conformities
in all code or RTL-specific code. For some linting rules, more
configuration options are available in the sidebar of the settings page. Look into the
documentation of a specific rule for more details on its effect.
Linting rules can be configured per project, folder, or file by right-clicking a project, folder, or file
in the Sigasi Projects view, selecting Configure > [Project/Folder/File] Settings, and clicking VHDL Errors/Warnings or Verilog Errors/Warnings.
You will then be able to change the linting rule configurations.
All configurable linting rules will also offer configure rule Quick Fixes. These can be used to quickly open the settings page corresponding to a specific linting rule.
You can suppress specific problems in your code by adding a @suppress comment (-- @suppress for VHDL and // @suppress for SystemVerilog) on the same line as the problem.
You can limit the suppression to a specific problem by adding a prefix of the problem message between quotes after @suppress. Sigasi also recommends adding a reason why the problem was suppressed by adding an extra comment after @suppress:
<line with problem> // @suppress "Problem message prefix" Reason why problem is suppressed
Changes through Sigasi version:
Since Sigasi Studio 4.2 the @suppress comment also suppresses errors.
Since Sigasi Studio 4.3 problems have a Quick Fix to automatically add the @suppress comment with a matching problem message prefix.
Since Sigasi Studio 5.4 it is possible to suppress all the problems file-, library-, or project-wide through a single Quick Fix.
Where ${path} can be <project> (literally, with brackets!) to set the severity of the entire project,
/path/to/folder to set the severity of an entire folder,
or /path/to/file.vhd to set the severity of a specific file.
The valid values for the parameters are documented on the individual linting rule pages.
They are described according to the following rules:
{value1|value2} means that either value1 or value2 must be used,
e.g., true for {true|false} or bit_vector for {enumeration|bit_vector|std_logic_vector}.
${integer} means the value must be an integral number, e.g., 5.
If the number must fall within a range, it is specified in a comment.
[keyword...] means the value is any number of keywords (or other strings) separated by tab characters,
e.g.
ENTITY PACKAGE
If any of the strings must contain a tab character or a single quote, escape it using a single quote.
For example, below is a list of 2 items, the first a<Tab>tab and the second a'quote.
a' tab a''quote
${regex} means the value must be an RE2/J regular expression, e.g., 0|1.
Whitespace in keys must be escaped with a backslash (\``). You can add comments using a #`.
In the VS Code editor, SVH marks errors, warnings, and info with red, yellow, and blue underlines, respectively.
This keeps you visually aware of the problems or info in your code.
SVH can check whether all sorts of names in the design; entities,
instances, modules, signals, variables, etc.; follow
particular patterns. This may help designers follow their
company’s or team’s coding rules. For example, coding rules may
prescribe that signal names must have a s_ prefix, that generic
names must be written in capitals, or that variable names must use
CamelCase. A naming convention rule is empty by default, which means
that the particular rule is not checked.
In addition, Sigasi can also check for header comments of files,
design units, subprograms, etc. This could, for instance, be used to
check whether a copyright notice or disclaimer has been included in
a file header comment.
Naming conventions configuration can be found in the Style Validation rule category.
At the top-right, you can set the severity of naming convention non-conformities.
Below the severity settings, you can enter validation patterns.
Patterns use the RE2/J regular expression syntax.
Note that names are not validated if the corresponding validation pattern is empty.
You can add two patterns per name: a valid pattern that the name must match (a marker will appear if it does not match) and an
invalid pattern that the name must not match (a marker will appear if
it does). You can set either or both patterns per name.
Similarly, you can also find header comment configuration in the Style Validation rule category.
Problems that have markers can be resolved automatically through a Quick Fix.
To see whether a Quick Fix is available, hover over a problem underline.
Then click Quick Fix… and select one of the Quick Fixes from the list.
You can also click on the problem marker to make a lightbulb icon appear at the beginning of that line.
Clicking the lightbulb will make the Quick Fix list appear. You can then select one of the Quick Fixes from the list.
Finally, you can also trigger Quick Fixes from the Problems View by hovering over
a problem and clicking the lightbulb icon that appears.
The templates editor allows you to define reusable code blocks encompassing frequently used elements like process blocks, signal declarations, or loop constructs. You can seamlessly insert these templates into your VHDL or Verilog code at the cursor position. This eliminates the need for manual typing of repetitive structures, saving you valuable time and reducing the potential for inconsistencies.
You can access the editor through the settings (search for sigasi.userDefinedTemplates). The setting you’ll find has a button to edit your custom templates. It is also available through Ctrl+Shift+P > Sigasi: Open Templates Editor.
In templates you can use variables whose values will be resolved at the time of insertion. Some variables have arguments that require an ID in order to be used, for example ${path:env('PATH')}.
The following is a list of all built-in variables SVH supports:
Variable
Description
${cursor}
Specifies where the cursor will end up when the template is completed.
${date} ${id:date(format[,locale])}
Evaluates to the current date in the specified format and locale. The format and locale parameters are optional.
${dollar}
Evaluates to the dollar symbol $. Alternatively, $$ can be used.
You can configure VHDL formatting settings for a project in Sigasi Visual HDL (SVH) to ensure consistent formatting
across platforms and among users working on the same project.
Sigasi Visual HDL (SVH) provides several features that help write UVM testbenches.
However, you first have to set up a project with a UVM library to use these features.
This page describes how to set up a UVM project in SVH.
The instructions described here are general; refer to the
Project Setup section for
details on project setup.
Open the folder of your UVM project and add Sigasi support to the project.
The project will have a lot of errors at this point, indicating missing declarations
and undefined macros as shown in the image below.
Make sure that UVM is added to SVH Tools and Libraries as explained in Adding Third-Party Libraries to a Project. If you don’t have UVM source files on your system yet, you can
download them here .
Use the UVM library inside your new project by opening the Project Settings, selecting UVM, and clicking the APPLY button as shown below.
At this point, most of the errors should be gone. The image below shows the linked UVM folder inside the Common Libraries in the Sigasi Projects view. You should now see UVM in your Common Libraries.
After completing the steps above, all of the problems related to UVM configuration should be gone as shown below.
You can now use all the UVM features, such as the UVM Diagram, UVM Topology View, and Preprocessor view. The latter resolves any includes automatically and allows you to view the entire UVM code after preprocessing.
Sigasi Visual HDL (SVH) offers Smart Indentation for both VHDL and Verilog. When enabled, the indentation level is automatically adjusted based on the context and the code being written.
To make use of SVH’s Smart Indentation, make sure the Editor: Auto Indent setting is set to full. To further configure the inserted indentation, the following settings can be used:
Editor: Insert Spaces: To insert spaces rather than tabs.
Editor: Indent Size: To configure the size of the indentation.
Editor: Detect Indentation: To dynamically adjust the previous two settings based on the indentation style used in the current file.
The table below lists the Verilog and SystemVerilog linting rules that SVH can check automatically.
The availability of linting rules depends on the license requirements.
Save the license that is sent to you in a file, e.g., sigasi.lic.
You can set the path to your license file through the
sigasi.pathToLicense setting.
To navigate to this setting, you can hover over the status bar item at the bottom of your window indicating SVH Disabled.
After clicking on the Configure Your License button in the hover, the license settings will be opened.
Type the path to your license file (e.g., /home/user/sigasi.lic) in the box under Sigasi: Path to License.
If you have a floating license key, you need to configure both a license server and SVH.
SVH’s license key management system is based on the well-known FlexNet (a.k.a. FlexLM) license manager.
In order to use a floating license, you should first set up a license server.
Read more about this on the Setting Up Your License Server page.
In VS Code, go to the SVH extension settings as described in the node locked licenses section.
Next, enter <portnumber>@<servername> in the Sigasi: Path to License. For example:
27000@myserver.example.com
If you have redundant license servers, enter each of the license servers separated by a comma (,).
We recommend you specify the primary server first in the list, because the first item in the list is checked first.
For example:
If you have multiple, non-redundant license servers, the servers should be separated using colons (:) on Linux and using semicolons (;) on Windows.
If you leave Sigasi: Path to License empty, SVH will try to use an environment variable
to find the license server. If this fails, it will look for a .sigasi.lic file in your home folder.
You can also set your license server via an environment variable instead of configuring it in SVH.
Both SIGASI_LM_LICENSE_FILE and LM_LICENSE_FILE are supported.
When SIGASI_LM_LICENSE_FILE is set, LM_LICENSE_FILE is ignored.
Note that if you want to use an environment variable, you cannot enter a path in Sigasi: Path to License in the extension settings.
The value in the extension settings has priority over environment variables.
For redundant license servers, the servers should be separated using commas (,).
We recommend you specify the primary server first in the list.
For example:
Sigasi Visual HDL will automatically upgrade the license to the
edition that is required for the used feature,
e.g., when first using the Block Diagram, SVH will bump your license from Designer to Professional.
We will hold on to the acquired license after upgrading, unless you manually downgrade the license again.
You can downgrade the license through the Downgrade to ... Edition button in the license status bar item.
The license status bar item can be found at the bottom of the window, indicating the current edition that is in use.
After downgrading, all views that require a higher edition will be disabled. These views will show buttons to upgrade the license again.
For some features, like the UVM linting rules,
there is no automatic upgrading. To activate and use UVM linting rules, you need to explicitly enable them, even if you’ve already checked out the required license.
The way to do so depends on the SVH version you are using.
When using SVH 2024.2.1 or newer versions, UVM linting rules can be enabled through the
sigasi.enableUvmLinting setting.
When using SVH 2024.1, 2024.1.1, 2024.1.2, or 2024.1.3, the UVM linting rules can be enabled by configuring the
sigasi.licenseToCheckOut setting to either Professional or Enterprise. When you configure a license to
check out, SVH will immediately check out that license on startup. Note that we might still upgrade the license to a
higher edition; for example, when a Sigasi Visual HDL Professional Edition license is configured as the license to check out, but
a documentation export is performed, SVH will upgrade to an Sigasi Visual HDL Enterprise Edition license.
If you are having trouble setting up your license, you can open a page that will show diagnostic information about the current license configuration.
This page can be opened by clicking on the license status bar item at the bottom of your window.
The main purpose of HDL languages is to describe a design to be synthesized and implemented in hardware. However, both VHDL and Verilog also provide additional features for writing verification code to check a design by simulating its behavior. In order to do so, you can write testbenches that provide stimulus to DUT inputs and assert whether their outputs have unexpected values. More sophisticated language constructs can be used to do more complex checks. The problem with such verification code is that it’s not synthesizable.
You should not use this verification subset of language features in an actual design. For better synthesis Quality of Results (QoR), you should also follow many other rules. However, since these rules only apply to a synthesizable design, there’s usually no need to restrict oneself to following them in verification code.
To provide better feedback, Sigasi Visual HDL (SVH) detects what parts of the code are supposed to be synthesizable and verifies synthesis rules for that code. In order to do so, it detects a description style for design units as one of the following:
Testbench - top level verification module
Behavioral - additional design units that are supposed to be used for verification purposes
RTL - design units that are part of an actual design to be synthesized
SVH allows you to specify a different severity for rules in RTL and non-RTL (testbench or behavioral) code.
It’s also possible to disable some checks for RTL or non-RTL code by setting the corresponding severity to ignore.
In VHDL, a description style is detected for every architecture, either by detecting verification code or based on architecture names.
The detecting verification code method is the default. In this case, an architecture is detected as:
Testbench, if the corresponding entity does not have any ports, otherwise
Behavioral, if it
contains non-synthesizable processes, e.g., no sensitivity list or multiple wait statements
uses the std.textio package or declares file types
RTL, in all other cases
This mechanism provides good results in most cases. However, if you require more fine-grained control, you can choose to detect the description style based on architecture names, in which case you have to specify name patterns to be matched against them. An architecture is then detected as:
RTL, if its name matches the valid pattern and does not match the invalid pattern, otherwise
Testbench, if the corresponding entity does not have any ports, or
Sigasi Visual HDL (SVH) offers a new and sophisticated workflow to improve re-usability of design build configurations. It is built on top of a new Sigasi project format that replaces Eclipse Compatible Projects currently used by SVH.
Sigasi project consists of one or more build targets. Each target describes how to build an artifact of your project.
An artifact could be a library, a synthesizable component, a test-bench, etc.
There are two types of project build targets, each provides a different way of specifying sources:
Many EDA projects have build scripts that start simulations.
These build scripts already contain a detailed description of the designs your team is working on.
Using Sigasi project scripted targets, you can avoid duplicating the information already present in your build scripts:
SVH will extract all relevant information from the build scripts itself.
Manual targets can be used when you want Sigasi to be in the driver seat and be the main source of information on how to build a design.
They provide control similar to Eclipse Compatible Projects, but allow specifying everything in a single place, and benefit from the dependencies mechanism provided by Sigasi projects.
It’s possible to define dependencies between targets. Defining a dependency on another target makes HDL definitions from that target sources available in current target sources.
It’s possible to define dependency on:
Another target of the same project
One or multiple targets of another project
Library from the Library Database
In addition, SVH now comes with a built-in UVM library. So adding UVM support to a Sigasi project is as easy as adding a single dependency to a project.
Sigasi project support is still in active development. You can start using Sigasi projects by enabling the
sigasi.project.enableSigasiProjectSupport setting:
When you are creating a new project (e.g. through the command palette via Sigasi: Add Project… command)
a wizard offers the option to make either an Eclipse Compatible Project or a new Sigasi Project.
The barebones project.sigasi file will look similar to the following:
From top to bottom, the following configuration is deduced from the JSON:
A Sigasi project has a name. In the example, the project’s name is MyProject.
Two targets are listed to assemble the contents of the project. A target comprises a self-contained set of files that are compiled together.
You can give a target a logical name. The first target in the example above is called rtl, the second one is called tb.
The scripted rtl target runs two simulator commands to compile the RTL code of the project.
The argument files ip/list.f and src/list.f are maintained as part of the project’s build system and can be reused directly.
This target also defines custom environment variables.
The manual tb target instructs to compile all HDL sources in testbench/src directory into a testbench library.
At the same time, all files generated by a simulator in sim directories should be ignored.
This target also defines a dependency on the rtl target (making all the design units compiled there available for the testbench code),
as well as a dependency on the UVM 1.2 library shipped with SVH.
To accommodate new Sigasi project concepts, the Sigasi Projects View represents such projects differently.
The structure of the captured project is visualized in two different forms:
as a filesystem centric Design perspective and as a logical Targets perspective.
The Design perspective allows navigating the structure of all directories that contribute to the project.
The captured information from the build script might refer to files from various locations on disk, configure include paths,
or rely on files that are located on shared drives. All the directories are accessible in the Design folder.
The Target perspective reveals the logical structure of the project. For each defined Target,
a folder represents the libraries and their associated files. The files are rendered in the order of compilation wherever possible.
This view will also reveal if some files are mentioned in the build scripts but are missing on disk.
You can open source file in the Targets perspective from the Code Lens at the top of the file.
To capture and record the semantics of the build scripts specified in scripted targets, SVH executes them in a prepared shell environment.
There, the simulators or compilers (the tools) are shadowed by so-called stub implementations.
These stubs capture the command invocations and their execution context as a compilation log.
Subsequently, the captured compilation log is interpreted and converted into a detailed compilation plan
that contains all participating files and directories in the order of their appearance.
The compilation plan is used to derive the underlying logical structure of the target.
The mechanism is generally agnostic to the chosen build technology, as long as it launches the supported tools
as external processes from a regular shell environment by their simple executable name.
The list of tools that are natively supported and can be introspected on Linux and Windows can be found here.
It should be noted that the tool stubs do not call the original tool. They do not create any artifacts besides adding information to the compilation log.
That is why the project structure can be captured on any machine, even if the simulators or compilers are unavailable.
The utilities that are used to run the build scripts are required though, e.g., make, perl, python, or any other command line based build technology that is used.
Some compiler options may need environment variables to be interpreted correctly.
SVH launches the build in a prepared environment, where the PATH variable is prefixed with a directory that contains the stub executables.
In addition, SVH sets additional environment variables. They allow SVH specific augmentation of the build scripts.
Capturing the project structure works best if the build scripts respect the following rules:
The configured commands should not cause side effects. If code generation is necessary for a project to work,
it is best if the generation step is either not part of the build or repeated runs of the build do not regenerate from scratch
but keep the existing generated files untouched.
When your build script is triggered from within SVH, ensure that your build script builds all your artifacts from scratch.
Avoid triggering an incremental build. An incremental build will not reveal to SVH all build operations and artifacts.
This will result in an incomplete Sigasi project being captured.
For example, make --always-make should be used to ensure that subsequent builds still run the entire pipeline.
The build might still have accidental side effects. Since SVH attempts to capture targets automatically if some meaningful change on disk is detected,
it might go into a build loop. Although this situation will be detected by the tool, the build script should be adjusted to avoid side effects.
The automatic refresh of targets can be disabled by the
sigasi.project.enableAutomaticTargetRefresh setting:
After disabling automatic refresh, you can refresh targets manually by using Code Lenses in the project.sigasi file.
If you encounter any problems with compilation scripts, you can check a few log files that can help you debug the issue.
In a project directory, SVH creates .sigasi/targets/<target name> directory for every scripted target. It contains following files:
compilation.log – contains all intercepted compiler invocations with arguments, working directory, and environment variable values they were invoked with
compilation.out – standard output stream (stdout) of compilation process
compilation.err – standard error stream (stderr) of compilation process
compilation.plan – structured information about files that are compiled as well as how they are compiled
Code Lenses in the project.sigasi file allow to quickly open some of these files.
Sigasi Visual HDL (SVH) license key management system is based on the well known FlexNet (a.k.a. FlexLM) license manager.
SVH supports both node-locked and floating license keys.
The SVH edition is controlled by the license key.
This section details the set-up of the license server when working with floating licenses.
The version of the FlexNet daemons must be equal or higher than the FlexLM version of SVH.
To find the required version in SVH, click on the SVH Disabled notification icon at the bottom right of the VS Code window.
Once you click that icon, a page named License will be opened. You can then check the required FlexNet version.
If you don’t see the SVH Disabled notification, right-click the same location at the bottom right of the VS Code Window,
and check the Sigasi for VHDL, Verilog & SystemVerilog (Extension) option.
By default, Sigasi license files use ports 27000 and 27001 on your license server.
If these ports are already in use on the server, you can change the port numbers in the license file.
The port of the Sigasi daemon is set on the DAEMON line. For example: DAEMON sigasi port=27001, forces the Sigasi daemon to use port 27001.
The port of the FlexNet daemon is set on the SERVER line For example: SERVER your_server_name1 BD41FCF5DE27 27000, forces FlexNet to use port 27000. This is the port clients need to use to check out a license.
You can change the port numbers and your_server_name1 without breaking the signature.
If you have a firewall, remember to open these ports for access.
Create a folder to hold the license manager software, in this example we will use D:\Sigasi\license.
Unpack the zip file into the license folder (D:\Sigasi\license)
Run the license configuration tool lmtools.exe as administrator.
Save the license file supplied for SVH to the license folder
Using a text editor, edit the license file and replace your_server_name1 with the name of the machine you are using, for example, from: SERVER your_server_name1 74e50bb0911e to: SERVER Maple 74e50bb0911e.
Note: If you are not sure of the name of the machine you are using, click on the System Settings tab of lmtools, where it is shown, see below:
Click on the Config Services tab and fill in the following, use the browse button when available:
Service Name: Sigasi License Manager
Path to lmgrd.exe: D:\sigasi\license\lmgrd.exe
Path to license file: D:\sigasi\license\sigasi.lic
Path to the debug log file: D:\sigasi\license\debug.logNote: You will probably need to type the “Path to the debug log file” in full as the file will not exist, so you cannot browse to it.
Ensure both the following boxes are checked:
Use Services
Start Server at Power Up
Now click the Save Service button, and click yes on the confirmation dialog.
Switch to the Start/Stop/Reread tab and start the server.
The license server should now be configured correctly and look a bit like this
If your floating license server does not function properly, try the following steps:
Start the FlexLM daemon with the -z option to see what is going wrong
Check that the FlexNet daemon is running as expected by following these steps:
Download the daemon zip file on the client machine
Run lmutil[.exe] lmdiag -c "<port>@<server>" -n
If the server is running correctly, you should see a description of the valid FlexNet features served by your license server.
Make sure the server name in the license key file is correct.
Make sure both the Sigasi and FlexNet daemon are the same version (i.e., from the same zip-file from the Sigasi download server). If you need to mix versions, the FlexNet daemon version should be equal to or higher than the Sigasi daemon version.
Firewall problems:
make sure that the port for the Sigasi FlexLM license daemon is open
you can force the port for the Sigasi license daemon by adding USE_SERVER and DAEMON sigasi port=<port number> to your license key
On Linux you might have to install lsb to avoid No such file or directory errors when starting lmgrd or other flexlm tools:
sudo apt-get install lsb-core
zypper in lsb
yum install lsb
yum install redhat-lsb.i686
If the installation of lsb-core fails (e.g., on Debian Linux 10), try this workaround (as root):
cd /lib64
ln -s ld-linux-x86-64.so.2 ld-lsb-x86-64.so.3
The lmgrd license manager needs to have write access to the /usr/tmp/ path. If your system doesn’t have a directory /usr/tmp, you can make a link to /tmp (as root):
ln -s /tmp /usr/tmp
Make sure there are no spaces in the daemon path.
Some users have reported that specifying an arbitrary absolute path for the Sigasi daemon on Windows (e.g., DAEMON sigasi C:\\sigasi.exe port=27021) does not work. It only works if the Sigasi daemon is in the C:\Sigasi folder.
Other users have reported that you are not allowed to have the directory name be the same as the daemon name. For example: c:\flexlm\sigasi\sigasi.exe is invalid, but c:\flexlm\vhdl_editor\sigasi.exe works fine.
Make sure the environment variable is correct: SIGASI_LM_LICENSE_FILE=<port number>@<servername>
Verify that your server meets the License Server System Requirements.
If you try to run the daemon on an unsupported version of Windows, you will typically see this error message: CreateProcess error code: 0xc1 File= sigasi.exe.
Check the status of your license via the License diagnostic page by clicking on the SVH Edition Status Bar item on the bottom of the window. At the bottom of this page, you can see the type and expiration date of your license.
If you are accessing your license server through an SSH tunnel, try using 127.0.0.1 instead of localhost.
SVH pre-emptively tries to check out certain license features. As a result, you might see warning messages like the one below in your server log. These messages can be safely ignored.
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.custom" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
9:14:47 (sigasi) UNSUPPORTED: "com.sigasi.hdt.preview" (PORT_AT_HOST_PLUS ) testuser@testmachine (License server system does not support this feature. (-18,327:10054 ""))
If the steps above do not help, feel free to send us an email
and send us a screenshot of the license dialog with the error message.
Did you correct the server name to the actual server name in the (floating) license key file?
Internal Flexlm Error
Check the version number of the FlexNet daemon, it is probably outdated. If not, check the daemon log on the license server.
Invalid Message Received From License Server
Check the daemon log on the license server
Updating DACL Failed: “Service has been created but failed to update the DACL settings of FlexNet Licensing Service. Accessing TS features will be problematic. Check whether FlexNet Licensing Service is correctly installed and delete and create this service again.”
There seems to be a bug in lmtools.exe version 11 on some systems. You can work around this issue by configuring the (latest) Sigasi daemon with an older version of lmtools. (Download here ).
(lmgrd) license manager: can’t initialize:No SERVER lines in license file.
(lmgrd) License Path: “C:\FlexLM\sigasi\license.dat”
(lmgrd) FlexNet Licensing error:-13,66
If you see this error message, double check whether your license file contains a line with USE_SERVER.
FLEXnet Error: “Exiting due to signal 32” (Exited because another server was running)
This error seems to be caused by running multiple instances of the same license server. If this is the case, first make sure to stop lmtools.exe, lmgrd.exe, and sigasi.exe. If the error continues to occur after stopping these processes, the real cause might be the name of the FlexLM folder.
If you installed the licensing software under the custom folder C:\FlexLM\, rename the folder to something else, such as C:\LMFlex\. After renaming the folder, also update the path that you set in the lmtools “Config Services” tab.
[Back to top]This single page manual was generated on 2025-07-05.
This website uses cookies. By
continuing to use this site you are giving consent to cookies being used.
Accept & close
Create a new file
Create a new folder
Refresh
Collapse all folders in the Sigasi Projects View
More Actions
).
A Quick Pick will be shown that lists all the available top level design unit candidates.
After picking a design unit from this list, the view will be populated with the structure of your top level.
Only show Instantiations (enabled)
Only show Instantiations (disabled)
Search the Design Hierarchy View
Expand the full Design Hierarchy View
Block Diagram
in the editor toolbar (top right) and selecting Open Block Diagram. Alternatively, you can open the view using the command palette Ctrl+Shift+P and typing 
State Machines Diagram
Dependencies Diagram
shows dependencies of the entire project, which you can uncheck to focus on the active editor dependencies only
groups design files per library
shows design units inside design files prefixed with an abbreviation of their kind architecture, module, package, etc.
UVM Diagram
