Modern digital design requires rigorous adherence to functional safety standards to ensure reliability and predictability in complex electronic systems. Sigasi provides a comprehensive suite of linting rules mapped to industry-standard guidelines, such as STARC (Semiconductor Technology Academic Research Center) and DO-254 (Design Assurance Guidance for Airborne Electronic Hardware).
STARC
The STARC guidelines provide a set of design rules for VHDL and Verilog to ensure design quality and reusability. Adhering to these rules helps maintain a consistent coding style and prevents common design pitfalls.
For more information on configuring Sigasi’s STARC rules and smoothly integrating the ruleset into your project for your entire team, refer to our how-to article.
The table below lists which STARC rules correspond to which Sigasi’s linting rules.
VHDL STARC mapping
| STARC rule | Rule name | Sigasi Rule |
|---|---|---|
| 1.1.1.1. | File names should be as follows: <entity name>.vhd. | 189 |
| 1.1.1.2. | Only alphanumeric characters and the underscore _ should be used, and the first character should be a letter of the alphabet. | 92 |
| 1.1.1.3. | Reserved words in Verilog (IEEE1364), EDIF, and SDF must not be used. | 192 ((System)Verilog only) |
| 1.1.1.4. | Names beginning with VDD, VSS, VCC, GND or VREF must not be used (uppercase or lowercase). | 92 |
| 1.1.1.5. | Do not distinguish names by using upper or lower case English letters (Abc, abc). | 163 |
| 1.1.1.6. | Entity name and component name should be the same. | 90 |
| 1.1.1.9. | At the top level, entity names and port names should consist of 16 or fewer characters and should not be distinguished by upper or lower case alphabet letters. | 92 |
| 1.1.2.1. | Entity names and instance names should be between 2 and 32 characters in length. | 92 |
| 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. | 92 |
| 1.1.3.1. | Naming conventions for internal signal names of blocks should be different from those for input and output ports. | 92 |
| 1.1.3.3. | Signal names, variable names, type names, label names and function names should be between 2 and 40 characters in length. | 92 |
| 1.1.4.1. | Use <name> + pac.vhd for package files | 198 |
| 1.1.4.2. | For constant declarations, names should start with C_ or P_ and all characters of the names should be in upper case letters | 92 |
| 1.1.6.1. | The architecture name in RTL description should be RTL | 92 |
| 1.1.6.2. | The architecture name in behavior description should be BEH | 92 |
| 1.1.6.3. | The architecture name in test bench description should be SIM or TB | 92 |
| 1.1.6.4. | The entity description and RTL architecture description should be made in the same file | 243 |
| 1.3.1.6. | Do not have both asynchronous reset and synchronous reset on the same reset line | 252 |
| 1.4.3.1. | Avoid inverting logic on the same clock line. Also avoid using gated clocks and using FFs with different edges. | 254 |
| 1.4.3.4. | Do not supply clock signals to pins other than FF clock input pins (such as D input) | 249 |
| 1.4.3.6. | Do not use FFs with inverted edges | 254 |
| 2.1.2.3. | Specify range when using integer | 236 |
| 2.1.2.5. | Do not use attribute enum_encoding | 244 |
| 2.1.6.1. | Specification of a range should be downto, if it is one-dimensional | 211, 241 |
| 2.1.8.8. | Do not use procedure in RTL description | 245 |
| 2.1.9.1. | Use attributes with array; range, length, left, right, high, low, and reverse_range | 244 |
| 2.1.9.2. | Attribute to signal, event, is used for FF inference description | 244 |
| 2.1.9.3. | Do not infer FF by using stable | 244 |
| 2.1.9.4. | Do not use embedded attributes other than the above | 244 |
| 2.1.9.5. | Do not use user-defined attributes | 244 |
| 2.1.10.1. | Do not use block statement | 245 |
| 2.1.10.2. | Do not use record type | 245 |
| 2.1.10.3. | Do not use shared variable | 245 |
| 2.1.10.4. | Do not use while loop | 245 |
| 2.1.10.5. | Do not use procedure | 245 |
| 2.1.10.6. | Do not use with -select | 245 |
| 2.1.10.7. | Do not use configuration | 245 |
| 2.1.10.8. | Do not use synopsys attribute | 245 |
| 2.1.10.9. | Do not use access type | 245 |
| 2.1.10.10. | Do not use alias | 245 |
| 2.1.10.11. | Do not use bus and register | 245 |
| 2.1.10.12. | Do not use disconnect | 245 |
| 2.1.10.13. | Do not use waveform | 245 |
| 2.2.1.1. | Latches are generated unless all conditions have been described | 11 |
| 2.2.2.1. | All signals at the right of the conditional expression and the assignment statement in the process statement of the combinational circuit must be defined in the sensitivity list. | 72 |
| 2.2.2.2. | Do not define constants and unnecessary signals in the sensitivity list | 73 |
| 2.2.2.3. | Do not use wait statement in process statement (Sensitivity list is required) | 39 |
| 2.2.2.4. | The sensitivity list should be verified with a RTL check tool rather than a logic synthesis tool | 38, 39, 72, 73, 85, 197 |
| 2.3.1.2. | Do not use unsynthesizable FF inference styles | 250, 252, 254 |
| 2.3.2.2. | Do not use variable in process statement | 245 |
| 2.3.6.1. | Do not mix FF inferences with and without asynchronous resets in the same process statement | 238 |
| 2.7.2.2. | Avoid describing conditions that will not be executed | 79 |
| 2.7.3.1. | The number of nests for if-if and elsif is best at five or less | 239 |
| 2.8.1.3. | Avoid the overlapping of case items | 14 |
| 2.8.1.4. | Always add others choices | 13 |
| 2.8.3.4. | A syntax error does not occur even if there is no others choice when using integral or enumeration types, however it is better to use others choices | 13 |
| 2.9.3.1. | Do not use exit and next in for-loop statement | 245 |
| 2.10.3.1. | Match the bit width of relational operator | 232 |
| 3.1.2.1. | Follow the basic naming conventions | 92 |
| 3.1.3.4. | Define one signal per line in I/O and declaration statement. Always add comments | 253 |
| 3.1.4.3. | Replace tabs with spaces after editing | 99 |
| 3.1.4.5. | The maximum number of characters in one line should be about 110 | 97 |
| 3.2.2.1. | Describe constants by constants as much as possible | 235 |
| 3.2.3.1. | For component instantiations, connect ports by name connections, not by ordered list | 164 |
| 3.2.3.2. | Match the bit width of the component port and the bit width of the net to be connected | 144 |
| 3.3.3.1. | A clock must not be connected to the D input of a FF | 249 |
| 3.3.6.2. | Do not mix clock lines and reset lines | 249 |
| 3.5.2.2. | The file name of a RTL description should consist of <entity name> + .vhd | 189 |
| 3.5.3.1. | Indicate the circuit name, circuit function, author, and creation date in the file header | 188 |
| 3.5.3.2. | Indicate who made changes and which item was modified in the case of reuse | 188 |
| 3.5.3.3. | Standardize file headers | 188 |
Verilog STARC mapping
| STARC rule | Rule name | Sigasi Rule |
|---|---|---|
| 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.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.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.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 |
| 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 |
DO-254
The DO-254 standard (Design Assurance Guidance for Airborne Electronic Hardware) provides guidance for the development of airborne electronic hardware.
For more information on configuring Sigasi’s STARC rules and smoothly integrating the ruleset into your project for your entire team, refer to our how-to article.
The table below lists which DO-254 rules correspond to which Sigasi’s linting rules.
VHDL DO-254 mapping
| DO-254 rule | Rule name | Sigasi Rule |
|---|---|---|
| CP1 | Avoid Incorrect VHDL Type Usage | 144 |
| CP3 | Avoid Hard-Coded Numeric Values | 235 |
| CP5 | Ensure Consistent FSM State Encoding Style | 237, 71 |
| CP7 | Avoid Mismatching Ranges | 1, 26 |
| CP8 | Ensure Complete Sensitivity List | 72, 73 |
| CP9 | Ensure Proper Sub-Program Body | 76 |
| CP11 | Avoid Unconnected Input Ports | 17 |
| CP12 | Avoid Unconnected Output Ports | 94 |
| CP14 | Avoid Unused Declarations | 88, 89, 55, 67, 68 |
| SS2 | Ensure Proper Case Statement Specification | 11, 13, 14 |
| SS7 | Avoid Uninitialized VHDL Deferred Constants | 175 |
| SS8 | Avoid Clock Used as Data | 249 |
| SS9 | Avoid Shared Clock and Reset Signal | 249 |
| SS10 | Avoid Gated Clocks | 249 |
| SS13 | Avoid Mixed Polarity Reset | 252 |
| SS21 | Ensure Consistent Vector Order | 211, 241 |
| DR1 | Use Statement Labels | 42, 43, 44 |
| DR2 | Avoid Mixed Case Naming for Differentiation | 163 |
| DR4 | Use Separate Declaration Style | 253 |
| DR7 | Avoid Using Tabs | 99 |
| DR10 | Ensure Consistent File Header | 188 |
| DR13 | Ensure Company Specific Naming Standards | 92 |
Verilog DO-254 mapping
| DO-254 rule | Rule name | Sigasi Rule |
|---|---|---|
| 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 |
| DR7 | Avoid Using Tabs | 21 |
| DR10 | Ensure Consistent File Header | 22 |
| DR13 | Ensure Company Specific Naming Standards | 2 |