Extension Setup

This page explains how to install and configure Sigasi Visual HDL (SVH).

Requirements

VS Code Version

The extension requires VS Code or VS Codium version 1.77.0 or higher.

Java Runtime (Optional)

The path to use the Java Runtime (JRE) can optionally be configured in the settings. If empty, the extension will extract the included JRE in the user’s home folder.

• Linux: ~/.config/Code/User/globalStorage/sigasi.sigasi-vscode
• Windows: %AppData%\Code\User\globalStorage\sigasi.sigasi-vscode

If you wish to provide the JRE:

• The extension requires a Java Runtime
• The Java runtime must be 64-bit. Make sure to use JRE 11 or JRE 17
• You can check your Java version with java -version
• Java can be downloaded from several sources, a.o. Adoptium 
• Make sure the java executable is available in the PATH environment variable

Installation

You can install the extension from the VS Code marketplace .

To install the extension from VS Code, open the Extensions pane using Ctrl+Shift+X. In the Search field on top, type Sigasi. Click the Sigasi extension and click Install.

You can also download the self-contained VSIX file directly. Go to the SVH extension marketplace webpage , and on the right panel under Resources, click on Download Extension. This will give you the option to download the Windows x64 or the Linux x64 VSIX.

If you’re working on a remote host for your HDL development, the extension only needs to be installed on the remote.

Licensing

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.
• First, configure the Path To License. It can be a local node-locked license file or a floating license server, e.g., 27000@myserver.example.com.
• Optionally, configure the JRE location in Sigasi > Java: Path. Make sure to add the java executable name to the configured value.

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 manual page.

Talkback is disabled by default. To enable Talkback in the VS Code extension, open the settings and enable the Sigasi: Enable Talkback option.

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 setting Sigasi > Server > Caching: Enable On-Disk Caching.

Setting up a Project

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.

For project configuration, open the Sigasi Projects View.

Creating and Importing Projects

Importing a Project from the File System

First, open the folder you want to import through (File > Open Folder…). Then, open the Command Palette (Ctrl+Shift+P) and run the command Sigasi: Add Sigasi Support.

Creating a New Project From Scratch

To create a new project, open the Command Pallet (View > Command Pallete…), execute the command Sigasi: Create New Sigasi Project, choose the project location, then give your project a name.

Next, you need to have the project’s root folder to create a .project file in your folder containing the project configurations.

Once the .project file is detected, SVH will fully start, indicated by a Projects View below the default VSC file explorer.
From then on, you should use the Projects View instead of the VSC file explorer.

Every Sigasi project has mixed-language support.

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: Create 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.

See also: Tutorial Project in Sigasi Visual HDL

Demo

You can also open a larger demo project using the command Sigasi: Create 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 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 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. Bes sure to select the version you want.

Sigasi Support

To add or remove Sigasi support, you can right-click on a project from the Sigasi Projects View, click Configure, and Add/Remove Sigasi Support. This will enable or disable Sigasi support.

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.

Libraries

Introduction

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 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 make changes to 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.

How To Add Files To Common Libraries

In any newly created Sigasi project, the Common Libraries folder contains the VHDL files of the IEEE and STD libraries.

To add files, right-click the Common Libraries folder and select the New Linked Folder to create a Linked Folder pointing to the actual folder location that contains the files you wish to add to the Common Libraries.

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

If your project uses libraries from Quartus or Vivado or standalone libraries (e.g. UVM), SVH provides a mechanism that makes it easier to add such libraries to a project and to switch between versions of libraries and toolchains.

First, SVH needs to know the location of the toolchains and standalone libraries on your system. SVH can automatically detect Quartus and Vivado installations:

• in default installation locations: /opt, /tools, C:\, <home>, and <home>/Documents.
• via environment variables that point to installation or bin directories of these tools (e.g. QUARTUS_ROOTDIR, XILINX_VIVADO, PATH, etc.).

Note: You can run the Reload Toolchain Libraries command to see what toolchains were detected (they would have a (detected) mark).

You can override detected toolchains or add additional toolchain installations and external libraries in the extension settings:

• When adding a toolchain, you’ll have to specify:
  • the installation path,
  • the Kind (Quartus or Vivado), and
  • an alias that would be used in a project to reference this installation.
• When adding a library, you’ll have to specify:
  • the library path,
  • the library name, that would be used to map HDL files,
  • the layout, which would configure how to link this library (at the moment, only two layouts are supported: a UVM library layout or a Default one that would simply link, map, and add a specified directory to include paths), and
  • an alias that would be used in a project to reference this library path

Once you’ve added all required toolchains (or are happy with detected toolchains) you have to extract their libraries with the Reload Toolchain Libraries command. This would allow using these libraries in your project. You can choose whether to extract only family-independent libraries or all libraries.

Now you can run the Manage Linked Libraries command and select what libraries you want to use in your project (if you don’t need them later on, you can unselect them here as well). After pressing the OK button (or Enter), the selected libraries will be linked to your project in the Common Libraries folder (while unselected libraries will be removed). To the right of the library name in a wizard you can see what library or toolchain version is used.

Note: If the project configuration for a linked 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) on this wizard page. Pressing the OK button (or Enter) will fix the configuration of all linked libraries that are out-of-sync.

If you have multiple toolchain installations or library versions and would like to use a different one, you can run the Set Active Toolchain or Set Active Library command and set a desired version as active.

A Reset Active Toolchains and Libraries command removes active toolchain and library aliases from project configuration files if those are not used by currently linked libraries. It can make configuration cleaner without affecting libraries linked to a project.

Note: When you link libraries this way, your project file and project settings will contain only aliases of toolchains and libraries, not their absolute paths on your system. This way, when multiple people work on a project, it’s sufficient to add a toolchain or library with the same alias in workspace settings (or use the same environment variable to point to the library or toolchain installation path).

Views

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 displaying the Preference View.

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 > Set Library > 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
  • Toggle Follow Cursor (links the Sigasi Projects View with the editor)

Hierarchy View

Initially, the Hierarchy View will be empty. To use the Hierarchy View, right-click an entity, architecture, or module name in the editor and select Set as Top Level from the pop-up menu. This will populate the Hierarchy View with the structure of your top level.

As you make changes to the design, the Hierarchy View will not automatically refresh. To refresh the Hierarchy View, use the refresh button ().

If you want the selection in the Hierarchy View to follow your position in the editor, make sure to enable Follow Cursor from the More Actions () menu.

Buttons in the Hierarchy View

These buttons are available in the Hierarchy View:

• Expand the full hierarchy
• Only show Instantiations (enabled)
• Only show Instantiations (disabled)
• Refresh the Hierarchy View
• Collapse the hierarchy
• More Actions
  • Toggle Follow Cursor (links the Hierarchy View with the editor)
  • Toggle Auto Refresh on save
  • 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.

UVM Topology View

Sigasi Visual HDL Professional Edition or Sigasi Visual HDL Enterprise Edition, [Only for SystemVerilog]

The UVM Topology View shows the verification environment’s component topology. To view a component’s topology, right-click its class name in the editor and select Set as Root UVM Component from the pop-up menu. This will populate the UVM Topology View 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.

Buttons in the UVM Topology View

These buttons are available in the UVM Topology View:

• Expand all components
• Collapse all components

Other available actions:

• Sort components, ports, and interfaces alphabetically.
• Sort components, ports, and interfaces by position in the source code.

Preference View

To open the Preference View, right-click the project, folder, or file you want to configure in the Sigasi Projects View. This view allows you to configure all preferences 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.

Configuring Linting Rules

You can configure linting rules per project, folder, or file by right-clicking a project, folder, or file > Open Preference View in the Projects View and then selecting Verilog Errors/Warnings or VHDL Errors/Warnings. In the middle of the page, Click here to enable to activate the rule configuration.

Refer to the linting documentation to learn more.

Graphical Views

Block Diagram View

Sigasi Visual HDL Professional Edition or Sigasi Visual HDL Enterprise Edition

The Block Diagram View 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 View by right-clicking in the editor and selecting Show In > 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 have to select it, right-click, and click Open Entity Declaration, Open Architecture, or Open Module.

To find an object in the Block Diagram, you can navigate from your code to the Block Diagram. In your code, right-click a signal, port, process, generate, or instantiation and select Show In > Block Diagram - just like when opening the Block Diagram View the first time. If the Block Diagram is already open, the corresponding element will be highlighted, and the Block Diagram View will center upon it.

You can export the Block Diagram View to an image with the save button on the toolbar. Both SVG and PNG are supported. Choose a *.svg filename for SVG export or a *.png filename for PNG export.

State Machines View

Sigasi Visual HDL Professional Edition or Sigasi Visual HDL Enterprise Edition

The State Machines View 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 Machine View by right-clicking in the editor and selecting Show In > State Machines. 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 image with the save button. Both SVG and PNG are supported. Choose a *.svg filename for SVG export or a *.png filename for PNG export.

Dependencies View

The Dependencies View 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 View also makes it easy to detect orphaned files.

The view is automatically updated each time you save your files.

You can open the Dependecies View by right-clicking in the editor and selecting Show In > Dependencies.

The Dependencies View 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 View can help you navigate, too. Double-click a file name in the diagram to open the corresponding editor.

You can export this diagram for documentation by clicking the save button.

UVM Diagram View

Sigasi Visual HDL Professional Edition or Sigasi Visual HDL Enterprise Edition, [Only for SystemVerilog]

The UVM Diagram View displays a graphical representation of the 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.

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 connect 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 image (supports both SVG and PNG).

Net Search View

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 double-clicking the search results.

Preprocessor View

In order to open the Preprocessor View, which shows preprocessed text, right-click in the editor and select Show In > Preprocessor.

Class Hierarchy 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, click the class name, right-click, 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.
	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.
	Toggle Sort By Defining Class	Sorts members by the class in which they are defined.

Documentation View

Sigasi Visual HDL Professional Edition or Sigasi Visual HDL Enterprise Edition

The Documentation View gives you a live preview of the automatic documentation SVH can generate for your project.

Sigasi Visual HDL in the VS Code Editor

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.

Language-specific features are explained in the “VHDL Specific” and “Verilog and SystemVerilog Specific” sections.

Code Highlighting (Syntax Coloring)

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.

See also:

• Extension Setup
• Project Setup

Type-time Syntax Error Reporting

SVH marks VHDL and SystemVerilog syntax errors while you type. It will also report broken SystemVerilog preprocessor code.

Project Exploration and Navigation

SVH offers powerful techniques to explore a file or project and navigate through it. This section covers: Occurrence Highlighting, Find References, Go To Definition and Hyperlinks, and Hovers.

Occurrence 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.

You can also configure your own templates as described in User-Defined Code Snippets.

Instantiating a Design Unit

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.

A number of VHDL-specific and Verilog and SystemVerilog-specific autocompletes are available in SVH.

Signature Helper

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.

See also:

• Indentation and Whitespace

Code Formatting

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.

Read more in the VHDL code formatting and Verilog and SystemVerilog code formatting sections.

Rename Refactoring

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.

VHDL Snippet Example

{
    // Place your snippets for VHDL here.
    "package declaration": {
        "prefix": "package",
        "body": [
            "package ${1:name} is",
            "\t$0",
            "end package $1;"
        ],
        "description": "Insert package declaration"
    }
}

SystemVerilog Snippet Example

{
    // Place your snippets for Verilog and SystemVerilog here.
    "always posedge clk": {
        "prefix": "always",
        "body": [
            "always @(posedge ${1:clk}) begin",
            "\t$0",
            "end"
        ],
        "description": "Insert an always block with posedge clock"
    }
}

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 key editor.autoClosingQuotes.

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 key editor.stickyScroll.enabled.

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
• Semantic: Constant, Port, Signal, Type, Variable, Attribute, Function, Procedure, Labels

VHDL Specific Autocompletes

Declaring a Component

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') when enable = '1'
     else (others => '1') when input  = '1' -- else on new line
     else (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 set your formatting preferences, right-click the project name in the Sigasi Projects View and select Open Preference View. 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 key editor.formatOnSave.

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 Open Preference View. 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 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:

Stuttering is enabled by default but can be toggled using the configuration option Enable stuttering with the key sigasi.vhdl.stuttering.

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:

• Syntax: Comment, Keyword, Number, String, Task Tag, Operator
• Semantic: Assignment, Class, Covergroup, Macro, Enum, Function, Localparam, Module, Net, Wire, Parameter, Port, Type

Verilog and SystemVerilog Specific Autocompletes

Inserting an Include File

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 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.

Documentation Generation

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.

Export Documentation

To export documentation, follow the steps below:

• Open the Command Palette (Ctrl+Shift+P) and type Export
• Select Sigasi: Export Project Documentation
• Follow the wizard steps to customize your documentation

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.

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.

Further Customization

You can further process exported HTML documentation, as explained in Use a Word macro to Scale Diagrams in HTML documentation.

Custom CSS

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.

body {
   background-color: Azure;
   font-family: sans-serif;
}

h1 { color: Tomato; }
h2 { color: Orange; }
h3 { color: Gold; }
h4 { color: Aquamarine; }
h5 { color: BlueViolet; }

Entire sections for entities, architectures, and modules can have different background colors. Likewise, process lists can have different background colors.

.entity, .module { background-color: AliceBlue; }
.architecture    { background-color: Cornsilk; }
.processes       { background-color: WhiteSmoke; }

You can give tables color banding (alternating row or column colors), including using different colors within sections.

tr:nth-child(even) { background-color: Lavender; }
.entity table tr:nth-child(even) { background-color: FloralWhite; }

It’s also possible to hide parts from view.

#revision { display: none; }

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>```

Compilation Order Export

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 value (CSV) list of files in your project, follow the steps below:

• Open the Command Palette (Ctrl+Shift+P) and type Export.
• Select Sigasi: Export Compilation Order CSV.
• Select the project and, optionally, a top level design unit.

As a result, 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 (for the VHDL tutorial project):

work, trouble.vhd
work, drive_rst_start.vhd
work, packages/pixel_tb_pkg.vhd
work, libimage/ram.vhd
work, libimage/image.vhd
work, step_3_pixelbuffer.vhd
work, step_5_dut_engine.vhd
work, step_1_dut_core.vhd
work, packages/pixelbuffer_pkg.vhd
work, libimage/image_serializer.vhd
work, step_2_dut_top.vhd
work, libimage/blockimage.vhd
work, step_4_pixel_testbench.vhd
work, step_6_image_testbench.vhd

The file paths are relative to your project root, except on Windows when a file is on a different drive.

Remote Development

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 .

Remote Development Setup

• Download, install, and start VS Code on your workstation (the laptop in our example): https://code.visualstudio.com/download 

  

• 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.
• Note that the Sigasi VS Code extension with default settings will extract a shipped JRE. If you want to use another JRE that is already installed on the server, look for Sigasi > Java: Path in the settings and enter he path to your java (17 or higher) executable.
• 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>].

AI Chat

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 LMStudio.

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.

export SIGASI_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.

export SIGASI_AI_MODEL="gpt-4-turbo"           # with the GPT 4 model
export SIGASI_AI_API_KEY="your-openai-api-key" # with this API key

Connecting to a local model

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.

1. Download the latest version of LM Studio .

2. Open LM Studio. From the home screen, search and download the model you want to use.

   

3. Navigate to the Local Server Window.

   

4. At the top of the local server screen, use the selection menu to choose the model you wish to load.

   

5. (Optional) Configure local server parameters, such as the Context overflow policy, the server port and Cross-Origin-Resource-Sharing (CORS).

6. Set the environment variables for Sigasi Visual HDL. You can get the necessary configurations most easily in the Example window under chat (python).

   • SIGASI_AI_API_URL to the base URL
   • SIGASI_AI_MODEL to the model name
   • SIGASI_AI_API_KEY to the API key (if required)

   

   In this example:

   export SIGASI_AI_MODEL="TheBloke/deepseek-coder-6.7B-instruct-GGUF"
   export SIGASI_AI_API_URL="http://localhost:1234/v1"
   export SIGASI_AI_API_KEY="lm-studio"
   

7. Launch Sigasi Visual HDL and start a conversation using your configured local LLM.

Linting and Quick Fixes

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 preference page. Look into the documentation of a specific rule for more details on its effect.

• List of Linting Rules for Verilog and SystemVerilog
• List of Linting Rules for VHDL

Linting rules can be configured per project, folder, or file by right-clicking a project, folder, or file in the Sigasi Projects view, selecting Open Preference View, and clicking VHDL Errors/Warnings or Verilog Errors/Warnings.

Then, enable custom validation settings to activate the rule configuration.

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 preferences 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.

• List of Linting Rules for Verilog and SystemVerilog
• List of Linting Rules for VHDL

Manual Configuration

Note: we discourage manual configuration, especially for rule parameters other than severity, because it’s easy to get the syntax wrong.

To configure the severity of rules, add a line using this template:

${rule id}/severity/${path}={error|warning|info|ignore}

To configure a parameter of a rule, add a line using this template:

${rule id}/params/${parameter}/${path}=${value}

• Where ${rule id} can be the number of the rule (e.g. 140) or all to specify preferences for all rule IDs at once.

  Rule IDs can be found in the Errors/Warnings settings under the Project Properties and Workspace Preferences. They are also included in the list of VHDL Linting Rules and the list of Verilog/SystemVerilog Linting Rules.

• 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 #`.

Examples

72/severity/<project>=IGNORE
72/severity//Folder\ name/Extra\ folder=INFO
72/severity//test/top.vhd=WARNING
237/params/fsm_state_type//test/top.vhd=ARRAY_OF_LOGIC
236/params/allowed_literal_pattern/<project>=0|1

Markers

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 expressions 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.

Project Formatting Configuration

Project Formatting Configuration

You can configure VHDL formatting preferences 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 or not the formatting preferences specific to this project are enabled
• Preserve newlines, the formatter respects newlines: it does not add or remove any
• Use vertical alignment, 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

Setting Up a UVM Project

Sigasi Visual HDL (SVH) provides several features that help write UVM testbenches. However, you first have to set up a project with a UVM library to use these features.

This page describes how to set up a UVM project in SVH. The instructions described here are general; refer to the Project Setup section for details on project setup.

1. 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.

2. Add the UVM sources to the project by adding a linked folder to the source folder of the reference implementation of UVM. At this point, most of the errors should be gone. If you don’t have UVM source files on your system yet, you can download them here .
   Note: we highly recommend adding this linked folder to the Common Libraries folder, since sources in this folder are treated as read-only and are not checked for errors. We also recommend that every file except uvm.sv be excluded from being built.

3. Finally, update the include paths, which you can easily do through a Quick Fix. There should be a number of Preprocessor include paths are not configured correctly warnings on include statements of UVM header files. You can easily find these warnings through the Problems View. A Quick Fix that automatically updates the include paths of a project is available on these warnings. A bulk mode is also available, allowing you to fix all the missing include paths in the current project. Alternatively, the include paths can be changed through the Add to Include Paths context menu item, which is available in the Sigasi Projects View. You can also manually update the include paths through the Preference View, under the Verilog Preprocessor page.

After completing the steps above, all of the problems related to UVM configuration should be gone. You can now use all the UVM features, such as the UVM Diagram and the UVM Topology View.

Verilog and SystemVerilog Linting

List of Verilog and SystemVerilog Linting Rules

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.

	Description	ID
	Empty loops and conditional branches	1
	Check naming conventions	2
	Disallow reg datatype	3
	Named and positional port connections cannot be mixed	5
	The packed keyword is required in packed structs and unions	6
	The module name is a keyword in VHDL and may cause problems in mixed language projects	7
	Case statement does not cover all cases	8
	The for loop statement misses mandatory part (Verilog)	9
	Function prototype has implicit return type	10
	Parameter port list cannot be empty	11
	No semicolon expected at this point (Verilog)	12
	Verilog disallows empty assignments of ordered parameters (Verilog)	13
	Implicit subprogram port direction	14
	Default clause has to be the last item in a case statement	15
	Case statement has multiple default clauses, but only one default clause is allowed	16
	File name does not match design unit	17
	File contains multiple design units	18
	Parameters must have a default value	19
	Verilog code line too long	20
	Tabs are not allowed	21
	File header comment does not match required pattern	22
	Named port connections have to be used for all instances with many ports	24
	Named and positional parameter overrides cannot be mixed	25
	Named parameter overrides have to be used for all instantiations with many parameters	26
	No event control at the top of always construct	27
	Default member must be last in assignment pattern	28
	Only one default member expression is allowed per assignment pattern	29
	Overwritten type key in assignment pattern	30
	Duplicate member key in structure assignment pattern	31
	Mixed named and ordered notation in assignment pattern	32
	Only variable output ports can have a default value in non-ANSI notation	33
	Only input or variable output ports can have a default value in ANSI notation	34
	Register initialization in declarations	35
	Duplicate formal item within the instantiated unit	37
	Missing actuals for formals that have no default value	38
	Excessive number of actuals in ordered notation	39
	Default clause missing from case statement	40
	Non-blocking assignments are not allowed in functions	41
	Consecutive underscores in unit / port identifier	42
	Underscores at end of unit / port identifier	43
	Report encrypted regions	44
	Timing controls are not allowed in functions	46
	Multiple statements per line	47
	Missing bit width for parameters wider than 32 bits	48
	Net data types must be 4-state	50
	Net data types integral	51
	Empty parameters	53, 54
	Invalid package item	55
	Named connections are not allowed with blank ports	56
	Unexpected preprocessor directive inside design elements	57
	Non-packed member in packed structure	59
	Illegal type in untagged union	60
	Illegal class member access	61
	Overridden method signature mismatch	62-68
	Local parameter has to be initialized	69
	Local parameter cannot be overridden	70
	Declaration not found	71
	Attempted implicit declaration with default nettype none	73
	Invalid enumeration element range format	74
	Range of enumeration element is too large	75
	Invalid construct	76
	Invalid randomize argument	77
	Type checking	78, 79, 94, 100, 131
	Constraint class scope missing	80
	Constraint class with packed dimensions	81
	Out-of-bound method signature mismatch	82-92
	Ambiguous reference	93
	Duplicate declaration	95
	Invalid UDP initial value	96
	Implicit net	97
	Duplicate conditions	98
	Upward reference	99
	Duplicate continuous assignments	101
	Different file encoding for including file and included file	102
	Missing macro identifier	103
	Undefined macro	104
	Forbidden macro identifier	105
	Missing `endif	106
	Missing identifier following expansion	107
	Failed include	108
	Macro expansion depth limit reached	109
	Inclusion loop	110
	Issues found while expanding macro	111
	Missing macro argument list	112
	Mismatched number of arguments	113
	Unexpected directive operand	114
	Identifier expansion with an invalid sequence of tokens	115
	Unexpected conditional compiler directive	116
	Whitespace following a backtick	117
	Unknown time literal	118
	Unexpected operand	119
	Missing operand	120
	Invalid preprocessor syntax	121
	Unsupported include path	122
	Syntax error	123, 124
	Invalid macro argument list	125
	Unbalanced expression	126
	Unbalanced directive invocation	127
	Unused macros	128
	Prohibited macro	129
	Unused declaration	130
	Hidden non-virtual methods	132
	Unexpected empty concatenation	133
	Unexpected empty assignment pattern	134
	Incorrect port declaration	135-139
	Duplicate port	140
	Empty port in ANSI port list	141
	Empty port	142
	Vector as edge event expression	143
	Implicit vector to boolean conversion	144
	Missing include path in preprocessor configuration	155
	End name does not match declaration name	158

UVM Linting Rules

UVM linting rules require a Sigasi Visual HDL Professional Edition or a Sigasi Visual HDL Enterprise Edition license. Note: you need to explicitly configure a license to check out to at least Sigasi Visual HDL Professional Edition to enable these linting rules.

	Description	ID
	Unregistered UVM object	145
	Incorrect utility macro	146
	Type argument value does not match containing class	147
	Incorrect UVM object instantiation	148
	UVM object name does not match variable name	149
	Unexpected output system task	150
	Incorrect override of UVM object	151
	Deprecated UVM API	152
	UVM phase method does not call superclass method	153
	Incorrect constructor for UVM object or component	154

Deprecated Linting Rules

Deprecated linting rules were used by Sigasi at some point, but they’ve been removed or superseded in the most recent version.

VS Code FAQ

Debug Log

To check whether Sigasi Visual HDL (SVH) started successfully, you should navigate to Sigasi’s output view. You can do this by opening the Command Palette (Ctrl+Shift+P) and selecting Sigasi: Open Log.

The Output View should say Language client connected from ...

The logs in the Sigasi output view might contain errors from the client and server. If errors are present, please copy them and include them in your email to support+vscode@sigasi.com.

SLF4J Errors

The following error messages in the Output View can safely be ignored:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

OutOfMemoryError: Java Heap Space

If Java runs out of memory, you will see java.lang.OutOfMemoryError: Java heap space in the log.

To avoid this, go to the settings (Ctrl+Shift+P > Preferences: Open Settings (UI) > Sigasi) and set the Sigasi > Server: Arguments. Increase the value for Xmx to more than the default 8g.

Troubleshooting

Server Logs

On some occasions, we might ask you to share server logs.

Before obtaining server logs, it’s best to enable debug logging. For more detailed logging, open the settings and change Sigasi > Server > Log: Level to debug.

The location of the server logs depends on your OS.

• On Linux, the logs are below ~/.config/Code/logs
• On Windows, the logs are in %AppData%\Code\logs

Then find [datetime]/window[1]/exthost/output_logging_[datetime]/[0-9]-Sigasi{Tracing}.log. For each occurrence of [datetime], choose the most recent directory available.

We recommend opening the exthost folder using the command Developer: Open Extension Logs Folder.

Note: These logs contain file names from your project, so only send them to us if you’re allowed to do so.

Issues Caused by VS Code Settings

Ctrl+Click Doesn’t Work

If Ctrl+Click doesn’t Open Declaration, it’s likely caused by an incorrect VS Code setting. In the VS Code Selection menu, there is an entry to switch the multi-cursor modifier to Ctrl+Click.

Even accidentally clicking that entry (e.g., when trying to enable Column Selection Mode) will change the setting for the multi-cursor modifier. This results in Alt+Click being used when trying to Open Declaration instead of the usual Ctrl+Click. You can click that same entry again to switch back to using Ctrl+Click.

Hide Signal Assignments in Outline

VS Code offers an array of settings to hide symbols from the outline. If you specifically want to hide signal assignments, you have to disable outline.showOperators in the VS Code settings. To do this, navigate to File > Preferences > Settings (or use the shortcut Ctrl+,), and then search for outline.showOperators.

VHDL Linting

List of VHDL Linting Rules

The table below lists the VHDL 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.

	Description	ID
	Null range: The left argument is strictly larger than the right	1
	Positional associations order	2
	‘Others’ position in associations	3
	Multiple others in associations	4
	Input port cannot be assigned	5
	Subprogram parameter cannot be assigned	6
	Constant cannot be assigned	7
	‘others’ has to be the last alternative in a case statement	9
	Deprecated IEEE packages	8
	Only one ‘others’ choice is allowed	10
	Case statement does not cover all cases	11
	Case alternative contains redundant choices	12
	Case statement contains all choices explicitly. You can safely remove the redundant ‘others’	13
	Case alternative contains duplicate choices	14
	C style equality operator	15
	C style inequality operator	16
	Incomplete associations	17
	Duplicate associations	18
	Invalid character literal	19
	Infinite loop. Loop is missing a wait, return or exit statement	20
	Function declarations in a package cannot have a function body	21
	Missing function body	22
	Invalid bit string literal	23
	Null range: The left argument is strictly smaller than the right	26
	Duplicate named associations	27
	Duplicate ‘all’ -style binding for component declaration	28
	Duplicate component instantiation binding	29
	Duplicate component instantiation binding	30
	Incorrect number of associations found in mapping	32
	A positional association cannot follow after a named association	33
	A signal cannot be the target of a variable assignment	34
	A port cannot be the target of a variable assignment	35
	A variable cannot be the target of a signal assignment	36
	Non-standard packages	37
	A process must either have a sensitivity list or contain one or more wait statements	38
	A process with a sensitivity list cannot contain any wait statements	39
	Procedure declarations in a package cannot have a procedure body	40
	Procedure declarations in a package body must have a procedure body	41
	Generate statements must have a label	42
	Instantiation statements must have a label	43
	Block statements must have a label	44
	There has to be a whitespace before physical units	47
	Unbound component instantiations	48
	Superfluous library clause	49
	Library is not available	50
	Matching case statement	51
	External name alias	52
	VHDL version check	53
	Duplicate declaration	54
	Find unused declarations	55
	Bitstrings may only contain std_logic metavalues	57
	A unary condition operator parentheses	58
	Duplicate design units	64
	Find unused ports	67
	Find unused generics	68
	Duplicate enum literal	69
	Invalid identifier	70
	Find dead states in state machines	71
	Find incomplete sensitivity lists	72
	Find superfluous signals in sensitivity lists	73
	Function pureness validation	76
	Find dead code	79
	Missing implementation	80
	Incorrect attribute class	81
	Invalid variable assignment	82
	Invalid signal assignment	83
	Report encrypted files	84
	Find duplicate signals in sensitivity lists	85
	A subprogram call cannot have an empty parameter lis	86
	Detect signals and variables that are never written	88
	Detect signals and variables that are never read	89
	None or multiple matching entities for component	90
	Unexpected tokens	91
	Check naming conventions	92
	Incomplete port map or generic map: using defaults	94
	Check line length	97
	Array assignment validation	144
	All references must have the same capitalization as their declaration	163
	Check for positional associations in instantiations	164
	Protected type bodies are not allowed in a package	168
	Invalid port associations	169
	VHDL version mismatch	170
	Invalid use of ‘bus’ keyword	171
	Invalid function parameter mode	172
	Invalid variable parameter in function	173
	Invalid function return type	174
	Invalid deferred constant declaration	175
	This declaration is not allowed in the current declarative region	176
	Order of generic and port associations	177
	Name mismatch	178
	Unexpected return type	179
	Configuration issue: Incorrect component name	180
	Configuration issue: Incorrect instantiation statement label	181
	Configuration issue: Missing or incorrect binding indication	182
	Configuration issue: Incorrect name in binding indication	183
	Incorrect use of keyword all	184
	Redundant boolean equality check with true	185
	Boolean equality check with false	186
	Check for component/entity mismatch	187
	Header comment does not match pattern	188
	Filename must contain primary unit name	189
	Empty loop statement	190
	VHDL 87 file declarations	191
	Entity name is a keyword in Verilog and may cause problems in mixed projects	192
	Concatenation of unconstrained aggregate	194
	Empty sensitivity list	197
	Instantiation mismatch	198
	Range wrapped inside parentheses	199
	Incomplete record aggregate	200
	No elements in a list	201
	Trailing separator in a list	202
	Cannot case on a type declaration	209
	Index out of range	210
	Slice has wrong direction	211
	VHDL version check	212
	Invalid use of return type identifiers	213
	Conditional return statements	214
	String literal is not properly closed	215
	An exponent for an integer literal shall not be negative	218
	Declaring the library ‘work’ is not allowed inside a context declaration	219
	Referencing the library ‘work’ is not allowed inside a context declaration	220, 221
	Common Libraries version mismatch	222
	VHDL version check	223
	Check case of non-keywords	224
	Type validation	226
	Loop variables cannot be assigned	227
	Whitespace in extended identifier	228
	Declaration not found	229
	Sequence of operators without parentheses	230
	Constant width vector assigned to signal	231
	Comparison of vectors with different sizes	232
	Missing full constant declaration	233
	Incorrect full constant subtype	234
	Magic number, bitstring, or string in statement	235
	Unconstrained signal or variable of integer type	236
	Unexpected FSM state type	237
	Incomplete reset branch	238
	Deep nesting of conditional and loop statements	239
	Unexpected keyword capitalization	240
	Incorrect vector range direction	241
	File contains multiple primary units	242
	Secondary unit in unexpected file	243
	Prohibited attribute	244
	Prohibited keyword or operator	245
	Prohibited package	246
	Prohibited pragma	247
	Prohibited library	248
	Clock signal not used as clock	249
	Unexpected clock edge specification	250
	Missing label	251
	Inconsistent reset style	252
	Multiple objects in one declaration	253
	Inconsistent clock edge usage	254

Deprecated Linting Rules

Deprecated linting rules were used by Sigasi at some point, but they’ve been removed or superseded in the most recent version.

License Key Management

Introduction

Sigasi Visual HDL (SVH) supports both node-locked and floating license keys. The SVH edition is controlled by the license key.

This page explains how to configure your Sigasi license in VS Code.

Node-locked Licenses

An example node-locked license is shown below. Note that the first line starts with INCREMENT.

INCREMENT com.sigasi.hdt sigasi 2.0 18-nov-2012 uncounted \
        VENDOR_STRING="company:www.example.com;mac:10f2dd92c5ac;name:John \
        Doe;type:trial" HOSTID=ANY ISSUER=Sigasi ISSUED=21-Oct-2012 \
        START=21-Oct-2012 SIGN="0CCC 87EA 9BB6 256E 7D81 E49D B2A6 \
        E53D 1CA5 41D4 63DF 8671 5695 EF82 0E30 1028 732D DED3 0999 \
        FD11 8B97 42B0 7CF2 F51F 20A0 DA6E 7F54 9D64 FF29 49AB"

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.

DAEMON sigasi port=27001
SERVER your_server_name1 BD41FCF5DE27 27000
INCREMENT com.sigasi.hdt sigasi 2.0 18-nov-2012 4 \
        VENDOR_STRING="company:www.example.com;mac:10f2dd92c5ac;name:John \
        Doe;type:trial" HOSTID=ANY ISSUER=Sigasi ISSUED=21-Oct-2012 \
        START=21-Oct-2012 SIGN="0960 9728 7193 4DA5 15C2 3652 21E1 \
        EF82 1060 8FC1 9EA6 0C43 4842 C50B 684F E4DA 8EEF 37E9 5384 \
        8DF4 106C 52B4 EECE 0A69 CBAC 0CF2 47E2 00F2 A244 E22F"

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. There is a separate page documenting how to do this License Server Management.

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:

27000@myserver1.example.com,27000@myserver2.example.com,27000@myserver3.example.com

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.

Linux example:

export SIGASI_LM_LICENSE_FILE="27000@myserver.example.com"

For redundant license servers, the servers should be separated using commas (,). We recommend you specify the primary server first in the list. For example:

export SIGASI_LM_LICENSE_FILE="27000@myserver1.example.com,27000@myserver2.example.com,27000@myserver3.example.com"

Configuring a license to check out

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.

For some features, like the UVM linting rules, the automatic upgrading is not done. To activate and use these features, you need to explicitly configure a license to check out. 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 Professional license is configured as the license to check out, but a documentation export is performed, SVH will upgrade to an Enterprise license.

Sigasi Visual HDL Talkback

Sigasi uses Talkback and telemetry services to better understand how our users engage with our products and to make improvements. Talkback automatically collects metadata about how someone is using Sigasi Visual HDL - only telemetry, no design data - and sends this metadata to Sigasi through a secured connection. By enabling Talkback, you help us improve SVH.

The LSP server process of SVH can be configured to use Talkback. The VS Code client part of our extension instead uses the telemetry setting.

Why Should I Enable Talkback?

By enabling Talkback, you help us improve SVH:

• Talkback provides us with feature usage. This information helps us determine which features are valuable for you as a user so we can adjust our product roadmap.
• Talkback collects performance statistics that we can relate to the project sizes. Together with our in-house performance tests, this helps us keep the SVH compiler and user interface fast.
• Talkback helps us reduce software errors by collecting incident reports from various use cases.
• Talkback is automatic and less cumbersome than feedback surveys.
• Talkback is required to use our free Sigasi Community Edition.

What Information Does Talkback Collect?

Talkback and telemetry transmit meta-information about your project, operating system, Java Virtual Machine, tool usage, build performance, system statistics, license type, file system paths, and incident reports (stack traces) that occur due to software errors. We also collect MAC addresses, and IP addresses that are visible when a client connects to the Talkback server. Talkback never transmits any HDL code, but it may send identifiers. All transmissions use industry-standard SSL secure connections.

We identify your Sigasi installation and session using a generated identifier, specifically a standard Java universal unique identifier UUID . The installation identifier is stored in your global VS Code preferences, while the session identifier changes every time you restart.

Talkback stores all the information it transmits in a local log file so that you can inspect it. The data is human-readable in JSON format. You can access the Talkback log - to verify what is being sent - through the Command Palette Sigasi: Open Talkback Log Folder command.

Talkback only concerns the LSP server process.

SVH collects telemetry data when an error occurs within the extension itself. We use this data to fix bugs and help guide the direction of the product. Our telemetry transmission is aligned with the VS Code telemetry setting and can be tweaked using the VS Code setting: telemetry.telemetryLevel. Note that this VS Code setting is on by default.

For more information regarding telemetry, refer to the VS Code telemetry documentation .

How does Sigasi use this information?

Sigasi uses the information transmitted by Talkback for marketing and product planning and development. We use it to decide which features to develop and improve, find and fix bugs, and find and fix performance issues.

The information is sent to us through an Amazon Web Services proxy and stored on one of our servers. It is backed up to Google Cloud Services.

How Do I Enable or Disable Talkback?

Talkback is always disabled by default. To enable or disable Talkback, follow the steps below.

• Open the Command Palette through Ctrl+Shift+P
• Select Preferences: Open Settings (UI)
• In the Setting tab, navigate to Extensions > Sigasi for VHDL & SystemVerilog > Enable Talkback
• Check or uncheck the checkbox

Telemetry

The VS Code telemetry setting  is on by default. To enable or disable it, follow the steps below.

• Open the Command Palette through Ctrl+Shift+P
• Select Preferences: Open Settings (UI)
• In the Setting tab, navigate to Application > Telemetry
• Edit the value in the dropdown to suit your needs

What about my Firewall or Proxy?

Talkback uses the HTTPS protocol for data communication. If your firewall blocks outgoing SSL connections to our server, Talkback cannot send diagnostics. Your firewall should allow outgoing connections to https://talkback-sigasi.sigasi.com/ .

Talkback does not support proxies. If Talkback cannot connect to our server directly because of your firewall or proxy server, you are required to purchase a commercial license .

Disabled Telemetry Features Are Against Our Corporate Policy. What Can I Do?

Our Sales Team will be happy to discuss trial options with you.

Design Units Description Style

Introduction

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.

License Server Management

Introduction

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.

FlexNet Version 11.16.4.0

• Linux 64 bit 
• Windows 64 bit  (Windows 7 or newer)

FlexNet Version 11.13.1.2

• Linux:
  • Linux 64 bit 
  • Linux 32 bit 
• Windows (Windows 7 or newer):
  • Windows 64 bit 
  • Windows 32 bit 

Customizing License Server Settings

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)

#!/bin/sh
echo "Starting the Sigasi floating license server"
LOCATION=/home/flex/flexnet-sigasi
$LOCATION/lmgrd -c $LOCATION/sigasi.lic -l $LOCATION/debug.log

Starting the FlexNet and Sigasi Daemon on Windows

1. Download the Sigasi daemon (see above)
2. Create a folder to hold the license manager software, in this example we will use D:\Sigasi\license.
3. Unpack the zip file into the license folder (D:\Sigasi\license)
4. Run the license configuration tool lmtools.exe as administrator.
5. Save the license file supplied for SVH to the license folder
6. 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:

   

7. 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.
8. Ensure both the following boxes are checked:
   • Use Services
   • Start Server at Power Up
9. Now click the Save Service button, and click yes on the confirmation dialog.
10. 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?
  • A License Token is a 24 character string. You can use your license token to Activate Your License Key .
  • A License Key (or license file) looks like this:

INCREMENT com.sigasi.hdt sigasi 2.0 18-nov-2012 uncounted \
        VENDOR_STRING="company:www.example.com;mac:10f2dd92c5ac;name:John \
        Doe;type:trial" HOSTID=ANY ISSUER=Sigasi ISSUED=21-Oct-2012 \
        START=21-Oct-2012 SIGN="0CCC 87EA 9BB6 256E 7D81 E49D B2A6 \
        E53D 1CA5 41D4 63DF 8671 5695 EF82 0E30 1028 732D DED3 0999 \
        FD11 8B97 42B0 7CF2 F51F 20A0 DA6E 7F54 9D64 FF29 49AB"

Floating Licenses

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=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 Key preference page: Preferences > Sigasi > License Key. At the bottom of this preference 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 preference page via : Window > Preferences and Sigasi > License Key

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?

Invalid License Key (inconsistent authentication code)

• 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 still exists 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.

Capitalization of Identifiers

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:

163/severity/${path}={error|warning|info|ignore}

Case Alternative Contains Duplicate Choices

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:

14/severity/${path}={error|warning|info|ignore}

Check for Component/Entity Mismatch

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:

187/severity/${path}={error|warning|info|ignore}

Check Header Comment

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.

The check can be enabled for the entire workspace via Preferences > Sigasi > VHDL|Verilog/SystemVerilog > Header Comments. The patterns can be configured on the same page. 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}

Clock Signal Not Used as Clock

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:

249/severity/${path}={error|warning|info|ignore}

Comparison of Vectors with Different Sizes

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:

232/severity/${path}={error|warning|info|ignore}

Dead Code Linting Rule

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;
  else
      v := 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
85/severity/${path}={error|warning|info|ignore} # Unreachable statements
71/severity/${path}={error|warning|info|ignore} # Dead states

Deep Nesting of Conditional and Loop Statements

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 preference 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.

use ieee.std_logic_misc.all

Read more on IEEE packages in Deprecated IEEE Libraries.

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 deprecated IEEE packages
8/severity/${path}={error|warning|info|ignore}
# For Non-standard packages
37/severity/${path}={error|warning|info|ignore}

Deprecated UVM API

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:

152/severity/${path}={error|warning|info|ignore}
152/params/up_to_version/${path}={current|uvm_1_2|uvm_2017|uvm_2020}

End Name Does Not Match Declaration Name

In Verilog, if an end name is provided for a code block, it must match the declaration name.

class SomeClass;
endclass : SomeOtherClass;

class SomeClass;
endclass : SomeClass;

SVH offers a quick fix for this issue. In the above example, it would replace ‘SomeOtherClass’ with ‘SomeClass’.

Filename Contains Primary Unit 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 preference 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:

189/severity/${path}={error|warning|info|ignore}

Implicit Vector to Boolean Conversion

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:

144/severity/${path}={error|warning|info|ignore}

Incomplete Port Maps and Generic Maps

Sigasi Visual HDL (SVH) warns about port maps and generic maps that are incomplete:
Port map uses default values. Missing optional actuals: yourport

Input ports and generics 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 and generics 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:

94/severity/${path}={error|warning|info|ignore}

Incomplete Reset Branch

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:

238/severity/${path}={error|warning|info|ignore}

Inconsistent Clock Edge Usage

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 setting or workspace preference.

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:

254/severity/${path}={error|warning|info|ignore}
254/params/expected_edge/${path}={consistent|rising|falling}

Inconsistent Reset Style

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:

252/severity/${path}={error|warning|info|ignore}
252/params/reset_style/${path}={asynchronous|synchronous}

Incorrect Constructor for UVM Object or Component

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:

154/severity/${path}={error|warning|info|ignore}

Incorrect Override of UVM Object

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:

151/severity/${path}={error|warning|info|ignore}

Incorrect Utility Macro

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:

146/severity/${path}={error|warning|info|ignore}

Incorrect UVM Object Instantiation

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:

148/severity/${path}={error|warning|info|ignore}

Incorrect Vector Range Direction

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:

241/severity/${path}={error|warning|info|ignore}
241/params/direction/${path}={downto|to}

Language Feature Restrictions

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 243). 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 abc denied

library abc;    -- Library 'abc' is prohibited

• Library ieee allowed

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:

244/severity/${path}={error|warning|info|ignore}
244/params/check_mode/${path}={deny|allow}
244/params/attributes/${path}=[attribute...]
244/params/user_attributes/${path}={true|false}

245/severity/${path}={error|warning|info|ignore}
245/params/keywords_and_operators/${path}=[keyword...]

246/severity/${path}={error|warning|info|ignore}
246/params/check_mode/${path}={deny|allow}
246/params/packages/${path}=[package...]

247/severity/${path}={error|warning|info|ignore}
247/params/pragmas/${path}=[pragma...]

248/severity/${path}={error|warning|info|ignore}
248/params/check_mode/${path}={deny|allow}
248/params/libraries/${path}=[library...]

Linting Rules for Arrays

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:

210/severity/${path}={error|warning|info|ignore}
211/severity/${path}={error|warning|info|ignore}

Linting Rules for Deferred Constants

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;

Linting Rules for Design Unit Locations

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}

Linting Rules for Instances

Sigasi Visual HDL flags an error if the entity keyword is omitted in the instantiation of an entity (rule 198).

Note that when instantiating a component, the keyword entity and the library name are not used.

architecture RTL of bar is
    component foo
        port(
            clk : in std_logic;
            rst : in std_logic
        );
    end component foo;
begin
    foo_inst_bad : work.foo              -- instance of entity foo requires keyword "entity"
        port map(
            clk => clk,
            rst => rst
        );

    foo_inst_correct : entity work.foo   -- correct instance of entity foo
        port map(
            clk => clk,
            rst => rst
        );

    foo_inst_comp : foo                  -- instance of **component** foo
        port map(
            clk => clk,
            rst => rst
        );
end architecture RTL;

Linting Rules for Loops

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:

20/severity/${path}={error|warning|info|ignore}
190/severity/${path}={error|warning|info|ignore}

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:

155/severity/${path}={error|warning|info|ignore}

Missing Label

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:

251/severity/${path}={error|warning|info|ignore}
251/params/entity_end_name/${path}={true|false}
251/params/architecture_end_name/${path}={true|false}
251/params/configuration_end_name/${path}={true|false}
251/params/package_end_name/${path}={true|false}
251/params/package_body_end_name/${path}={true|false}
251/params/context_end_name/${path}={true|false}
251/params/component_end_name/${path}={true|false}
251/params/function_end_name/${path}={true|false}
251/params/procedure_end_name/${path}={true|false}
251/params/record_type_end_name/${path}={true|false}
251/params/physical_type_end_name/${path}={true|false}
251/params/protected_type_end_name/${path}={true|false}
251/params/protected_type_body_end_name/${path}={true|false}
251/params/for_generate_end_label/${path}={true|false}
251/params/if_generate_end_label/${path}={true|false}
251/params/case_generate_end_label/${path}={true|false}
251/params/if_generate_alternative_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/case_generate_alternative_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/process_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/concurrent_block_end_label/${path}={true|false}
251/params/concurrent_procedure_call_label/${path}={true|false}
251/params/concurrent_assertion_label/${path}={true|false}
251/params/concurrent_signal_assignment_label/${path}={true|false}
251/params/if_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/case_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/loop_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/sequential_block_labels/${path}={ignore|start_label|start_and_end_labels}
251/params/sequential_procedure_call_label/${path}={true|false}
251/params/sequential_assertion_label/${path}={true|false}
251/params/sequential_signal_assignment_label/${path}={true|false}
251/params/variable_assignment_label/${path}={true|false}
251/params/wait_label/${path}={true|false}
251/params/report_label/${path}={true|false}
251/params/next_label/${path}={true|false}
251/params/exit_label/${path}={true|false}
251/params/return_label/${path}={true|false}
251/params/null_label/${path}={true|false}

Multiple Objects in One Declaration

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:

253/severity/${path}={error|warning|info|ignore}

Naming Conventions

On the Naming Conventions preference page (Window > Preferences > Sigasi > VHDL|Verilog/SystemVerilog > Naming Conventions) you can 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 .

Note: The Naming Conventions preference page is not yet available in the project preferences. If you require project-based configuration of the naming conventions rather than workspace preferences, please refer to the manual Rule configuration detailed below.

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/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/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/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}

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.

92/severity//<project>=ERROR
92/params/port_name=p_.*
92/params/input_port_name=\	.*[0-9].*
92/params/inout_port_name=b_.*
eclipse.preferences.version=1
isEnabled=true

Null or Empty Range

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}

Order of Associations

Sigasi Visual HDL gives a warning when the order of generics or ports in a map differs from the original generics or ports 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:

177/severity/${path}={error|warning|info|ignore}

Positional Association in Instantiations

Most VHDL designers prefer named associations in port and generic maps 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 via Preferences > Sigasi > VHDL > Errors/Warnings 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:

164/severity/${path}={error|warning|info|ignore}

Prohibited Macro

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:

// Deprecated
`define size 42

...

module my_module(input logic clk, rst);
   logic [`size : 0] data;
   ...
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:

129/severity/${path}={error|warning|info|ignore}
/params/prohibited_macros/${path}=[macro...]

Redundant "others"

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:

13/severity/${path}={error|warning|info|ignore}

Sensitivity List

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

Space Before the Physical Unit

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).

Superfluous Library Clause

The VHDL language reference manual states that:

Every design unit except package STANDARD is assumed to contain the following implicit context items as part of its context clause:

    library STD, WORK;
    use STD.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:

49/severity/${path}={error|warning|info|ignore}

Testing Equality of Booleans to true or false

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:

185/severity/${path}={error|warning|info|ignore}
186/severity/${path}={error|warning|info|ignore}

Tool Compatibility Rules

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:

147/severity/${path}={error|warning|info|ignore}

Types in Expressions

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;

Unconstrained Signal or Variable of Integer Type

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:

236/severity/${path}={error|warning|info|ignore}

Unexpected Clock Edge Specification

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:

250/severity/${path}={error|warning|info|ignore}
250/params/style/${path}={edge_function|stable_attribute|event_attribute}

Unexpected FSM State Type

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

237/severity/${path}={error|warning|info|ignore}
237/params/fsm_state_type/${path}={enumeration|bit_vector|std_logic_vector}

Unexpected Keyword Capitalization

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:

240/severity/${path}={error|warning|info|ignore}
240/params/style/${path}={consistent_in_file|uppercase|lowercase}
240/params/overrides/${path}=[keyword...]

Unexpected Output System Task

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.

class my_driver extends uvm_driver#(my_item);
	`uvm_component_utils(my_driver)

	task read(my_item req);
		// ...
		// Unexpected invocation of '$display', use UVM reporting macros instead
		$display("read: %s", req.convert2string());
	endtask

	task write(my_item req);
		// ...
		`uvm_info("write", req.convert2string(), UVM_HIGH)
	endtask
endclass

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:

150/severity/${path}={error|warning|info|ignore}
150/params/report_file_output_system_tasks/${path}={true|false}

Unregistered UVM Object

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:

145/severity/${path}={error|warning|info|ignore}
145/params/allow_unregistered_virtual_uvm_objects/${path}={true|false}

UVM Object Name Does Not Match Variable Name

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:

149/severity/${path}={error|warning|info|ignore}

UVM Phase Method Does Not Call Superclass Method

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:

153/severity/${path}={error|warning|info|ignore}

Vector as Edge Event Expression

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:

143/severity/${path}={error|warning|info|ignore}

Vector Width in Assignments and Port Maps

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:

144/severity/${path}={error|warning|info|ignore}

Verilog Ambiguous Reference

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.

module inner;
    ...
endmodule

module inner(input x, y);
    ...
endmodule

module bad_code;
    inner inner_inst();
endmodule

Verilog Assignment Patterns

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

Verilog Case Statements

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

Note that SVH also warns for case statements without a default clause

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

Verilog Checks on Initialization

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) begin
            sig = 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:

35/severity/${path}={error|warning|info|ignore}

Verilog Class Item Visibility

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

Verilog Coding Style

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).

File header comment does not match required pattern

Many coding standards require the presence of a header comment in every file, matching a certain format. SVH can check whether the file header comment matches a pattern (rule 22). By default, the pattern is empty which disables this check. The pattern can be configured through Window > Preferences > Sigasi > (System)Verilog > Header Comments > File header and uses the regex syntax . More information can be found on the Check Header Comment configuration page.

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
22/severity/${path}={error|warning|info|ignore} # File header comment does not match required pattern
44/severity/${path}={error|warning|info|ignore} # Report encrypted regions
52/severity/${path}={error|warning|info|ignore} # Multiple statements per line
58/severity/${path}={error|warning|info|ignore} # Regular expressions compatibility

Verilog Duplicate Conditions

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:

98/severity/${path}={error|warning|info|ignore}

Verilog Duplicate Continuous Assignments

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

module sumff(input clk, rst_n, logic[31:0] d1, d2, output logic[31:0] q);
    wire logic[31:0] sum;

    assign sum = d1 + d2;

    always @(posedge clk or negedge rst_n)
    if (~rst_n)
        q <= 32'b0;
    else
        q <= sum;
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:

101/severity/${path}={error|warning|info|ignore}

Verilog Duplicate Declaration

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

Verilog Duplicate Port

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:

140/severity/${path}={error|warning|info|ignore}

Verilog Empty Assignment Pattern

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

Verilog Empty Concatenation

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

Verilog Empty Parameters

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).

module parameterized#(
    parameter p = 10,
    ,
    parameter q = 20
);
    ...
endmodule

module inner#(
    parameter p = 10,
    parameter q = 20,
    parameter r = 30
)
    ...
endmodule


module outer;
    inner#( 
        25,
        ,
        50
    ) inner_inst();
endmodule

Verilog Empty Port

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:

142/severity/${path}={error|warning|info|ignore}

Verilog Empty Port in ANSI Port List

When using the ANSI style, it is not legal to declare empty ports in the port list. Such empty ports will be flagged as errors by Sigasi (rule 141).

module empty_ansi_port(
    input a, 
    ,
    output b
);
endmodule

Verilog Functions

Non-blocking assignments are not allowed in functions

A non-blocking assignment (<=) is not allowed in a (System)Verilog function. While syntactically correct, it will generally not lead to the desired behavior, and will likely cause synthesis-simulation mismatch. Sigasi Visual HDL (SVH) flags an error if a blocking assignment is used in a function (rule 41).

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

Function prototype has implicit return type

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:

41/severity/${path}={error|warning|info|ignore} # Non-blocking assignment in function
10/severity/${path}={error|warning|info|ignore} # Function prototype with implicit return type

Verilog Hiding Non-virtual Methods

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:

132/severity/${path}={error|warning|info|ignore}

Verilog Identifiers and Data Types

VHDL keywords as module name

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).

module entity;
endmodule

module my_module;
endmodule

Underscores in identifier names

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.

module bad__code(input clk_);
endmodule

module goodcode(input clk);
endmodule

Non-packed member in packed struct or union

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

Verilog Implicit Net

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.

module inner(input wire logic x, y);
    ...
endmodule


module error_prone_code;
    wire logic declared_net = 0;

    inner inner_inst(declared_net, implicit_net);
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:

97/severity/${path}={error|warning|info|ignore}

Verilog Incorrect Port Declaration

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).

module missing_direction_ansi(a, input b, output c);
endmodule

When using the non-ANSI style, all ports in the port list must be declared in the body of the design unit and vice versa (rule 136 and 137).

module missing_port_non_ansi_136(a, b, c);
    input b;
    output c;
endmodule

module missing_port_non_ansi_137(b, c);
    input a, b;
    output c;
endmodule

It is not legal to mix ANSI style port declarations and non-ANSI style port declarations within a single port list (rule 138).

module ansi_style_mixing(input a, b, c);
    output c;
endmodule

Verilog Inputs

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:

14/severity/${path}={error|warning|info|ignore}

Verilog Keywords in VHDL

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:

192/severity/${path}={error|warning|info|ignore}

Verilog Out-of-bound Method Declarations

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:

90/severity/${path}={error|warning|info|ignore}
91/severity/${path}={error|warning|info|ignore}

Verilog Overridden Method Signatures

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:

67/severity/${path}={error|warning|info|ignore}

Verilog Parameters

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.

module badcode;
	parameter P;
	initial
	    $display(P);
endmodule

module goodcode;
	parameter P = 0;
	initial
	    $display(P);
endmodule

Parameters width mismatch

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;

Empty parameter not allowed

The Verilog standard does not allow empty parameters (rule 53).

module dut # (parameter WIDTH = 42, ) (input clk); endmodule; // dangling comma is not allowed

module dut # (parameter WIDTH = 42 ) (input clk); endmodule;

Empty parameter overrides not allowed

The Verilog standard does not allow empty parameter overrides (rule 54).

module test;
    sub#(8, 16, ) inst(); // dangling comma is not allowed
endmodule

module test;
    sub#(8, 16 ) inst();
endmodule

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
53/severity/${path}={error|warning|info|ignore} # empty parameter
54/severity/${path}={error|warning|info|ignore} # empty parameter override
69/severity/${path}={error|warning|info|ignore} # local parameter not initialized
70/severity/${path}={error|warning|info|ignore} # local parameter overridden

Verilog Port and Parameter Associations

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.

module sub(i1, i2, o1);
    parameter WIDTH = 8;
    input[WIDTH-1:0] i1, i2;
    output[WIDTH-1:0] o1;
endmodule

module badtop;
    logic aa, bb, cc;
    // parameter `HEIGHT` and ports `a`, `b`, `c` do not exists in module `sub`
    sub#(.HEIGHT(4)) sub_inst(
        .a(aa),
        .b(bb),
        .c(cc)
    );
endmodule

module goodtop;
    logic aa, bb, cc;
    sub#(.WIDTH(4)) sub_inst(
        .i1(aa),
        .i2(bb),
        .o1(cc)
    );
endmodule

Duplicate port and parameter connections

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 Processes

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:

27/severity/${path}={error|warning|info|ignore}

Verilog reg and logic Datatype

In SystemVerilog, the reg datatype is deprecated. It is recommended to use the logic datatype instead.

Sigasi Visual HDL warns when the reg datatype is used in SystemVerilog.

A Quick Fix is available to convert reg into logic.

module my_module;
    reg   deprecated;
    logic good;
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:

3/severity/${path}={error|warning|info|ignore}

Verilog Type Checking

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.

Syntax Confusion and Implicit Casting

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

Verilog Unused Declaration

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.

module code;
    logic var1 = 0;
    logic var2 = 1;

    initial $display(var2);
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:

130/severity/${path}={error|warning|info|ignore}

Verilog Unused Macros

Sigasi Visual HDL warns about unused macros. Unused macros are often a side effect of code modifications. They can be safely removed.

`define UNUSED_MACRO(a) $display(a)
module sumff(input clk, rst_n, logic[31:0] d1, d2, output logic[31:0] q);
    wire logic[31:0] sum;

    assign sum = d1 + d2;

    always @(posedge clk or negedge rst_n)
    if (~rst_n)
        q <= 32'b0;
    else
        q <= sum;
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:

128/severity/${path}={error|warning|info|ignore}

Verilog Upward Reference

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:

99/severity/${path}={error|warning|info|ignore}

VHDL Coding Style Rules

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 or workspace preferences.

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 .

...
s_output <= func(s_input, 4032);
...

...
constant Size : integer := 4032;
...
s_output <= func(s_input, Size);
...

Sequence of operators without parentheses

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}

VHDL Language Version

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.

Extension Setup

This page explains how to install and configure Sigasi Visual HDL (SVH).

Requirements

VS Code Version

The extension requires VS Code or VS Codium version 1.77.0 or higher.

Java Runtime (Optional)

The path to use the Java Runtime (JRE) can optionally be configured in the settings. If empty, the extension will extract the included JRE in the user’s home folder.

• Linux: ~/.config/Code/User/globalStorage/sigasi.sigasi-vscode
• Windows: %AppData%\Code\User\globalStorage\sigasi.sigasi-vscode

If you wish to provide the JRE:

• The extension requires a Java Runtime
• The Java runtime must be 64-bit. Make sure to use JRE 11 or JRE 17
• You can check your Java version with java -version
• Java can be downloaded from several sources, a.o. Adoptium 
• Make sure the java executable is available in the PATH environment variable

Installation

You can install the extension from the VS Code marketplace .

To install the extension from VS Code, open the Extensions pane using Ctrl+Shift+X. In the Search field on top, type Sigasi. Click the Sigasi extension and click Install.

You can also download the self-contained VSIX file directly. Go to the SVH extension marketplace webpage , and on the right panel under Resources, click on Download Extension. This will give you the option to download the Windows x64 or the Linux x64 VSIX.

If you’re working on a remote host for your HDL development, the extension only needs to be installed on the remote.

Licensing

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.
• First, configure the Path To License. It can be a local node-locked license file or a floating license server, e.g., 27000@myserver.example.com.
• Optionally, configure the JRE location in Sigasi > Java: Path. Make sure to add the java executable name to the configured value.

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 manual page.

Talkback is disabled by default. To enable Talkback in the VS Code extension, open the settings and enable the Sigasi: Enable Talkback option.

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 setting Sigasi > Server > Caching: Enable On-Disk Caching.

Setting up a Project

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.

For project configuration, open the Sigasi Projects View.

Creating and Importing Projects

Importing a Project from the File System

First, open the folder you want to import through (File > Open Folder…). Then, open the Command Palette (Ctrl+Shift+P) and run the command Sigasi: Add Sigasi Support.

Creating a New Project From Scratch

To create a new project, open the Command Pallet (View > Command Pallete…), execute the command Sigasi: Create New Sigasi Project, choose the project location, then give your project a name.

Next, you need to have the project’s root folder to create a .project file in your folder containing the project configurations.

Once the .project file is detected, SVH will fully start, indicated by a Projects View below the default VSC file explorer.
From then on, you should use the Projects View instead of the VSC file explorer.

Every Sigasi project has mixed-language support.

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: Create 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.

See also: Tutorial Project in Sigasi Visual HDL

Demo

You can also open a larger demo project using the command Sigasi: Create 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 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 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. Bes sure to select the version you want.

Sigasi Support

To add or remove Sigasi support, you can right-click on a project from the Sigasi Projects View, click Configure, and Add/Remove Sigasi Support. This will enable or disable Sigasi support.

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.

Libraries

Introduction

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 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 make changes to 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.

How To Add Files To Common Libraries

In any newly created Sigasi project, the Common Libraries folder contains the VHDL files of the IEEE and STD libraries.

To add files, right-click the Common Libraries folder and select the New Linked Folder to create a Linked Folder pointing to the actual folder location that contains the files you wish to add to the Common Libraries.

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.