Linty Documentation


DO-254 Coverage by Linty Rules

ID Title Automatable Coverage (full / high / low / none) Comments Linty Rules
CP1 Avoid Incorrect VHDL Type Usage no none Synthesis during Linty analysis would fail  
CP2 Avoid Duplicate Signal Assignments yes none    
CP3 Avoid Hard-Coded Numeric Values yes full   VHDL023: Hardcoded numeric values should be used only in “constant” or “generic”

CP4 Avoid Hard-Coded Vector Assignment yes full   VHDL236: Vector assignments should not be hardcoded

CP5 Ensure Consistent FSM State Encoding Style yes full   VHDL1005: FSM states should be encoded using enumerated type

CP6 Ensure Safe FSM Transitions yes low   VHDL1040: FSM number of states should equal its type number of states

CP7 Avoid Mismatching Ranges yes full   VHDL1066: Objects of different lengths should not be compared

CP8 Ensure Complete Sensitivity List yes full   VHDL1037: The sensitivity list of a process should be minimal

VHDL1072: The sensitivity list of a process should be complete

CP9 Ensure Proper Sub-Program Body yes full   VHDL166: Recursive functions should not be used

VHDL233: Synthesizable functions and procedures should not use external signals and variables

VHDL1068: Functions should always return a value

CP10 Assign Value Before Using yes full   VHDL1069: Signals and variables should be assigned a value before being used

CP11 Avoid Unconnected Input Ports yes full   VHDL138: All output ports (and optionally all input ports) of a component should be mapped

CP12 Avoid Unconnected Output Ports yes full   VHDL138: All output ports (and optionally all input ports) of a component should be mapped

CP13 Declare Objects Before Use no none Synthesis during Linty analysis would fail  
CP14 Avoid Unused Declarations yes full   VHDL135: All declared parameters should be used in the corresponding function/procedure

VHDL134: All declared elements should be used in their corresponding scope

VHDL1052: Unused generate blocks should be removed

VHDL1050: Unused entities should be removed

VHDL1051: Unused architectures should be removed

CDC1 Analyze Multiple Asynchronous Clocks yes full   HDL1000: All clock domains should be reviewed

HDL1001: All clock domain crossings should be reviewed

SS1 Avoid Implied Logic yes low   VHDL224: Internal tristates should not be used

SS2 Ensure Proper Case Statement Specification yes full ‘Be complete’ would be caught at synthesis step of Linty analysis VHDL003: Each case statement should define an “others” clause

VHDL1065: Choices should not overlap

VHDL1064: Choices outside of range should be removed

SS3 Avoid Combinational Feedback yes full   HDL1003: Combinatorial loops should be removed

SS4 Avoid Latch Inference yes full   VHDL1036: “if” statements should always contain an “else” statement in combinational processes to avoid undesired latch inference

VHDL1063: Latches should be removed

SS5 Avoid Multiple Waveforms yes full   VHDL235: Signal assignments should not contain multiple waveforms

SS6 Avoid Multiple Drivers yes full   VHDL140: Concurrent assignments should be complete to avoid undesired latch inference

VHDL139: Signals and variables should not be assigned in multiple processes or equivalent concurrent assignments

SS7 Avoid Uninitialized VHDL Deferred Constants yes full   VHDL155: All deferred constants should be initialized

SS8 Avoid Clock Used as Data yes high   VHDL1012: Clock signals not used as clock of a flip-flop should be reviewed

SS9 Avoid Shared Clock and Reset Signal yes high   VHDL1033: Reset signals not used as reset of a flip-flop should be reviewed

VHDL1012: Clock signals not used as clock of a flip-flop should be reviewed

SS10 Avoid Gated Clocks yes none    
SS11 Avoid Internally Generated Clocks yes none    
SS12 Avoid Internally Generated Resets yes none    
SS13 Avoid Mixed Polarity Reset yes full   VHDL1027: Active-high resets should be preferred over active-low resets

VHDL1028: Active-low resets should be preferred over active-high resets

SS14 Avoid Unresettable Registers yes none    
SS15 Avoid Asynchronous Reset Release yes none    
SS16 Avoid Initialization Assignments yes none    
SS17 Avoid Undriven and Unused Logic no none    
SS18 Ensure Register Controllability yes none    
SS19 Avoid Snake Paths yes low   VHDL172: Conditional branching statements (“if”, “case”, “while” and “for” loops) should not be too deeply nested

SS20 Ensure Nesting Limits yes full   VHDL172: Conditional branching statements (“if”, “case”, “while” and “for” loops) should not be too deeply nested

SS21 Ensure Consistent Vector Order yes full   VHDL036: Vector direction in ranges should always be the same

DR1 Use Statement Labels yes low   VHDL213: Processes should be identified by labels

DR2 Avoid Mixed Case Naming for Differentiation yes full   VHDL136: All references should have the same case as the corresponding declarations

DR3 Ensure Unique Name Spaces yes full   VHDL016: Signal names should be unique in a project

VHDL015: Constant names should be unique in a project

VHDL012: Function names should be unique in a project

VHDL007: Architecture names should be unique in a project

VHDL009: Entity names should be unique in a project

VHDL008: Configuration names should be unique in a project

VHDL234: Variable names should be unique in a project

VHDL209: Type/Subtype names should be unique in a project

VHDL199: Procedure names should be unique in a project

DR4 Use Separate Declaration Style yes full   VHDL126: Multiple declarations should not be written on the same line

DR5 Use Separate Statement Style yes full   VHDL161: Statements should be on separate lines

DR6 Ensure Consistent Indentation yes low   VHDL210: Port clauses should be properly formatted

DR7 Avoid Using Tabs yes full   HDL004: Tabulation characters should not be used

DR8 Avoid Large Design Files yes full   VHDL033: Files should not have too many lines of code

DR9 Ensure Consistent Signal Names Across Hierarchy yes none    
DR10 Ensure Consistent File Header yes full   VHDL239: File header should match a template

DR11 Ensure Sufficient Comment Density yes full   VHDL160: Declarations should be commented

VHDL207: Processes should be commented

VHDL307: Code should be properly commented

DR12 Ensure Proper Placement of Comments yes full   VHDL194: Trailing comments should not be used

DR13 Ensure Company Specific Naming Standards yes full   VHDL181: Alias names should comply with a naming convention

VHDL171: Package names should comply with a naming convention

VHDL187: “for” generate statement labels should comply with a naming convention

VHDL131: Procedure names should comply with a naming convention

VHDL010: Entity names should comply with a naming convention

VHDL130: Function names should comply with a naming convention

VHDL005: Architecture names should comply with a naming convention

VHDL006: Configuration names should comply with a naming convention

VHDL120: Generic parameter names should comply with a naming convention

VHDL122: Type names should comply with a naming convention

VHDL121: Subtype names should comply with a naming convention

VHDL117: Constant names should comply with a naming convention

VHDL116: Variable names should comply with a naming convention

VHDL118: Port names should comply with a naming convention

VHDL119: Signal names should comply with a naming convention

VHDL1026: Reset signal names should comply with a naming convention

VHDL1035: Process labels should comply with a naming convention

VHDL1003: FSM state signal names should comply with a naming convention

VHDL1009: Clock signal names should comply with a naming convention

VHDL309: “if” generate statement labels should comply with a naming convention

VHDL310: “case” generate statement labels should comply with a naming convention