More details can be found here. Your license unlocks the features for your edition.
Updating
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.
Settings
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.
Talkback and Telemetry
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.
On Disk Caching
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 Projects View below the default VSC file explorer. From then on, you should use the Sigasi Projects View instead of the VS Code file explorer.
Every Sigasi project has mixed-language support.
Importing a Project from the File System
Open the folder you want to import through (File > Open Folder…). A pop-up will be shown asking you to create a Sigasi Project.
A project can also be created from the context menu in the explorer through Sigasi Visual HDL > New Project….
The Sigasi: New Project… command can also be run from the command palette.
Creating a New Project From Scratch
To create a new project, use the Create Sigasi Project button in the empty Explorer View. Alternatively, the command Sigasi: New Project… can be run from the command palette.
Importing Another Tool’s Project
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 .
Tutorial and Demo Projects
The extension contains both a tutorial project and demo project.
Tutorial
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.
You can also open a larger demo project using the command Sigasi: New Demo Project….
Project Configuration
Library Configuration
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.
VHDL and Verilog Version
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.
Workspace
To add a new project to your workspace, press File > Add Folder To Workspace.
Make sure the project you’re adding has a valid .project file.
Linked Resources
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.
Environment Variables
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.
Custom Project Variables
Some variables are automatically defined.
PROJECT_LOC with the PATH of your project
PARENT-<COUNT>-<VARIABLE> which points to COUNT levels above the PATH of the VARIABLE
For example, if your project lives in /design/projects/project1, then PARENT-2-PROJECT_LOC/companylibrary points to /design/companylibrary.
You can also use custom project variables, e.g., VUNIT, to point to your VUnit installation.
You can configure these variables as follows:
Press Ctrl+Shift+P to open the Command Palette
Select Preferences: Open Settings (UI)
In the Setting tab, navigate to Extensions > Sigasi for VHDL & SystemVerilog > General > Custom Project Variables
Add variables and their values as required
Note that custom project variables can be set on the User level and also per Remote or for a specific Workspace.
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.
Examining the Library Configuration
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.
Modifying the Library Configuration
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
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.
Configuration File
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.
Common Libraries
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.
Manually Adding Files to Common 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.
How Is “Common Libraries” Different From Other Folders?
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.
Adding Third-Party Libraries to a Project
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.
Library Database, Tools and Libraries
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.
Troubleshooting
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.
Common Libraries
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.
Active Tools and Libraries
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.
Migration from Sigasi Visual HDL 2024.1
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
This page documents the views the SVH extension adds to VS Code.
Sigasi Projects View
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.
Linked Libraries
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.
Buttons in the Sigasi Projects View
These buttons are available in the Sigasi Projects View:
Create a new file
Create a new folder
Refresh
Collapse all folders in the Sigasi Projects View
More Actions
Follow Cursor: links the Sigasi Projects View with the editor
Hide Excluded Files: toggles whether excluded files should be hidden
Configure Excluded Files: opens settings to configure files exclusions
Excluding Files
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.
Design Hierarchy View
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.
Buttons in the Design Hierarchy View
These buttons are available in the Design Hierarchy View:
Select Top Level Design Unit
Only show Instantiations (enabled)
Only show Instantiations (disabled)
Refresh the Design Hierarchy View
Search the Design Hierarchy View
Expand the full Design Hierarchy View
Collapse the Design Hierarchy View
More Actions
Follow Cursor: links the Design Hierarchy View with the editor
Auto Refresh
Sort by: Position
Sort by: Name
Sort by: Category
Problems View
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.
Libraries View
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.
Buttons in the Libraries View
These buttons are available in the Libraries View:
Search the Libraries View
Expand the Libraries View
Collapse the Libraries View
More Actions
Follow Cursor: links the Libraries View with 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.
Buttons in the UVM Topology View
These buttons are available in the UVM Topology View:
Select Root UVM Component
Search the UVM Topology View
Expand all components
Collapse all components
More Actions
Follow Cursor: links the UVM Topology View with the editor
Sort by: Position: sort components, ports, and interfaces by position in the source code
Sort by: Name (sort components, ports, and interfaces alphabetically)
Project Settings
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.
Configuring Linting Rules
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.
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.
You can export state machines to an SVG with the save button.
Dependencies Diagram
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).
Class Hierarchy Tree
The class hierarchy tree displays the superclasses, subclasses, or both.
Icon
Command
Description
Class Hierarchy
Displays all superclasses and subclasses.
Superclass Hierarchy
Displays all superclasses and implemented interface classes.
Subclass Hierarchy
Displays all subclasses that extend or implement the selected (interface) class.
Search
Searches the Class Hierarchy.
Toggle Show Qualified Class Names
Shows the qualified name next to each class.
Member List
The member list shows all members (fields, functions, tasks, and constructors) of a selected class in the class hierarchy tree.
The icon shown in the view describes the current active state of the members list options.
Icon
Command
Description
Show Inherited Members
Shows members inherited from superclasses.
Hide Inherited Members
Hides members inherited from superclasses.
Show Fields
Shows fields in the members list.
Hide Fields
Hides fields in the members list.
Search
Searches the Members.
Toggle Sort By Defining Class
Sorts members by the class in which they are defined.
Documentation View
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.
VHDL and SystemVerilog Editor
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.
Find References
To look for occurrences of a given identifier throughout your design, place your cursor on the identifier and right-click. Then select Find All References.
A search window will appear to the left of your workbench, 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.
Go To Definition and Hyperlinks
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.
Hover
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
Autocomplete and Content Assist
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 Interface
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.
Based on the Design Context
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.
Based on Templates
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.
Smart Indentation
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.
User-Defined Code Snippets
VS Code supports user-defined code snippets, as explained here . To add snippets yourself, follow the steps below.
Open the Command Palette (Ctrl+Shift+P) and type Snippets.
Select Snippets: Configure User Snippets.
Type vhdl or systemverilog to open the corresponding JSON file where you can add your snippet. See the examples below.
{"always posedge clk":{"prefix":"always","body":["always @(posedge ${1:clk}) begin","\t$0","end"],"description":"Insert an always block with posedge clock"}}
Code Lens
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.
Inlay Hints
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.
Other Editor Features
Code Folding
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.
Add Parentheses or Create a String
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.
Indentation and Whitespace
You can access the spaces customization controls at the bottom-right of the VS Code window.
If you click Spaces, a dialog box appears at the top-middle of the window.
The options in this menu are only valid for the file in the editor. Before using these actions, make sure your file has been saved.
Split Editor
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.
Sticky Scroll
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.
Customize Color Preferences
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.
Side-By-Side Comparison
With SVH, you can compare two files side-by-side.
Previous versions (local history or version control)
Comparing two files
Multi-Cursor Support
In order to enable multi-cursor support, open the Command Palette via Ctrl+Shift+P, type multi, and select Toggle Multi-Cursor Modifier from the list.
Open Design Unit
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.
Quick Outline
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.
Open Resource (Go To File)
In order to open a resource, press Ctrl+P, filter the list by typing, and select the resource that you want to open from the list.
VHDL Specific
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.
Code Highlighting
Highlighting classes for VHDL:
Syntax: Comment, Keyword, Number, String, Task Tag
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.
Type Conversion
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.
VHDL Code Formatting
Right-click in the editor and select Format Document to format your current VHDL file.
This includes:
indentation
spacing between keywords and references
vertically aligning symbols like <=
keyword casing
comment alignment
Context-Based
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.
Configuration
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.
Disable Formatting in Defined Regions
You can disable the formatter for defined regions in your VHDL source files by adding off and on tags:
off tag: -- @formatter:off
Turns off the formatter until the end of the file or until an on tag is encountered
on tag: -- @formatter:on
Reenables the formatter following an off tag
Format on Save
You can use auto-formatting whenever you save a file. This feature can be enabled with the
editor.formatOnSave setting.
Constant Propagation
SVH propagates the values of VHDL constants to the expressions where they are used.
VHDL 2019 Tool Directives
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.
VHDL Version
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
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.
Verilog and SystemVerilog Specific
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).
Code Highlighting
Highlighting classes for Verilog and SystemVerilog:
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.
Verilog and SystemVerilog Code Formatting
Right-click in the editor and select Format Document to format your current Verilog or SystemVerilog file.
The default formatter implementation corrects indentation only.
Verilog Version
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.
Include Paths and Initial Preprocessor Definitions
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.
Preprocessor
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.
Customization
You can customize the exported documentation.
Note: Diagram rendering is not supported in Remote SSH setups in versions earlier than 5.5.0.
Selecting a Specific Top Level
You can export documentation for an entire project or a specific top level.
When you select an entire project, the design elements will be listed alphabetically.
When you select a specific top level, design elements will be ordered in a breadth-first order from the top down.
Resources
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>.
Pagination
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.
Problems Section
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.
Output Directory
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.
Introduction Section
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.
The difference in documentation with the CSS settings described above is shown in the screenshots below.
Comment Association
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.
Special Cases
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.
Comment Markup With Markdown
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.
Example
This is the compilation order export for the VHDL tutorial project:
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.
Remote Development License Needs
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.
Example Setting
Below is an example of a semantic coloring configuration for VHDL.
The token keywords below are used to configure how a VHDL construct should be styled.
Token
Construct
sigasiPort
A VHDL port
sigasiConditionalProcessingVariable
A VHDL conditional processing variable
sigasiSignal
A VHDL signal
sigasiSubprogramParameterVariable
A VHDL variable parameter of a task or function
sigasiSubprogramParameterSignal
A VHDL signal parameter of a task or function
sigasiSubprogramParameterConstant
A VHDL constant parameter of a task or function
sigasiConstant
A VHDL constant or enumeration literal
sigasiAttribute
A VHDL attribute
sigasiGenericConstant
A VHDL generic constant value
sigasiGenericType
A VHDL generic type declaration
sigasiGenericSubprogram
A VHDL generic function or task
Customizing Your Setup
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.
First, by clicking the SAL icon in the Activity Bar icon.
Second, by choosing “Chat with SAL: Focus on Chat with SAL View” from the Command Palette (opened with Ctrl-Shift-P by default).
Finally, by selecting a piece of HDL code and using the context menu 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.
Configuring your AI model
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.
Connecting to remote OpenAI services
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.
Linting
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.
Configuring the Linting Rules
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.
Suppressing Problems
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.
No Linting for Common Libraries
Common Libraries are considered production-ready libraries.
Linting is skipped for all files in the Common Libraries folder.
Language-specific Linting Rules
The currently available linting rules are described in detail on the following pages.
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.
Naming Conventions and Header Comment Checks
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.
Quick Fixes
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.
Template Variables
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.
${id:env(name)}
Evaluates to the specified environment variable.
${filename}
Evaluates to the name of the file.
${filename_ext}
Evaluates to the extension of the file.
${user}
Evaluates to the user name.
${year}
Evaluates to the current year.
Importing Templates from SVH in Eclipse
If you previously used SVH in Eclipse, you can transfer any custom templates you created there to the SVH Extension for VS Code:
Export the custom templates as an XML file from within SVH in Eclipse.
Import the XML file(s) into the SVH Extension from the Templates Editor, or by using Sigasi: Import Eclipse Templates from the Command Palette.
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.
Properties
Enable project formatting settings, dictates whether the formatting settings specific to this project are enabled
Preserve newlines, the formatter respects newlines: it does not add or remove any
Align code, align lists such as generics or ports
Lowercase/Uppercase keywords, controls how the formatter transforms keywords: lowercase, UPPERCASE, or ignore
Alignment column for trailing comments, the column in the line to which the trailing comments will be aligned
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.
Configuration
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.
Designer Edition Linting Rules
Designer Edition linting rules are available for all editions.
Save the license that is sent to you in a file, e.g., sigasi.lic.
You can set the path to your license file in the SVH extension settings page.
Open the Command Palette in VS Code via Ctrl+Shift+P, type Settings, and select Preferences: Open Settings (UI).
Then type Sigasi to open the SVH extension settings. Type the path to your license file (e.g., /home/user/sigasi.lic) in the box under Sigasi: Path to License.
Once you configure your license, the SVH extension will ask you to restart VS Code.
Click Restart and wait for it to start using your newly configured license.
Floating Licenses
An example floating license is shown below. Note that the first line starts with SERVER or DAEMON.
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 setup a license server.
Read more about this on the License Server Management page.
Configuring a Floating License in SVH (FlexNet Client)
The license server can be configured in SVH or using an environment variable.
Configuring the License Server in SVH
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.
Configuring the License Server in an Environment Variable
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:
When using a floating license, Sigasi Visual HDL will automatically upgrade the license to the
edition that is required for the feature that is being used,
e.g., when first using the Block Diagram View, SVH will bump your license from Designer to Professional.
We will hold on to the acquired license for the remainder of your SVH session.
Enabling UVM Linting Rules
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 Enable Uvm linting 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
License to check out 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.
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.
VHDL
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
Behavioral, in all other cases
Verilog
For now, there are no rules that would benefit from a design unit description style, so no detection of description styles is performed.
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.
License Server Setup
Download the FlexNet Daemons
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.
Starting the FlexNet and Sigasi Daemon on Linux
The easiest way to start the Sigasi FlexNet daemon is like this (on Linux)
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.log Note: 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
Troubleshooting
If your license key does not work, the first things to check are:
Which version of the Sigasi license daemon are you using?
Is the MAC address correct?
Has the license expired?
Did you copy the license string exactly as it was sent to you?
Did you accidentally try to use a License Token as a license key?
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.
Typical Error Messages
Check the content of the Sigasi License diagnostic page by clicking on the SVH Edition Status Bar item on the bottom of the window.
No License
Is a valid license key path configured (or are valid environment variables used)?
Is the user trying to use an SVH 3 license in Sigasi 2.x?
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.
Rule 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:
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;
Rule 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:
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.
Rule 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 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;
Rule 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 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;
Rule 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 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.
Rule Configuration
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;
Rule 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:
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
...
Rule 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:
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;
Rule Configuration
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
Rule 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:
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;
Rule 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:
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.
Rule 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:
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.
always @(clk, clk , clk )
always @(edge clk, negedge clk , posedge clk )
always @(edge clk , clk)
Rule 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:
When SVH encounters encrypted regions or files, they are ignored. An optional linting rule can warn about this.
Rule 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:
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).
Rule 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:
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
Rule Configuration
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.
Rule 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:
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.
Rule 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 (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.
Rule 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:
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;
Rule 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 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;
Rule 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:
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;
Rule 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:
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
Rule 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:
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
Rule 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:
There are multiple variants of the UVM utility macros, each one used to register a different kind of UVM object class:
UVM components must use the component variants, all other UVM objects must use the object variants
Parameterized classes must use the param variants
Virtual classes must use the abstract variants (UVM 2017 or higher)
class my_uvm_component#(type type_param) extends uvm_component;
`uvm_object_utils(my_uvm_component#(type_param))
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction
endclass
class my_uvm_component#(type type_param) extends uvm_component;
`uvm_component_param_utils(my_uvm_component#(type_param))
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction
endclass
Rule 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:
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
Rule 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:
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.
Note that this rule is set to
ignore by default.
Rule 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 lets users restrict the usage of language features.
Prohibited Keyword or Operator
Keywords and operators can be restricted using a list of keywords and operators that cannot be used (rule 245). For example:
Following keywords and operators are not allowed: **, after
if a**2=4 then -- Operator '**' is prohibited
a <= 8 after 5 ns; -- Keyword 'after' is prohibited
end if;
Prohibited Attribute
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;
Prohibited Library
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:
Library abcdenied
library abc; -- Library 'abc' is prohibited
Library ieeeallowed
library abc; -- Only library 'ieee' is allowed
Prohibited Package
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
Prohibited Pragma
Pragmas can be restricted using a list of pragmas that will be reported when they are used (rule 247). For example:
The following pragma is not allowed: vhdl_comp_off
-- vhdl_comp_off -- Pragma 'vhdl_comp_off' is prohibited
assert (rst_lvl = 0) or (rst_lvl = 1)
report "rst_lvl should be 0 or 1"
severity failure;
-- vhdl_comp_on
Rule Configuration
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.
library ieee;
library DOES_NOT_EXIST;
Note that this rule is set to
warning by default.
Rule 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 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;
Rule Configuration
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:
Sigasi Visual HDL can check for a number of problems related to deferred constants that the VHDL language reference mandates:
Duplicate declaration
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;
Missing full constant declaration
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;
Incorrect full constant declaration subtype
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.
File contains multiple primary units
Every primary unit should live in a separate file.
package pkg1 is
end package;
package pkg2 is -- more than 1 primary unit in the file
end package;
Secondary unit in unexpected file
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.
Rule Configuration
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}
Sigasi Visual HDL can check for a number of loop-related problems:
Infinite loop missing a wait (rule 20). Note that infinite while and for loops will not be checked by this rule.
process
begin
loop
-- statements go here
end loop;
end process;
process
begin
loop
-- statements go here
wait for 1 ns;
end loop;
end process;
Empty loop statement (rule 190): the loop body doesn’t contain any statements
for loopvar in loop
-- nothing going on here...
end loop;
for loops that will not execute due to a loop variable with a null range will be flagged with the Null range linting rule.
Rule Configuration
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
function f(int x, y);
int a = (y);
endfunction
Rule 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:
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.
Rule 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;
Rule 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:
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;
Rule 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:
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
Rule 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:
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.
Rule Configuration
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}
Example
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
Rule Configuration
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.
Rule 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:
In VHDL, you can use ranges with to and downto. But, if you use the
wrong direction, you get an empty range, which is usually not what you
want.
signal foo: std_logic_vector(7 downto 0) -- range of 8;
signal foo: std_logic_vector(7 to 0) -- null range;
We have a lint check that warns about this, even if you use constants or some simple arithmetic.
Rule Configuration
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
);
Rule 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:
This style validation checks whether the relative order of the port connection, argument, or parameter list matches the order used in the declaration.
Port Connections
module top(input a, output b, inout c);
endmodule
module example();
logic a, b, c;
top explicit_named_ordered(.a(a), .b(b), .c(c));
top explicit_named_unordered(.a(a), .c(c), .b(b));
top implicit_named_ordered(.a, .b, .c);
top implicit_named_unordered(.a, .c, .b);
endmodule
Arguments
task tsk(input logic a, output b, output c);
endtask : tsk
function func(input logic a, output b, output c);
endfunction : func
class Cls;
function new(input logic a, output b, output c);
endfunction
endclass
module test();
logic a, b, c;
Cls inst = new(.a(a), .c(c), .b(b));
initial begin
tsk(.b(b), .c(c), .a(a));
func(.a,.b, .c);
end
endmodule : test
Parameters
module top#(type A, B)();
endmodule
class Cls#(type A, B);
endclass
module test();
Cls#(.A(logic), .B(5)) inst = new();
top#(.B(5), .A(logic)) top_instance();
endmodule : test
Rule 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:
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;
Rule 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:
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:
Case statement contains all choices explicitly. You can safely remove
the redundant others.
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”.
Rule 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 warn about problems with your sensitivity list:
Presence of either a sensitivity list or one or more wait statements in a process
VHDL requires a sensitivity list for each process or wait statements in the process body.
Incomplete sensitivity list
A sensitivity list should contain all signals the process is sensitive to.
process(a)
begin
c <= a and b;
end process;
Superfluous signals in sensitivity list
A sensitivity list should only contain signals the process is sensitive to. Adding more signals will only slow down your simulations.
process(a, b, c)
begin
c <= a and b;
end process;
Duplicate signals in sensitivity list
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;
process(all)
begin
c <= a and b;
end process;
Rule Configuration
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;
Note that this rule is set to
warning by default.
Rule 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:
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;
Note that this rule is set to
warning by default.
Rule 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:
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).
Rule 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:
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.
library IEEE, STD, WORK;
Rule 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:
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;
Rule 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:
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;
Note that this rule is set to
ignore by default.
Rule 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:
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.
Rule Configuration
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.
Whitespace following a backtick
Some tools allow additional whitespace following the backtick of a preprocessor directive.
`define A 1
` define B 2 /* unexpected whitespace following the backtick */
Invalid preprocessor syntax
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
Rule Configuration
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
Type Argument Value Does Not Match Containing Class
There are several UVM macros for which the first argument must be the equal to containing class. These macros are:
All UVM object and component utility macros
uvm_field_utils_begin
uvm_sequence_library_utils
uvm_add_to_seq_lib
uvm_set_super_type
uvm_register_cb
class my_uvm_component extends uvm_component;
`uvm_component_utils(some_other_class)
...
endclass
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
...
endclass
If the containing class is parameterized, the parameters must also be passed to the macro:
class my_uvm_component#(int size_param = 8) extends uvm_component;
`uvm_component_param_utils(my_uvm_component)
...
endclass
class my_uvm_component#(int size_param = 8) extends uvm_component;
`uvm_component_param_utils(my_uvm_component#(size_param))
...
endclass
Rule 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 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;
Rule 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:
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;
...
Rule 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 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.
Rule 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:
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.
Rule 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:
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.
Rule 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:
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.
Note that this rule is set to
ignore by default.
Rule 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:
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 configured to report file output system tasks ($fdisplay, $fwrite, …) too:
class my_test extends uvm_test;
`uvm_component_utils(my_test)
task run_phase(uvm_phase phase);
int fd = $fopen("my_test.log", "w");
repeat (1000) begin
my_instr instr = my_instr::generate_random();
// ...
// Unexpected invocation of '$fwrite', use UVM reporting macros instead
$fwrite(fd, {instr.convert2string(),"\n"});
end
$fclose(fd);
endtask
endclass
Rule 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:
UVM objects and components must be registered with the factory using one of the UVM utility macros.
class my_uvm_component extends uvm_component;
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction
endclass
class my_uvm_component extends uvm_component;
`uvm_component_utils(my_uvm_component)
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction
endclass
Rule 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:
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
Rule 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:
When overriding a phase method of a user-defined UVM component, the superclass method must be called.
class parent_comp extends uvm_component;
...
function void build_phase(uvm_phase phase);
...
endfunction
function void connect_phase(uvm_phase phase);
...
endfunction
endclass
class child_comp extends parent_comp;
...
function void build_phase(uvm_phase phase);
// no super call
...
endfunction
function void connect_phase(uvm_phase phase);
super.connect_phase(phase);
...
endfunction
endclass
Rule 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:
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
Rule 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 (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.
Rule 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:
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.
Sigasi Visual HDL (SVH) has several checks on Verilog assignment patterns.
Default member must be last
Concrete assignments must precede more general assignments. Otherwise, some of those assignments might be ignored (rule 28).
In particular:
for arrays, default must be at the end of the list
for structures, default must be at the end, but type-default must be after the particular member assignments
module badcode;
int a[3:0] = '{0: 5, default: 0, 3: 1};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{default: 0, x:1};
circle_t c = '{default: 0, real: 0.0};
endmodule
module goodcode;
int a[3:0] = '{0: 5, 3: 1, default: 0};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{x:1, default: 0};
circle_t c = '{real: 0.0, default: 0};
endmodule
Only one default member expression is allowed
SVH flags an error when expressions have multiple default assignments (rule 29). In particular:
arrays cannot have multiple default assignments
structures cannot have multiple default assignments or multiple type-default assignments
module badcode;
int a[3:0] = '{default: 1, 0: 2, default: 3}; // multiple default assignments
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{default: 0, radius: 1.0, default: 0}; // multiple default assignments
circle_t c = '{int: 0, radius: 1.0, int: 0}; // multiple *type*-default assignments
endmodule
module goodcode;
int a[3:0] = '{0: 2, default: 3};
typedef struct {
int x;
int y;
real radius;
} circle_t;
circle_t b = '{radius: 1.0, default: 0};
circle_t c = '{radius: 1.0, int: 0};
endmodule
Overwritten type key in assignment pattern
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
Duplicate member key in structure assignment pattern
SVH flags an error for duplicate members/index keys in assignment patterns (rule 31). Each member/index key can occur only once.
module badcode;
struct { int x, y; } a = '{x: 0, y: 0, x: 0};
int b[10] = '{5: 1, 5: 2, default: 0};
endmodule
module goodcode;
struct { int x, y; } a = '{x: 0, y: 0};
int b[10] = '{5: 1, default:0};
endmodule
Mixed named and ordered notation in assignment pattern
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
Rule Configuration
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
Sigasi Visual HDL (SVH) has a number of checks on Verilog case statements.
Case statement does not cover all cases
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
Default clause has to be the last item in a case statement
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
Case statement can only have one default clause
A case statement can only have one default clause (rule 16). A warning is flagged if more than one default clause is present.
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;
READY : state = IDLE ;
default : state = IDLE ; // Error: two `default` clauses
default : state = START;
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: // Error: two `default` clauses 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
default: // Error: two `default` clauses begin // others - carry look-ahead adder
adder_cla #(WIDTH) x3(co, sum, a, b, ci); end
endcase
endgenerate
endmodule
Default clause missing from case statement
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
Rule Configuration
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
Rule 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:
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
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
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
Sigasi Visual HDL (SVH) has a number of checks on Verilog and SystemVerilog coding style.
Empty loops and conditional branches
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.
File name does not match design unit
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.
File contains multiple design unit
It is recommended that a Verilog file contains only one design unit (rule 18). SVH warns if that is not the case.
module foo;
endmodule
module bar;
endmodule
Verilog code line too long
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.
Tabs are not allowed
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).
Report encrypted regions
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.
Multiple statements per line
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
Rule Configuration
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
Rule 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 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
Rule 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:
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
Rule 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:
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
Rule Configuration
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.
Packed structures and unions can only contain members of packed data types and integer data types (rule 59).
class AClass; endclass
typedef struct packed { int a; } intstruct;
typedef struct packed { real a; } realstruct;
typedef struct packed { AClass a; } classstruct;
Illegal type in untagged union
Dynamic types and chandle types can not be used in untagged unions (rule 60).
class AClass; endclass
typedef union { int a; } intunion;
typedef union { string a; } stringunion;
typedef union { AClass a; } classunion;
Rule Configuration
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
Rule 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:
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!
Rule 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:
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
Rule Configuration
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
Rule 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 (SVH) validates the use of parameters in (System)Verilog.
Parameters without a default value
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.
SVH flags an error if a parameter with a defined width is declared is assigned a value of differing width (rule 48).
parameter int p = 'h764321098; // Number of bits set a04a (35) wider than the expected bit width (32)
parameter signed [36] q = 'h764321098;
Local parameter has to be initialized
The Verilog standard requires that local parameters are initialized (rule 69).
localparam p; // initialization missing
localparam p = 1;
Local parameter cannot be overridden
The Verilog standard does not allow the overriding of local parameters (rule 70).
module name(
input clk,
input rst
);
localparam int test = 42;
defparam test = 0; // override not allowed
endmodule : name
Rule Configuration
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
Sigasi Visual HDL (SVH) has several checks on Verilog port and parameter associations.
Named parameter and port connections have to be used for all instances with many parameters / ports
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
Named and positional associations cannot be mixed
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
Unresolved formal names
SVH flags an error for named port and parameter connections if the instantiated module doesn’t have ports with these names.
SVH flags an error for duplicate named port and parameter connections (rule 37).
module sub#(WIDTH=8) (input[WIDTH-1:0] i1=1'b0, i2, output[WIDTH-1:0] o1);
endmodule
module badtop;
logic a, b, c;
// parameter `WIDTH` and port `i1` are connected twice
sub#(.WIDTH(4), .WIDTH(6)) sub_inst(
.i1(a),
.i1(b),
.o1(c)
);
endmodule
module goodtop;
logic a, b, c;
// parameter `WIDTH` and port `i1` are connected once
sub#(.WIDTH(4)) sub_inst(
.i1(a),
.o1(c)
);
endmodule
Missing actuals for formals that have no default value
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
Excessive number of actuals in ordered notation
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.
Named connections are not allowed with blank ports
If an instantiated module contains a null port, the instantiation must use port association by order and not by name (rule 56).
module sub(
input clk,
, // this is a *null port*
input rst
);
endmodule
module badtop;
sub sub_instance(
.clk(clk),
.rst(rst)
);
endmodule
module goodtop1;
sub sub_instance(
,clk,rst
);
endmodule
module goodtop2;
sub sub_instance(
clk,foo,rst
);
endmodule
Rule Configuration
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
Rule 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:
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:
Expression Type Requirements in Different Contexts
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).
Extending and Implementing
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
Types vs Value Expressions
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
Operand Data Types
Unary logical reduction operators expect integral operands:
function logic parity(input real data);
parity = ^data; // Expected integral expression but got 'real'
parity = ^$realtobits(data);
endfunction
Bit-stream Types
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.
Type Compatibility
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:
Unions and Structs
Even though these two unions and structs have the same signature, they implicitly define two anonymous types; they are thus not assignment compatible.
String Variables and Literals
string variables and literals behave differently.
null cannot be assigned to string variables.
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.
Syntax Confusion and Implicit Casting
The concatenation and assignment pattern syntax confusingly resemble each other a lot.
It is not always clear what assignments will be implicitly cast. enums are implicitly cast to ints, but not the other way around.
Classes
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.
Ref Ports
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
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:
When talking about hierarchy, references can be divided into three groups:
Downward references, starting from current module items;
Hierarchical references, starting from the top level; and
Upward references, starting from some module in between the top level and the current module.
Upward references can make the code very hard to understand, and hence to debug and maintain, so Sigasi warns you against their usage (rule 99).
module top(input i1, i2, output o1, o2);
mid mid1_inst(.i(i1), .o(o1));
mid mid2_inst(.i(i2), .o(o2));
endmodule
module mid(input i, output o);
int x;
assign x <= 3 * i;
assign o <= 3 * x;
bottom bottom_inst();
endmodule
module bottom();
initial $display(mid.x); // whichever mid's x could it be?
endmodule
Rule 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 (SVH) has a number of checks on VHDL coding style.
Extended identifier contains whitespace
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!
Line is too Long
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.
Magic number, bitstring, or string in statement
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.
s_output <= s_input mod 4 + 3;
s_output <= (s_input mod 4) + 3;
Constant width vector assigned to signal
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.
s_output <= "00000000";
s_output <= (others => '0');
Rule Configuration
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.
More details can be found here. Your license unlocks the features for your edition.
Updating
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.
Settings
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.
Talkback and Telemetry
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.
On Disk Caching
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 Projects View below the default VSC file explorer. From then on, you should use the Sigasi Projects View instead of the VS Code file explorer.
Every Sigasi project has mixed-language support.
Importing a Project from the File System
Open the folder you want to import through (File > Open Folder…). A pop-up will be shown asking you to create a Sigasi Project.
A project can also be created from the context menu in the explorer through Sigasi Visual HDL > New Project….
The Sigasi: New Project… command can also be run from the command palette.
Creating a New Project From Scratch
To create a new project, use the Create Sigasi Project button in the empty Explorer View. Alternatively, the command Sigasi: New Project… can be run from the command palette.
Importing Another Tool’s Project
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 .
Tutorial and Demo Projects
The extension contains both a tutorial project and demo project.
Tutorial
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.
You can also open a larger demo project using the command Sigasi: New Demo Project….
Project Configuration
Library Configuration
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.
VHDL and Verilog Version
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.
Workspace
To add a new project to your workspace, press File > Add Folder To Workspace.
Make sure the project you’re adding has a valid .project file.
Linked Resources
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.
Environment Variables
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.
Custom Project Variables
Some variables are automatically defined.
PROJECT_LOC with the PATH of your project
PARENT-<COUNT>-<VARIABLE> which points to COUNT levels above the PATH of the VARIABLE
For example, if your project lives in /design/projects/project1, then PARENT-2-PROJECT_LOC/companylibrary points to /design/companylibrary.
You can also use custom project variables, e.g., VUNIT, to point to your VUnit installation.
You can configure these variables as follows:
Press Ctrl+Shift+P to open the Command Palette
Select Preferences: Open Settings (UI)
In the Setting tab, navigate to Extensions > Sigasi for VHDL & SystemVerilog > General > Custom Project Variables
Add variables and their values as required
Note that custom project variables can be set on the User level and also per Remote or for a specific Workspace.
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.
Examining the Library Configuration
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.
Modifying the Library Configuration
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
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.
Configuration File
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.
Common Libraries
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.
Manually Adding Files to Common 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.
How Is “Common Libraries” Different From Other Folders?
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.
Adding Third-Party Libraries to a Project
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.
Library Database, Tools and Libraries
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.
Troubleshooting
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.
Common Libraries
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.
Active Tools and Libraries
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.
Migration from Sigasi Visual HDL 2024.1
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
This page documents the views the SVH extension adds to VS Code.
Sigasi Projects View
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.
Linked Libraries
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.
Buttons in the Sigasi Projects View
These buttons are available in the Sigasi Projects View:
Create a new file
Create a new folder
Refresh
Collapse all folders in the Sigasi Projects View
More Actions
Follow Cursor: links the Sigasi Projects View with the editor
Hide Excluded Files: toggles whether excluded files should be hidden
Configure Excluded Files: opens settings to configure files exclusions
Excluding Files
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.
Design Hierarchy View
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.
Buttons in the Design Hierarchy View
These buttons are available in the Design Hierarchy View:
Select Top Level Design Unit
Only show Instantiations (enabled)
Only show Instantiations (disabled)
Refresh the Design Hierarchy View
Search the Design Hierarchy View
Expand the full Design Hierarchy View
Collapse the Design Hierarchy View
More Actions
Follow Cursor: links the Design Hierarchy View with the editor
Auto Refresh
Sort by: Position
Sort by: Name
Sort by: Category
Problems View
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.
Libraries View
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.
Buttons in the Libraries View
These buttons are available in the Libraries View:
Search the Libraries View
Expand the Libraries View
Collapse the Libraries View
More Actions
Follow Cursor: links the Libraries View with 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.
Buttons in the UVM Topology View
These buttons are available in the UVM Topology View:
Select Root UVM Component
Search the UVM Topology View
Expand all components
Collapse all components
More Actions
Follow Cursor: links the UVM Topology View with the editor
Sort by: Position: sort components, ports, and interfaces by position in the source code
Sort by: Name (sort components, ports, and interfaces alphabetically)
Project Settings
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.
Configuring Linting Rules
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.
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.
You can export state machines to an SVG with the save button.
Dependencies Diagram
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).
Class Hierarchy Tree
The class hierarchy tree displays the superclasses, subclasses, or both.
Icon
Command
Description
Class Hierarchy
Displays all superclasses and subclasses.
Superclass Hierarchy
Displays all superclasses and implemented interface classes.
Subclass Hierarchy
Displays all subclasses that extend or implement the selected (interface) class.
Search
Searches the Class Hierarchy.
Toggle Show Qualified Class Names
Shows the qualified name next to each class.
Member List
The member list shows all members (fields, functions, tasks, and constructors) of a selected class in the class hierarchy tree.
The icon shown in the view describes the current active state of the members list options.
Icon
Command
Description
Show Inherited Members
Shows members inherited from superclasses.
Hide Inherited Members
Hides members inherited from superclasses.
Show Fields
Shows fields in the members list.
Hide Fields
Hides fields in the members list.
Search
Searches the Members.
Toggle Sort By Defining Class
Sorts members by the class in which they are defined.
Documentation View
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.
VHDL and SystemVerilog Editor
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.
Find References
To look for occurrences of a given identifier throughout your design, place your cursor on the identifier and right-click. Then select Find All References.
A search window will appear to the left of your workbench, 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.
Go To Definition and Hyperlinks
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.
Hover
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
Autocomplete and Content Assist
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 Interface
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.
Based on the Design Context
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.
Based on Templates
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.
Smart Indentation
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.
User-Defined Code Snippets
VS Code supports user-defined code snippets, as explained here . To add snippets yourself, follow the steps below.
Open the Command Palette (Ctrl+Shift+P) and type Snippets.
Select Snippets: Configure User Snippets.
Type vhdl or systemverilog to open the corresponding JSON file where you can add your snippet. See the examples below.
{"always posedge clk":{"prefix":"always","body":["always @(posedge ${1:clk}) begin","\t$0","end"],"description":"Insert an always block with posedge clock"}}
Code Lens
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.
Inlay Hints
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.
Other Editor Features
Code Folding
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.
Add Parentheses or Create a String
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.
Indentation and Whitespace
You can access the spaces customization controls at the bottom-right of the VS Code window.
If you click Spaces, a dialog box appears at the top-middle of the window.
The options in this menu are only valid for the file in the editor. Before using these actions, make sure your file has been saved.
Split Editor
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.
Sticky Scroll
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.
Customize Color Preferences
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.
Side-By-Side Comparison
With SVH, you can compare two files side-by-side.
Previous versions (local history or version control)
Comparing two files
Multi-Cursor Support
In order to enable multi-cursor support, open the Command Palette via Ctrl+Shift+P, type multi, and select Toggle Multi-Cursor Modifier from the list.
Open Design Unit
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.
Quick Outline
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.
Open Resource (Go To File)
In order to open a resource, press Ctrl+P, filter the list by typing, and select the resource that you want to open from the list.
VHDL Specific
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.
Code Highlighting
Highlighting classes for VHDL:
Syntax: Comment, Keyword, Number, String, Task Tag
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.
Type Conversion
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.
VHDL Code Formatting
Right-click in the editor and select Format Document to format your current VHDL file.
This includes:
indentation
spacing between keywords and references
vertically aligning symbols like <=
keyword casing
comment alignment
Context-Based
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.
Configuration
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.
Disable Formatting in Defined Regions
You can disable the formatter for defined regions in your VHDL source files by adding off and on tags:
off tag: -- @formatter:off
Turns off the formatter until the end of the file or until an on tag is encountered
on tag: -- @formatter:on
Reenables the formatter following an off tag
Format on Save
You can use auto-formatting whenever you save a file. This feature can be enabled with the
editor.formatOnSave setting.
Constant Propagation
SVH propagates the values of VHDL constants to the expressions where they are used.
VHDL 2019 Tool Directives
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.
VHDL Version
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
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.
Verilog and SystemVerilog Specific
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).
Code Highlighting
Highlighting classes for Verilog and SystemVerilog:
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.
Verilog and SystemVerilog Code Formatting
Right-click in the editor and select Format Document to format your current Verilog or SystemVerilog file.
The default formatter implementation corrects indentation only.
Verilog Version
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.
Include Paths and Initial Preprocessor Definitions
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.
Preprocessor
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.
Customization
You can customize the exported documentation.
Note: Diagram rendering is not supported in Remote SSH setups in versions earlier than 5.5.0.
Selecting a Specific Top Level
You can export documentation for an entire project or a specific top level.
When you select an entire project, the design elements will be listed alphabetically.
When you select a specific top level, design elements will be ordered in a breadth-first order from the top down.
Resources
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>.
Pagination
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.
Problems Section
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.
Output Directory
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.
Introduction Section
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.
The difference in documentation with the CSS settings described above is shown in the screenshots below.
Comment Association
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.
Special Cases
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.
Comment Markup With Markdown
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.
Example
This is the compilation order export for the VHDL tutorial project:
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.
Remote Development License Needs
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.
Example Setting
Below is an example of a semantic coloring configuration for VHDL.
The token keywords below are used to configure how a VHDL construct should be styled.
Token
Construct
sigasiPort
A VHDL port
sigasiConditionalProcessingVariable
A VHDL conditional processing variable
sigasiSignal
A VHDL signal
sigasiSubprogramParameterVariable
A VHDL variable parameter of a task or function
sigasiSubprogramParameterSignal
A VHDL signal parameter of a task or function
sigasiSubprogramParameterConstant
A VHDL constant parameter of a task or function
sigasiConstant
A VHDL constant or enumeration literal
sigasiAttribute
A VHDL attribute
sigasiGenericConstant
A VHDL generic constant value
sigasiGenericType
A VHDL generic type declaration
sigasiGenericSubprogram
A VHDL generic function or task
Customizing Your Setup
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.
First, by clicking the SAL icon in the Activity Bar icon.
Second, by choosing “Chat with SAL: Focus on Chat with SAL View” from the Command Palette (opened with Ctrl-Shift-P by default).
Finally, by selecting a piece of HDL code and using the context menu 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.
Configuring your AI model
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.
Connecting to remote OpenAI services
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.
Linting
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.
Configuring the Linting Rules
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.
Suppressing Problems
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.
No Linting for Common Libraries
Common Libraries are considered production-ready libraries.
Linting is skipped for all files in the Common Libraries folder.
Language-specific Linting Rules
The currently available linting rules are described in detail on the following pages.
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.
Naming Conventions and Header Comment Checks
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.
Quick Fixes
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.
Template Variables
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.
${id:env(name)}
Evaluates to the specified environment variable.
${filename}
Evaluates to the name of the file.
${filename_ext}
Evaluates to the extension of the file.
${user}
Evaluates to the user name.
${year}
Evaluates to the current year.
Importing Templates from SVH in Eclipse
If you previously used SVH in Eclipse, you can transfer any custom templates you created there to the SVH Extension for VS Code:
Export the custom templates as an XML file from within SVH in Eclipse.
Import the XML file(s) into the SVH Extension from the Templates Editor, or by using Sigasi: Import Eclipse Templates from the Command Palette.
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.
Properties
Enable project formatting settings, dictates whether the formatting settings specific to this project are enabled
Preserve newlines, the formatter respects newlines: it does not add or remove any
Align code, align lists such as generics or ports
Lowercase/Uppercase keywords, controls how the formatter transforms keywords: lowercase, UPPERCASE, or ignore
Alignment column for trailing comments, the column in the line to which the trailing comments will be aligned
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.
Configuration
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.
Designer Edition Linting Rules
Designer Edition linting rules are available for all editions.
Save the license that is sent to you in a file, e.g., sigasi.lic.
You can set the path to your license file in the SVH extension settings page.
Open the Command Palette in VS Code via Ctrl+Shift+P, type Settings, and select Preferences: Open Settings (UI).
Then type Sigasi to open the SVH extension settings. Type the path to your license file (e.g., /home/user/sigasi.lic) in the box under Sigasi: Path to License.
Once you configure your license, the SVH extension will ask you to restart VS Code.
Click Restart and wait for it to start using your newly configured license.
Floating Licenses
An example floating license is shown below. Note that the first line starts with SERVER or DAEMON.
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 setup a license server.
Read more about this on the License Server Management page.
Configuring a Floating License in SVH (FlexNet Client)
The license server can be configured in SVH or using an environment variable.
Configuring the License Server in SVH
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.
Configuring the License Server in an Environment Variable
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:
When using a floating license, Sigasi Visual HDL will automatically upgrade the license to the
edition that is required for the feature that is being used,
e.g., when first using the Block Diagram View, SVH will bump your license from Designer to Professional.
We will hold on to the acquired license for the remainder of your SVH session.
Enabling UVM Linting Rules
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 Enable Uvm linting 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
License to check out 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.
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.
VHDL
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
Behavioral, in all other cases
Verilog
For now, there are no rules that would benefit from a design unit description style, so no detection of description styles is performed.
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.
License Server Setup
Download the FlexNet Daemons
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.
Starting the FlexNet and Sigasi Daemon on Linux
The easiest way to start the Sigasi FlexNet daemon is like this (on Linux)
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.log Note: 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
Troubleshooting
If your license key does not work, the first things to check are:
Which version of the Sigasi license daemon are you using?
Is the MAC address correct?
Has the license expired?
Did you copy the license string exactly as it was sent to you?
Did you accidentally try to use a License Token as a license key?
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.
Typical Error Messages
Check the content of the Sigasi License diagnostic page by clicking on the SVH Edition Status Bar item on the bottom of the window.
No License
Is a valid license key path configured (or are valid environment variables used)?
Is the user trying to use an SVH 3 license in Sigasi 2.x?
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.
Sigasi Visual HDL (SVH) offers a new and sophisticated mechanism to construct a Sigasi project based on your own, existing build scripts.
The Basic Use Case
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’s scripted project support, you can avoid duplicating the information already present in your build scripts: SVH will extract all relevant information from the build scripts itself.
Enable the Experimental Project Support
This new project support is hidden by a feature flag and can be enabled in the VS Code settings JSON file. Note that the flag is not exposed in the settings UI.
A directory is recognized as a Sigasi project if it contains a project.sigasi file.
A wizard to create new projects is available from the command palette via Sigasi: New Project…. It offers the option to make a legacy project or a project backed by build scripts. The minimal script based project.sigasi will look similar to the following:
From top to bottom, the following configuration is deduced from the JSON:
A Sigasi project has a name. If the name is not explicitly set, it is derived from the name of the enclosing directory. In the example, the project’s name is MyProject.
One or more targets are listed to assemble the contents of the project. A target comprises a self-contained set of files that are compiled together. For SVH 2025.1 it is encouraged to configure exactly one target per project.
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 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 tb target is built by a Makefile. No further configuration is necessary for this target, since everything is derived from the build itself.
In the Sigasi Projects View, the structure of the captured project will be visualized in two different forms: as a file system centric Design perspective and as a logical Targets perspective.
The Design 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
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.
How Does it Work?
A Sigasi project is backed by one or multiple build scripts. Yet, it is independent of the technology that is used to build the project.
To capture and record the semantics of the build scripts, the build is executed 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.
Supported Tools
The following tools are natively supported and can be introspected on Linux and Windows:
Synopsis VCS
vcs
vhdlan
vlogan
Siemens Questa
qrun
qverilog
vlog
vcom
vlib
vmap
vopt
vsim
Cadence XCelium
xrun
TCL scripts are supported when passed to vsim via vsim -do.
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.
Predefined Environment Variables
SVH launches the build in a prepared environment, where the PATH variable is prefixed with a directory that contains the stub executables. In addition, the following environment variables are used. They allow SVH specific augmentation of the build scripts.
Environment Variable
Description
SIGASI_TARGET_SHELL
the shell that is spawned in order to run the target’s commands, e.g., /bin/bash -c or cmd.exe /c
SIGASI_COMPILATION_LOG
the absolute path of the log file that is being populated
SIGASI_PROJECT_DIRECTORY
the absolute path of the directory that contains the project.sigasi JSON file
SIGASI_COMPILER_STUBS_DIRECTORY
the absolute path of the directory that contains the tool stubs
SIGASI_TCL_SHELL
the absolute path of the TCL shell that replicates the Questa vsim -do TCL environment
Caveats and Troubleshooting
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.
The build must not be incremental in the way it is triggered from within SVH. 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. This situation will be detected by the tool. Yet, the build script might need adjustments to not cause side effects. The automatic refresh of targets can be disabled in the settings JSON "sigasi.project.enableAutomaticTargetRefresh": false.
[Back to top]This single page manual was generated on 2025-04-24.
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
in the Activity Bar icon.
Second, by choosing “Chat with SAL: Focus on Chat with SAL View” from the Command Palette (opened with 
