In addition to syntax validation, Sigasi Studio also checks your code for semantic problems (Linting, or Linter checks). Some of these problems can be automatically resolved with Quick Fixes. Both syntax checking and linting happen at type-time: new markers appear as you are typing your code.

Linting

VHDL code Lint is defined as code that is strictly correct according to the language definition, but still suspicious or problematic. Sigasi Studio has a built-in VHDL linter, which provides info about code lint in the design.

Marker Icons

• marks an info message.
• marks a warning that can be resolved automatically with a Quick Fix.
• marks a warning that cannot be resolved automatically.
• marks an error that can be resolved automatically with a Quick Fix.
• marks an error that cannot be resolved automatically.

Configuring the Severity Level

The Sigasi Studio VHDL linter has reasonable defaults for the severity level of reported lint problems. However, the severity level of certain classes of lint is configurable for additional flexibility. The configuration interface is available in Window > Preferences > VHDL > Errors/Warnings.

You can also configure the severity level per project.

Suppressing warnings

Specific warnings can be suppressed in your code by adding a @suppress comment (-- @suppress for VHDL, // @suppress for SystemVerilog), on the same line as the warning.

You can limit the suppression to a specific warning by putting a prefix of the warning message between quotes after @suppress. Sigasi also recommends adding a reason why the warning was suppressed by adding an extra comment after @suppress:

<line with warning> // @suppress "Warning message prefix" Reason why warning is suppressed

Since Sigasi Studio 4.2 the @suppress comment also suppresses Errors. Since Sigasi Studio 4.3 warnings have a quickfix to automatically add the @suppress comment with a matching warning message prefix.

No Linting for Common Libraries

Common Libraries are considered to be production ready libraries. Linting is skipped for all files in the Common Libraries folder.

Quick Fixes

Some of the VHDL lint problems can be automatically resolved with Quick Fixes. These problems have markers annotated with a lightbulb icon (like ). To trigger a Quick Fix, click the problem marker or press Ctrl-1 and select the Quick Fix.

List of (System)Verilog code rules

The table below lists the (System)Verilog code rules that can be checked automatically by Sigasi Studio. The availability of code rules depends on the license requirements.

• ST code rules are available for all licenses including Sigasi Studio Starter
• XPRT code rules require a Sigasi Studio XPRT license.

License	Quick Fix	Description	ID
ST		File encoding differences between including and included files
XPRT		Null loops	1
XPRT		Check Naming Conventions	2
XPRT		Disallow ‘reg’ datatype	3
XPRT		VHDL keyword as module name	7

List of VHDL code rules

The table below lists the VHDL code rules that can be checked automatically by Sigasi Studio. The availability of code rules depends on the license requirements.

• ST code rules are available for all licenses including Sigasi Studio Starter
• CR code rules require at least a Sigasi Studio Creator license.
• XL code rules are only available with a Sigasi Studio XL or Sigasi Studio XPRT license.

License	Quick Fix	Description	ID
ST		Declaration could not be found
ST		Duplicate declarations
ST		Signal/variable assignment operator
ST		Case statement does not cover all choices
ST		Missing enumeration literal in case statements
ST		Instantiation statement validation
ST		Library validation
ST		Subprograms in packages (e.g. function body in a package, rather than in the package body)
ST		Missing return statement in function bodies
ST		Correct attribute entity class in attribute specifications
ST		C-style equality and inequality operator (= and /= vs == and !=)
ST		VHDL 2008 features in VHDL 93 mode (Learn about choosing your VHDL version)
ST		Port/Generic lists cannot be terminated with a ‘;’
ST		Port/Generic maps cannot be terminated with a ‘,’
CR		Deprecated IEEE packages	8
CR		Non-standard packages	37
CR		A process must either have a sensitivity list or contain one or more wait statements	38
CR		There has to be a whitespace before physical units	47
CR		Superfluous library clause	49
CR		Library is not available Configure Altera, Xilinx, ModelSim and VUnit libraries	50
CR		Find unused declarations	55
CR		Bitstrings may only contain std_logic metavalues	57
CR		Duplicate, conflicting design unit names	64
CR		Find unused ports	67
CR		Find unused generics	68
CR		Find incomplete sensitivity lists	72
CR		Find superfluous signals in sensitivity lists	73
CR		Report encrypted files	84
CR		Find duplicate signals in sensitivity lists	85
CR		Incorrect use of keyword all	184
XL		Null range: The left argument is strictly larger than the right	1
XL		Case alternative contains redundant choices	12
XL		Case statement contains all choices explicitly. You can safely remove the redundant ‘others’	13
XL		Infinite loop. Loop is missing a wait	20
XL		Null range: The left argument is strictly smaller than the right	26
XL		Unbound component instantiations	48
XL		Find dead states in state machines	71
XL		Find dead code (unreachable statements)	79
XL		Detect signals and variables that are never written	88
XL		Detect signals and variables that are never read	89
XL		None or multiple matching entities for component	90
XL		Check naming conventions	92
XL		Incomplete port map or generic map	94
XL		Vector width in assignments and port maps	144
XL		All references must have the same capitalization as their declaration	163
XL		Check for positional associations in instantiations	164
XL		Invalid port associations (incompatible port modes in instantiations)	169
XL		Order of generic and port associations	177
XL		Incorrect component name in configuration	180
XL		Incorrect instantiation statement label in configuration	181
XL		Missing or incorrect binding indication	182
XL		Incorrect name in binding indication	183
XL		Redundant boolean equality check with true	185
XL		Boolean equality check with false	186
XL		Check for component/entity mismatch	187
XL		Header comment check	188
XL		Filename must contain primary unit name	189
XL		Empty loop statement	190

Detailed explanation of code rules

Dead Code lint

Dead code is code that is does have any effect in 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 nor the synthesis tool. However, it consumes mental energy of anybody reading the code. People will try to figure the puropose 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 to reuse code. In general, dead code is a form of technological debt that should be avoided.

Sigasi Studio flags some kinds of dead code:

• unused declarations (signals, constants, …)
• unused ports
• unreachable statements (see Dead code)

For unused declarations, there is also a Quick Fix to help you remove unused declarations fast.

Deprecated IEEE Packages, Non-Standard Packages

Some packages are widely spread, but were never standardized by IEEE. Different vendors have shipped different versions, with incompatible implementation. These packages should not be used and are flagged as Deprecated IEEE packages.

ieee.std_logic_arith
ieee.std_logic_signed
ieee.std_logic_unsigned

Instead, use the standard ieee.numeric_std package.

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 Studio flags this package as Non-standard package.

Read more in Deprecated IEEE Libraries.

Incomplete Port Maps and Generic Maps

Available since Sigasi 2.25

Sigasi Studio warns about port maps and generic maps that are not complete:
Port map is using default values. Missing optional actuals: yourport

Input ports and generics need to be 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. Sigasi Studio 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, Sigasi Studio can warn you about this.

Positional Association in Instantiations

Available since Sigasi 2.30

Most VHDL designers prefer named associations in port and generic maps in instantiations. This makes it a lot easier to spot wrong connections. By default Sigasi Studio warns when positional associations are used. You can change the severity of this check via Preferences > Sigasi > VHDL > Errors/Warnings in the Instantiation statement valiadation section.

Quick Fix for Third Party Libraries

If you are using vendor libraries from Altera or Xilinx (ISE or Vivado), you do not need to set up these libraries by hand. Sigasi Studio has a Quick Fix to do this for you.

The library statement that tries to import a missing library (like altera) will be have a yellow warning marker next to it. Click this marker and select Configure library altera. If the path to your Altera Quartus (or Xilinx ISE) installation is not yet set, Sigasi Studio will ask to set the path now. You can always change these paths in Window > Preferences > Sigasi > Toolchains. Note that for the Xilinx libraries we only map the packages with the component declarations. By default all entity and architecture declarations are not mapped (excluded). This significantly reduces the time for a clean build. If you use direct entity instantiations, you can easily map the entities you need.

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 Studio warns about this:

Case statement contains all choices explicitly. You can safely remove the redundant others.

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

Sensitivity List

VHDL requires a sensitivity list for each process (or wait statements in the project).

Since VHDL-2008, you can write process (all) to make sure you have all signals in the sensitivity list. In all earlier versions, incomplete sensitivity lists can cause unexpected behavior. That is: your simulation results may be different from your synthesis results. Most synthesis tools ignore your 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 earlier saves time and lets you catch the problem early.

Sigasi Studio can warn about problems with your sensitivity list:

• Incomplete sensitivity list (there is Quick Fix for this)
• Superfluous signals in sensitivity list
• Duplicate signals in sensitivity list

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 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. Sigasi Studio flags this as warning.

Dead Code (unreachable code)

If the Sigasi Studio analyzer can determine that a condition is always false, it will mark the if-statement because it contains dead code.

Null Range (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: 7 downto 0 is a range of eight. 7 to 0 is an null range. We have a lint check that warns about this, even if you use constants (or some simple arithmetic).

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 Studio accepts the ModelSim-style physical literals, but warns about this.

Capitalization of Identifiers

Although VHDL is not case sensitive, it is recommend to always use the same capitalization when referring to the same declaration. Since version 2.30, Sigasi Studio 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.

Since Sigasi 2.31 this can easily be fixed with a Quick Fix.

Since Sigasi Studio 3.6 all capitalization issues in a file can be fixed in one click.

Naming Conventions

On the Navigation conventions preference page (Window > Preferences > Sigasi > VHDL/(System)Verilog > Naming conventions) you can configure patterns to check correct naming of your VHDL and SystemVerilog identifiers. Patterns are configured with Java regex syntax.

Only names with a specified pattern are checked. Empty patterns are omitted.

Example: to enforce a style where all variables have a _v suffix, you would specify .*_v pattern in the Variable name field.

Vector width in assignments and port maps

Sigasi Studio checks the vector size in assignments (Since Sigasi 2.28) and port maps (Since Sigasi Studio 3.1). This check works at type-time and takes the (symbolic) value of generics into account.

Sigasi Studio will not take into account the value assigned to a generic in instantiations. The reasoning behind this is explained here.

Order of associations

Sigasi Studio gives a warning when the order of generics or ports in a map differs from the original generics or ports declaration order.

Check for component/entity mismatch

Sigasi Studio gives a warning if a component declaration is not equal to its matching entity. You can easily fix this by applying the quick fix.

Check header comment

Sigasi Studio can check that the header comment matches a specified pattern. A header comment is the comment that starts at the first character of your file (no leading whitespace).

The check can be enabled in Preferences > Sigasi > VHDL > Naming conventions. The pattern can be set on the same page.

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.

Check that filename contains primary unit name

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

Project specific Linting settings

Severity of Linting checks

The default way to configure the severity of the Sigasi Studio linting checks is to set their severity in the Errors/Warnings preference page. You can override these setting by creating a settings file for your projects.

In each project, you can override the coding rules settings. You can override rules for the entire project, for folders in the project, or for individual files.

Errors/Warnings property page

To configure the severity level, right click the project (or file or folder) in the Project Explorer and select Properties > VHDL Errors/Warnings or Properties > SystemVerilog Errors/Warnings.

Project settings are stored in this settings file:

    ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs

You can search for a specific rule, by using the search field at the top of the property page.

Manual configuration

To configure the severity of validations, add a line for each validation:

    ${validation id}/severity/${path}=${severity}

Where ${validation id} can be

• the number of the validation ID (e.g. 140)
• all to specify all validation ids in one rule

Validation ID numbers are listed in the List of VHDL code rules and can also be found in the Project Properties under VHDL Errors/Warnings.

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
• /path/to/file.vhd to set the severity of a specific file

Where ${severity} can be:

• ERROR
• WARNING
• INFO
• IGNORE

Whitespace must be escaped with a back slash (\). You can add comments with #.

Examples:

    72/severity/<project>=IGNORE
    72/severity//Folder\ name/Extra\ folder=INFO
    72/severity//test/top.vhd=WARNING
    all/severity/<project>=IGNORE

Naming Conventions per project

While Naming Conventions and the Header Comment check can be configured globally for a workspace, they can also be defined per project, per folder or per file. The project-specific Naming Conventions and Header Comment are stored in this settings file for VHDL related settings:

    ${project location}/.settings/com.sigasi.hdt.vhdl.linting.prefs

For (System)Verilog related settings, this settings file is used:

    ${project location}/.settings/com.sigasi.hdt.verilog.linting.prefs

The validation ID for Naming Conventions is 92. The validation ID for the Header Comment is 188.

Syntax for Naming conventions

All lines that configure Naming Conventions should start with 92 and are of this format:

    92/params/${identifier}/${path}=${convention}

Valid ${identifier} values are:

    architecture_name
    configuration_name
    constant_name
    entity_name
    generate_statement_name
    generic_name
    instantiation_statement_name
    label
    package_name
    port_name
    process_statement_name
    signal_name
    type_name
    variable_name

Naming Conventions can be restricted to a specific file or folder using ${path}. Possible values are:

• <project> (literally, with brackets!) to set Naming Conventions for the entire project
• the folder name to which the Naming Convention should apply
• the full path of the file to which the Naming Convention should apply

The pattern that defines the Naming Convention is set in ${convention}. Patterns are configured with Java regex syntax.

Naming Conventions for a project and setting the severity of the linting checks are configured in the same settings file.

Syntax for Header Comment

Lines that configure the Header Comment should start with 188 and are of this format:

    188/params/comment_header/${path}=${convention}

The meaning of ${path} and ${convention} is equal to the definitions for Naming Conventions.

Examples:

    92/severity/<project>=INFO
    92/params/constant_name/<project>=c_.*
    92/params/entity_name/my_folder=e_([A-Z_0-9])*
    188/severity/<project>=WARNING
    188/params/comment_header//<project>=-- Project specific header comment\r?\n-- Second line
    188/params/comment_header//my_folder=-- Folder specific header comment

Errors in the patterns will be reported in the log file: Help > Open Log.