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 VHDL1068: Functions should always return a value VHDL233: Synthesizable functions and procedures should not use external signals and variables
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 (CDC) 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	VHDL1065: Choices should not overlap VHDL1064: Choices outside of range should be removed VHDL003: Each case statement should define an “others” clause
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		VHDL209: Type/Subtype names should be unique in a project 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 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		HDL1028: FSM state signal names should comply with a naming convention VHDL1026: Reset signal names should comply with a naming convention VHDL181: Alias names should comply with a naming convention VHDL187: “for” generate statement labels should comply with a naming convention VHDL1035: Process labels should comply with a naming convention VHDL171: Package 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 VHDL010: Entity names should comply with a naming convention VHDL131: Procedure 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 VHDL119: Signal names should comply with a naming convention VHDL118: Port names should comply with a naming convention