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.
VHDL STARC mapping
Documentation on configuring STARC rules in Sigasi.
| 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
Documentation on configuring STARC rules in Sigasi.
| 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.
VHDL DO-254 mapping
Documentation on configuring DO-254 rules in Sigasi.
| 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
Documentation on configuring DO-254 rules in Sigasi.
| 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 |