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.
UVM Linting Rules
UVM linting rules require a Sigasi Visual HDL Professional Edition or a Sigasi Visual HDL Enterprise Edition license.
You need to explicitly enable UVM linting.
Functional Safety
Mapping of STARC rules to SVH rules and features
Documentation on configuring STARC rules in SVH
| STARC rule | Rule name | SVH rules / features |
|---|---|---|
| 1.1.1.1. | File names should be as follows: <module name>.v or <module name>.sv. | 17 |
| 1.1.1.2. | Only alphanumeric characters and the underscore _ should be used, and the first character should be a letter of the alphabet. | 2 |
| 1.1.1.3. | Reserved words in Verilog HDL (IEEE 1364) SystemVerilog (IEEE 1800) and VHDL (IEEE 1076.X) must not be used. | 7 (VHDL only) |
| 1.1.1.4. | Names beginning with VDD, VSS, VCC, GND or VREF must not be used (uppercase or lowercase). | 2 |
| 1.1.1.5. | Do not distinguish names by using upper or lower case English letters (Abc, abc). | 166 |
| 1.1.1.6. | Do not use an _ (underscore) at the end of the primary port name or module name, and do not use _ consecutively. | 2 |
| 1.1.1.9. | At the top level, module names and port names should consist of 16 or fewer characters and should not be distinguished by upper or lower case alphabet letters. | 2 |
| 1.1.2.1. | Module names and instance names should be between 2 and 32 characters in length. | 2 |
| 1.1.2.5. | Naming conventions for input port names and output port names for each block should be different from those for internal signal names. | 2 |
| 1.1.3.1. | Naming conventions for internal signal names of blocks should be different from those for input and output ports. | 2 |
| 1.1.3.3. | Signal names, port names, parameter names, ```define` names and function names should be between 2 and 40 characters in length. | 2 |
| 1.1.4.2. | Parameter names should have a different naming convention. | 2 |
| 2.1.1.2. | Describe every case statement expressions in a function statement | 8 |
| 2.1.1.3. | Use the syntax analysis tool to avoid mistakes | SVH |
| 2.1.2.2. | A non-blocking assignment <= should not be used in function statements | 41 |
| 2.1.4.5. | Logical operators should not be used for vectors | 144 |
| 2.1.5.3. | In the conditional expression of an if statement or the conditional operator (?) the result should not be a vector | 144 |
| 2.2.1.1. | Latches are generated unless all conditions have been described | 8 |
| 2.2.2.2. | Do not define constants and unnecessary signals in the sensitivity list | 160 |
| 2.7.3.1. | The nesting level for if-if and else if should seven or less. | 167 |
| 2.7.3.3. | Use of tabs (indenting) will reduce mistakes in if statement nesting. | SVH formatting |
| 2.7.4.2. | Be sure to remember to attach begin-end | SVH syntax check |
| 2.7.4.3. | Do not use fork-join in RTL descriptions | SVH formatting |
| 2.8.1.4. | Always add default clauses. | 40 |
| 2.8.3.5. | Describe a default clause at the end of a case statement | 40, 15 |
| 2.10.2.2. | Results of logical operation will be 1 bit | 144 |
| 3.1.2.1. | Follow the basic naming conventions | 2 |
| 3.1.3.1. | Standardize the description order of the port declaration, port list and module instantiation port lists defined in the modules | 163 |
| 3.1.4.2. | Standardize the number of indents used in always constructs, if statements and case statements (two spaces are standard) | SVH formatting |
| 3.1.4.3. | Replace tab with spaces after editing | SVH formatting |
| 3.1.4.4. | Do not describe multiple assignments in one line | 47 |
| 3.1.4.5. | The maximum number of characters in one line should be about 110 | 20 |
| 3.1.5.3. | Set parameter default values | 19 |
| 3.2.3.1 | For component instantiations, connect ports by name connections, not by ordered list | 24 |
| 3.5.2.2. | The file name of a RTL description should consist of <module name>.v or <module name>.sv | 17 + SVH file types |
| 3.5.3.1. | Indicate the circuit name, circuit function, author, and creation date in the file header | 22 |
| 3.5.3.2. | Indicate who made changes and which item was modified in the case of reuse | 22 |
| 3.5.3.3. | Standardize file headers | 22 |
| 3.5.6.7. | Comments should start with // | SVH syntax check |
Mapping of DO-254 rules to SVH rules and features
Documentation on configuring DO-254 rules in SVH
| DO-254 rule | Rule name | SVH rules / features |
|---|---|---|
| CP1 | Avoid Incorrect VHDL Type Usage | 78,79,94,100,131 |
| CP8 | Ensure Complete Sensitivity List | 27,160 |
| CP14 | Avoid Unused Declarations | 128,130,169 |
| SS2 | Ensure Proper Case Statement Specification | 8,16,40 |
| SS4 | Avoid Latch Inference | 8 |
| SS20 | Ensure Nesting Limits | 167 |
| DR2 | Avoid Mixed Case Naming for Differentiation | 166 |
| DR5 | Use Separate Statement Style | 47 |
| DR6 | Ensure Consistent Indentation | Indent on save |
| DR7 | Avoid Using Tabs | 21 |
| DR10 | Ensure Consistent File Header | 22 |
| DR13 | Ensure Company Specific Naming Standards | 2 |
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.
| Description | Reason | ID |
|---|---|---|
A Verilog net type keyword cannot be followed directly by the reg keyword | Superseded by a syntax error | 4 |
| Formal item not found within the instantiated unit | Superseded by a syntax error | 36 |
Unexpected trailing , in parameter list | Superseded by the Empty parameters rule (rule 53) | 52 |
| Regular expressions (RE2/J) compatibility check | Superseded by checks in the settings | 58 |
| Ambiguous design unit reference | Superseded by the more general Ambiguous reference (rule 93) | 72 |