Sigasi Studio 5.3 introduces many new DO-254 compatible VHDL design linting rules, more ways to check coding guidelines and naming conventions, means to differentiate between RTL and non-RTL code, as well as new Verilog vector linting rules and enhanced support for SystemVerilog parameterized classes.

As per usual, Veresta  and our VS Code extension  benefit from all of the changes not explicitly marked as Eclipse. Additionally, Veresta 5.3 brings project documentation generation to your CI/CD environment.

TL;DR

Sigasi 5.3 introduces many new VHDL style rules to implement your project-specific coding guidelines and naming conventions. You can now enforce coding conventions such as line length, prohibited language features, consistent vector directions, keyword capitalization, and many more. Furthermore, we are adding new naming conventions for constructs such as input/output/inout ports, enumeration literals, functions, and procedures. These can be configured with new visually pleasing preference pages. These allow you to configure different severities for RTL code and non-RTL code. Finally, we have split off header comment pattern matching into separate preferences, e.g., for entities, packages, and function header comments.

Aside from the style rules mentioned above, five VHDL design linting rules make their entrance:

• Clock signal not used as clock
• Incomplete reset branch
• Comparison of vectors with different sizes
• Missing full constant declaration
• Duplicate choices in case statements

Many of these new design and style linting rules apply to the DO-254 standard. Sigasi 5.3 is an essential tool for working towards a fully compliant DO-254 design process.

Beyond VHDL, there are two new Verilog linting rules regarding vector usage:

• Implicit vector to boolean conversion
• Vector as edge event expression

SystemVerilog designers will be pleased to learn that Sigasi’s support for parameterized classes was greatly improved in this release, too. Navigating complex class hierarchies is a breeze and meaningful feedback is provided at type-time.

Autocomplete for all languages has received a speedup of up to 50% for large projects and a more complete list of suggestions is offered.

As announced in the previous releases, we have removed the support for the Graphics Configuration Language.

Finally, this release is once again packed with many bug fixes and small improvements.

VHDL Linting Rules

Sigasi 5.3 offers more than 250 VHDL linting rules.

New Preference Pages

All of these new preference pages are available in Eclipse.

Linting Configuration

Before we jump into all the VHDL linting rules, let us first show you how to configure them using the redesigned linting rule preference page (Right-click project > Properties > Verilog/VHDL Errors/Warnings).

• New foldable families allow for easy grouping of linting rules and editing their severities
• Improved descriptions of all linting rules
• Icons now visually highlight the currently configured severity
• Many linting rules have parameters that can be tweaked in this view
• Linting rule severities can be set separately for RTL and non-RTL code

VHDL Identification

The RTL code detection mechanism can be configured per project by going to Right-click project > Properties > VHDL Identification.

• Via a naming convention for an RTL architecture
• By detecting verification code

This allows you to set different linting rule severities for RTL and non-RTL code.

Naming Conventions

We have extended the Naming Conventions preference page at Window > Preferences > Sigasi > VHDL > Naming Conventions. Naming conventions can now also be configured using an invalid pattern and many additional naming conventions are available.

Comment Headers

The Comment Header configuration moved from the naming conventions to a new preference page at Window > Preferences > Sigasi > VHDL > Header Comments. Aside from files, headers describing constructs such as entities, packages, and functions can now also be validated.

Design Linting Rules

These rules check for potential design flaws and coding errors. They are enabled by default, but you can usually edit their severity and parameters through your project preferences: Right-click project > Properties > VHDL Errors/Warnings.

Clock Signal Not Used as Clock

Clock signals should only be used to clock registers. Other usages can cause problems during logic synthesis or static timing analysis.

Learn more

Incomplete Reset Branch

A reset branch should reset all registers defined in the clocked branch of a process. Otherwise, unexpected enable or clock gating logic can be synthesized for non-reset registers.

Learn more

Comparison of Vectors with Different Size

When comparing vectors with default comparators, they should be exactly the same size. The use of a generic to define this size can potentially cause issues down the road, e.g., when later design reconfiguration makes the compared vectors differently sized.

Learn more

Missing Full Constant Declaration

The VHDL language specification mandates that an uninitialized, deferred constant declaration in a package declaration must have a corresponding fully initialized constant declaration in the package body.

Learn more

Case Alternative Contains Duplicate Choices

In VHDL every choice in a case statement must be unique. This pre-existing rule was extended to check all values, not only enumerations.

Learn more

Style Rules

Style rules check a certain coding style. Since they are a question of taste, they are set to ignore by default. You can enable them in your project preferences: Right-click project > Properties > VHDL Errors/Warnings.

Sequence of Operators without Parentheses

While it is not necessary to add parentheses, they can clarify evaluation order in expressions with operators of different associativity.

You might wonder, is it 2 ** (8 - 1) or (2 ** 8) - 1? (Narrator: It is the latter)

Learn more

Unconstrained Signal or Variable of Integer Type

Integers with a range constraint allow the synthesis tool to optimize the number of bits used by the signal or variable. This rule requires all signals and variables of integer types to be range-constrained to benefit from that optimization.

Learn more

Constant Width Vector Assigned to Signal

For portability and maintainability reasons, you may want to prohibit constant width vector assignments to a signal. Using constant values or aggregates ((others -> '0')) prevent potential maintainability hurdles.

Learn more

Inconsistent Reset Style

It is good practice to use either only async reset blocks or only sync reset blocks. You can configure whether you prefer the synchronous or asynchronous reset style.

Learn more

Incorrect Vector Range Direction

For clarity and maintainability, it is best to use either ascending or descending ranges for all the vectors in your design. We recommend a descending range (downto) as this causes the leftmost bit to be the most significant and the rightmost to be least significant; this is what the VHDL standard library’s arithmetic operators assume as well.

Learn more

Unexpected Keyword Capitalization

VHDL is case-insensitive in almost all aspects, including keywords. Using a consistent casing for keywords improves the readability of the design. We recommend synchronizing this setting with the VHDL Lowercase/Uppercase keywords formatting option.

Learn more

File Contains Multiple Primary Units

For clarity, you may want to have each primary unit described in its own file. A primary unit is one of the following

• entity
• configuration
• package
• package instantiation
• context

Learn more

Secondary Unit in Unexpected File: Separate File from Primary Unit

For clarity, you may want to have secondary units described in their own file. A secondary unit is an architecture or a package body. The rule can be configured differently for each of them.

Learn more

Secondary Unit in Unexpected File: Same File as Primary Unit

You may want to have secondary units described in the same file as their corresponding primary unit to emphasize their close connection. A secondary unit is an architecture or a package body. The rule can be configured differently for each of them.

Learn more

Multiple Objects in One Declaration

Multiple objects in one declaration can decrease readability making it harder to maintain code.

Learn more

Unexpected FSM State Type

We recommend declaring the FSM states as enumerated data types. Other state types can be configured, for example, an array of bits. Enumerated state types make VHDL code generally more readable and facilitate flexibility in the synthesis implementation since the encoding style can be selected without modifying the code.

Learn more

Line is Too Long

Many coding guidelines mandate a maximum line length for readability.

Learn more

Magic Number, Bitstring, or String in Statement

Magic numbers can impact maintainability. While their purpose was probably clear during implementation, it might no longer be later in the design cycle. Hardcoding the magic numbers everywhere instead of using constants also requires increased effort if they ever need changing.

Learn more

Inconsistent Clock Edge Usage

Depending on the technology, you may want to use either the rising or falling edge of the clock. Using both clock edges requires greater attention to maintain correctness.

Learn more

Unexpected Clock Edge Specification Style

A clock edge can be specified by using edge functions (rising_edge and falling_edge) or event attributes (not clk'STABLE or clk'EVENT) and checking the clock signal level. We recommend using edge functions; however, whether you use the recommended style or not, you may find it beneficial to use a consistent style for readability. The preferred style can be configured.

Learn more

Deep Nesting of Conditional and Loop Statements

Many coding guidelines discourage deeply nested conditional and loop statements, as they reduce code readability. The limit can be configured.

Learn more

Prohibited Attribute

Consider this rule if certain attributes are deprecated, discouraged, or not applicable to your design. Note that you can add prohibitions specifically for RTL or non-RTL code.

Learn more

Prohibited Keyword or Operator

Consider this rule if certain keywords or operators are deprecated, discouraged, or not applicable to your design, for example, to prevent the use of a certain construct. Note that you can add prohibitions specifically for RTL or non-RTL code.

Learn more

Prohibited Library

Consider this rule if certain libraries are deprecated, discouraged, or not applicable to your design, for example, an old version of an IP block. Note that you can add prohibitions specifically for RTL or non-RTL code.

Learn more

Prohibited Package

Consider this rule if certain packages are deprecated, discouraged, or not applicable to your design. Note that you can add prohibitions specifically for RTL or non-RTL code.

Learn more

Prohibited Pragma

Consider this rule if certain pragmas are deprecated, discouraged, or not applicable to your design, for example, because you want to ensure compatibility with your synthesis tool. Note that you can add prohibitions specifically for RTL or non-RTL code.

Learn more

Verilog Linting Rules

Implicit Vector to Boolean Conversion

A vector in an if statement is implicitly converted to a boolean by comparing it to 0. This is a valid code style, but it could also have happened accidentally. In this case, rst was accidentally assigned the type logic [7:0] instead of logic.

Learn more

Vector as Edge Event Expression

Using a vector as an edge event expression is valid, but you have to be aware that only changes to the least significant bit will be considered as an edge event. In this case, clk was accidentally declared with the type logic [7:0] instead of logic.

Learn more

Further New and Noteworthy

• Eclipse Added feedback to unsuccessful project imports
• Eclipse Improved highlighting for multiline strings and numbers
• Eclipse The Libraries View now shows whether code is RTL, behavioral, or a testbench

  

• Eclipse VHDL Allow configuring separate severities for RTL and non-RTL
• Verilog The Multiple Statements per Line linting rule’s severity is now configurable

Quality of Life

• Eclipse Removed viewport scrolling on format, greatly reducing interruptions caused by formatting
• Eclipse Improved consistency of menu items
• Eclipse Added keybindings to the Keys preference page allowing them to be rebound. This regards keybindings like Quick Outline (Ctrl+O) and Class Hierarchy (F4).
• Eclipse Verilog Enum members are grouped in the Class Hierarchy member pane
• Verilog Improved autocomplete performance by up to 50% for large projects
• Verilog Improved formatting when using includes and macro invocations
• Verilog Improved formatting inside of included files
• Verilog Improved Smart Indent when using interfaces as module ports
• Verilog The File Contains Multiple Design Units linting rule is only reported on the second design unit, greatly reducing noise
• VHDL Added missing squiggly line for the Process with Missing Sensitivity List and Wait Statements linting rule

Updates and Deprecations

• As announced in the previous releases, we have removed the support for the Graphics Configuration Language.

Bug Fixes

• Fixed formatting when zero width no-break spaces are used
• Eclipse Fixed prefix highlighting in autocomplete suggestions
• Eclipse Fixed editor <-> Hierarchy View cursor synchronization when duplicate entries are present
• Eclipse Fixed missing autocomplete when specific syntax errors are present
• Eclipse Fixed missing date for User-defined Autocomplete Templates using custom date formats
• Eclipse Verilog Fixed missing autocomplete when typing $ with the autocomplete dialog open
• Eclipse Verilog Fixed missing Block Diagram elements for complex assign statements
• Eclipse Verilog Fixed editor <-> Preprocessor View cursor synchronization when double or triple-click selecting
• Verilog Fixed the Add Declaration Quick Fix when used in if statements
• Verilog Fixed missing autocompletes following a function invocation
• Verilog Fixed missing autocompletes on large projects
• Verilog Fixed incorrect hover when using include files
• Verilog Allow interface classes in SystemVerilog packages
• Verilog Predefined SystemVerilog macros (e.g., `SV_COV_NOCOV) are recognized in unmapped files
• VHDL Fixed false positive dead code error
• VHDL Fixed the label of entity and component autocomplete instantiations when the Formatting > Lowercase/Uppercase keywords preference is enabled
• VHDL Fixed missing autocomplete in empty package
• VHDL Fixed missing first character following a Type Conversion Autocomplete

Thank you for all the bug reports and for enabling Talkback. All your reports have helped us fix many issues that would otherwise have gone unnoticed.

Sigasi Studio 5.3.1 Point Release

On October 10, we released Sigasi Studio 5.3.1. This release contains the following changes and bug fixes:

• More resilient processing of .project files
• Parameters in the .prefs files are case-insensitive
• Eclipse Fixed Errors/Warnings page not opening when creating a builder

Sigasi Studio 5.3.2 Point Release

On October 23, we released Sigasi Studio 5.3.2. This release contains the following bug fix:

• Eclipse Fixed blank webviews on Windows

Sigasi Studio 5.3.3 Point Release

On November 28, we released Sigasi Studio 5.3.3. This release contains the following new feature:

• Eclipse Sigasi Studio on Windows starts without first showing a Microsoft Defender SmartScreen warning

System Requirements

• Sigasi Studio standalone is supported on:
  • Windows 10 or Windows 11 64-bit
  • RedHat Enterprise Linux RHEL 7.9 64-bit or newer, including RHEL 8 and 9
    • Sigasi Studio depends on libXss.so which can be obtained by installing libXScrnSaver
    • Sigasi Studio depends on webkit2gtk4.0 which can be installed through your package manager of choice
  • More information on supported Linux OSes can be found on the Eclipse website 
• Sigasi Studio as a plugin in your Eclipse installation:
  • Eclipse IDE 2021-03 up to and including Eclipse IDE 2023-03
  • Java JRE 11 or 17
• Sigasi Studio extension  for VS Code:
  • Windows 10 or Windows 11 64-bit
  • RedHat Enterprise Linux RHEL 8 or 9 64-bit
  • VS Code >= 1.77 and < 2.0
  • Java JRE 11 or 17 (shipped with the extension)
• Veresta 
  • Windows 10 or Windows 11 64-bit
  • RedHat Enterprise Linux RHEL 7.9 64-bit or newer, including RHEL 8 and 9
  • Java JRE 11 or 17 (shipped with Veresta)

We recommend having at least 4GB of memory and about 1GB of free disk space available for Sigasi Studio.