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.