Best Practice VHDL Coding Standards for DO-254 Programs

DO-254 Users Group Position Paper DO254-UG-001Best Practice VHDL Coding Standards for DO-254 Programs COMPLETED 2/26/10 (MODIFIED 9/13/10) (Rev 1a) Team Primary Author: Michelle Lange NOTE: This position paper has been coordinated among representatives from the Europe and US DO254 users groups. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering actual projects. This position paper does not represent an official position of the EASA, FAA or Eurocae/RTCA related committees. Contents 1.0 PURPOSE ..............................................................................................................................................22 2.0 BACKGROUND ....................................................................................................................................22 3.0 REFERENCES ......................................................................................................................................33 4.0 TERMINOLOGY ..................................................................................................................................33 5.0 INTRODUCTION .................................................................................................................................33 6.0 SUGGESTED CODING STANDARDS (RULES) .............................................................................44 Category: Coding Practices (CP) .................................................................................. 44 Category: Clock Domain Crossing (CDC) ............................................................... 1414 Category: Safe Synthesis (SS) .................................................................................. 1515 Category: Design Reviews (DR) .............................................................................. 2828 7.0 BEST PRACTICE USAGE OF AUTOMATED HDL STANDARDS CHECKING ...................3333 Benefits of Automated Checking .............................................................................. 3333 Use Model for Automated HDL Code Checking ..................................................... 3434 Considerations for Tool Assessment ........................................................................ 3535 8.0 THE “DO-254” RULESET IN MENTOR GRAPHICS HDL DESIGNER TOOL .....................3636 9.0 SUMMARY ........................................................................................................................................3636 1 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. This position paper does not represent an official position for the FAA, EASA or RTCA / Eurocae related committees. Best Practice VHDL Coding Standards for DO-254 Programs 1.0 Purpose DO-254 discusses the need for “Design Standards” and FAA Order 8110.105 takes this a step further, discussing the specific need for HDL coding standards. Many companies having to comply with DO-254 are either looking for examples of good standards, or have insufficient or inconsistent standards. This paper provides a list of generally accepted HDL (specifically VHDL) design best practice coding guidelines that should be considered for a fail-safe design, including DO-254 programs. These coding guidelines should not be viewed as what must be done in a DO-254 program. What must be done is always the decision of the applicant in conjunction with the certification authority. However, if a project team is looking for a good foundational set of checks to assess the HDL design quality for their DO-254 program, this document provides that foundation. The standards or checks presented in this document serve one of three purposes, specifically: 1) Catching potential design problems in HDL code that may not normally surface until later in the process and may not be caught by other verification activities, 2) Supporting error detection, containment and recovery mechanisms, and 3) Enforcing style and readability practices to improve code comprehension, portability, and reviews. In DO-254 programs, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards. While reviews can be done manually, an automated approach (when possible) guarantees a more consistent HDL code quality assessment. Automating the HDL code assessment process, often called linting, has the added benefit of promoting regular HDL design checking steps throughout the design development process, as opposed to waiting for gating design reviews where issues can be overwhelming and more costly to address. This paper also discusses automation when appropriate, and states that a combination of automation and manual reviews can lead to best results. 2.0 Background FAA Order 8110.105 section 6-2a clarified that HDL coding standards should be defined and checked when it stated: “To prevent potentially unsafe attributes of HDLs from leading to unsafe features of the components, we must expect that, if they use an HDL, applicants define the coding standards for this language consistent with the system safety objectives, and establish conformance to those standards by HDL code reviews.” In the EASA context, guidance for the use of HDL is also required, and conformance to those standards should be established. 2 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. This position paper does not represent an official position for the FAA, EASA or RTCA / Eurocae related committees. digital logic. This paper presents a foundational set of checks that an applicant may use if they do not already have a good set of standards in-house.. 3 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. register transfer level (RTL) description is a way of describing the operation of a synchronous digital circuit. Document RTCA/DO-254 c. RTL – Register Transfer Level. a circuit's behavior is defined in terms of the flow of signals (or transfer of data) between hardware registers. An HDL is any language from a class of computer languages and/or programming languages for formal description of electronic circuits. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. VHDL – VHSIC Hardware Description Language. Register transfer level abstraction is the level of design representation in which hardware description languages (HDLs) like Verilog and VHDL are used to define the circuit. where VHSIC stands for “very-high-speed integrated circuit. . EASA Certification Memos and CRIs on recent programs (non public material) 4. Design Assurance Guidance For Airborne Electronic Hardware. This position paper does not represent an official position for the FAA. Inc. By developing and following a good set of HDL coding standards. Note that the coding standards shown in this document apply to HDL for use as a design language. FAA AC 20-152. from which technology specific implementations can be derived.105 d. such as VHDL. The flexibility of the language can lead to downstream problems and in-hardware design errors that cannot only be very hard to debug but also pose potential threats to safety. are very flexible.0 Introduction HDL languages. FAA Order 8110.0 References a. It can describe the circuit's operation. EASA or RTCA / Eurocae related committees. They allow extensive flexibility and creativity in coding. not necessarily for verification testbenches.This has led many applicants to ask for a good set of HDL coding standards. RTCA. b.0 Terminology For this paper. 5. 3.” VHDL is a hardware description language used in electronic design automation to describe digital and mixed-signal systems such as Field-Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs). In integrated circuit design. its design and organization. In RTL design. and tests to verify its operation by means of simulation. and the logical operations performed on those signals. and more specifically. the following terminology applies: HDL – Hardware Description Language. RTCA/DO-254 (EUROCAE ED-80). errors should always be corrected. 6. which provides a measure of the worst case impact a standard violation can have on safety. where appropriate. While the guidance of FAA Order 8110. both case statements and finite state machines are prone to undesired synthesis optimizations. 4 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. this paper provides a foundational set of standards that could be considered best practice coding guidelines for the VHDL language. The other half lies with setting up the synthesis tool properly to ensure the intent of the HDL is properly synthesized. The categories are 1) Coding Practices. but each category serves a distinct purpose as described. in the coding rules descriptions that follow. These concerns are explained. Each rule that follows is given a coding practice (CP) number for ease of reference. These categories are arbitrarily named.105 states that HDL coding standards are required for DAL A/B devices. Each coding standard has a default severity level of Error. Category: Coding Practices (CP) This category of standards ensures that a coding style supporting safety-critical and good digital design practices are used. From this collective experience and input. even if properly coded in HDL. 3) Safe Synthesis. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. For example. This paper presents a set of standards that have been developed from the input of many companies doing safety-critical design and also the input of 20 individuals participating in both the US and EU DO-254 User Groups. following these standards in general for all designs would be considered a best practice. 2) Clock Domain Crossings.many potential problems can be caught early and addressed before they turn into bugs in a physical implementation. Warning. warnings should usually be corrected but may have documented and justified exceptions. EASA or RTCA / Eurocae related committees. or Note. and 4) Code Reviews. . In general. Each coding standard listed hereafter falls under one of four categories. depending on the design assurance level assigned to the design as well as the project team’s own coding style and preferences.0 Suggested Coding Standards (Rules) The following coding standards are suggested for VHDL synthesizable code for DO-254 projects. The standards and severity levels are potentially editable by the project team. Note that in some cases. ensuring good HDL coding practice is only half of the solution. This position paper does not represent an official position for the FAA. and notes should simply be examined to ensure there is no impact on safe design operation. Default severity: Error Example: ENTITY top IS port (rf2fe_vec: IN dword). and this may or may not be flagged by the synthesis tool. hard-coded numeric values should not be 5 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. EASA or RTCA / Eurocae related committees. Avoid Incorrect VHDL Type Usage (CP1) Check for the incorrect use of types.more lines beep <= '1'.Type error at ‘rf2fe_vec’. Avoid Duplicate Signal Assignments (CP2) The same signal should not be assigned a value more than once within the same statement region. ARCHITECTURE rtl OF top IS signal tx_index: std_logic_vector (14 DOWNTO 0).Default Reset Values beep <= '0'. Default assignments (one occurrence) should be acceptable as indicated in the example below. …. -. This check ensures the designer will be warned consistently during HDL design development.Duplicate assignment maybe a mistake ELSIF (falling_edge(clk)) THEN 3. 2. Needed type ‘std_logic_vector’ END rtl. Default severity: Warning Example: same_signal <= '0'. It will also ensure implementation of a more portable design IP review process. it is beneficial to correct the problem as early as possible. A violation leads to a potential conflict on the signal assignment.This is NOT a duplicate assignment. and/or constraints. An assignment is considered duplicated if its left hand side exists more than once in the same statement region in the same process that is being checked. Avoid Hard-Coded Numeric Values (CP3) For design IP reuse and portability ease. as opposed to waiting until synthesis. -. This position paper does not represent an official position for the FAA. . IF (reset = '1') THEN -. which could have different results across different synthesis tools. -.1. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. tx_index <= rf2fe_vec (f_txindex_hi DOWNTO f_txindex_lo). -. -. END IF. While these types of issues are usually caught during compilation.Default assignment IF (reset = '1') THEN same_signal <= '1'. incompatible bounds. 6 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group.cpu data bus width ENTITY dual_clock_cache_struct is PORT( cpu_addr : IN std_logic_vector( 15 DOWNTO 0 ). Default severity: Note Example: WHEN OTHERS => clk_div_en xmitdt_en ser_if_select ser_in_select <= <= <= <= '0'. -.violation cpu_di : IN std_logic_vector(CPU_DATA_WIDTH-1 DOWNTO 0).Violation (OTHERS => ‘0’). --32-bit cpu_clk : IN std_logic. b. . This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. -. do not use hard-coded values. Default severity: Warning Example: PACKAGE dcc_pkg is ------------------------------------. A design should employ a consistent state encoding style for Finite State Machines (FSM). CONSTANT CPU_DATA_WIDTH : INTEGER := 32. Avoid Hard-Coded Vector Assignment (CP4) For vector reset assignments.This is preferred 5. This limits the impact of changing vector sizes and enhances design portability ease. 4. This position paper does not represent an official position for the FAA. . . -.cpu address bus width -.constant declarations -----------------------------------CONSTANT CPU_ADR_WIDTH : INTEGER := 16. unless unavoidable. EASA or RTCA / Eurocae related committees.used. Ensure Consistent FSM State Encoding Style (CP5) a. This will greatly reduce the probability of a design error from creeping into the design code as it is being ported to a new application. "00000000". The reset assignment should be done in a way that is independent of the size of the vector. '0'. . -.FSM state types should not be hard-coded. Constants or generics should be used and documented within the design. STALL_WAIT. Consult your synthesis tool vendor for more information. the synthesis tool must also be set up properly to implement the FSM state encoding consistently in the targeted hardware. ) BEGIN CASE current_state_r is WHEN IDLE => . some organizations’ coding guidelines may enforce a hard coded FSM state definition to avoid unexpected synthesis results. .reset & default state START_OP. P_CPU_SM_NEXT_STATE : PROCESS( . how to minimize the number of bit-flips at state transitions. Note that in general. EASA or RTCA / Eurocae related committees. this rule ensures that the appropriate FSM style is consistently used throughout the design.) without modifying the HDL code. . etc. FSM states are encoded as enumerated type DO_RD ). WHEN START_OP => . . whether TMR (Triple Modular Redundancy) is required.Inconsistent FSM encoding style may interfere with the design’s FSM error detection and recovery scheme for the operating environment. WRITE_DATA. Enumerated types facilitate more flexibility in the synthesis implementation as users can select the encoding style used (one-hot. These aspects support greater design portability and insure FSM error detection and recovery. . Default severity: Error Example: TYPE cpu_sm_state_type IS ( IDLE. As an exception to this rule. END PROCESS P_CPU_SM_NEXT_STATE. . the error detection. . Enumerated state types make HDL code more readable generally. The synthesis tool control can be achieved through a pragma in the code or via an external control file. care must be taken in designing state machines and each project must determine the FSM coding styles allowed. . . WHEN “0011” => -. -. -. gray. END CASE. inconsistent state encoding .Note. This position paper does not represent an official position for the FAA. Note that while this check of the HDL code is important. Considerations may include whether one-hot encoding is allowed. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. .Violation. 7 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. When these decisions are made. error isolation and recovery mechanisms to be employed. binary etc. WAITMEM. DO_READ. . Default severity: Error Example: TYPE fsm_state_type IS ( IDLE. those without any outgoing transitions) in an FSM. It should be noted that some designs may have other well-defined schemes for fault condition mitigation and recovery.6. -. including FSM state registers. EASA or RTCA / Eurocae related committees.wait for memory response STALL_WAIT. . WRITE_DATA. This position paper does not represent an official position for the FAA. Thus. -. then it will remove the fault condition detection and recovery logic during synthesis optimization. An FSM should have a defined reset state. . ground bounces and SEUs (Single Event Upsets)... b. DO_READ.Commented out AIS state will cause violation ). If the FSM design contains a fault condition detection and default error recovery transition. memory logic. Ensure Safe FSM Transitions (CP6) a. the synthesis tool must also be set up properly to implement the safe FSM design consistently in the targeted hardware. If the synthesis tool’s control options have not been properly configured for safe FSM implementation. CASE current_state IS WHEN IDLE => 8 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. Check with your synthesis tool vendor for more information. whereupon this error condition can be processed accordingly. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. then the transient event(s) inducing the invalid state will be recoverable by way of a defined transition to a safe recovery state.AIS -. c. The synthesis tool control can be achieved via an external control file. . -. All unused (illegal or undefined) states should transition to a defined state.e. can change state unpredictably due to supply-rail transients. There should be no unreachable states (i.e. Checking for these issues is central in determining if the FSM design will be able to handle adverse operating conditions that could induce invalid FSM state transitions. it is possible to check for improperly written HDL code that does not implement a faulttolerant FSM design at the RTL level.reset & default state START_OP. This will result in a incorrect in-hardware logic implementation of the RTL code. this standard would be modified or unnecessary. those without any incoming transitions) and dead-end states (i. Note that while this check of the HDL code is important. WAITMEM. and in those cases. In general.cpu stall DO_RD -. 7. comparison. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. variable local_var2 : std_logic_vector (1 DOWNTO 0). END.Violation. . EASA or RTCA / Eurocae related committees. out1 : OUT std_logic_vector(31 DOWNTO 0)). Ensure Complete Sensitivity List (CP8) The sensitivity list should only contain the signals needed by the process. . in2 : IN std_logic_vector(31 DOWNTO 0). This position paper does not represent an official position for the FAA.IF (rd_req=’1’ AND pre=’0’) THEN next_state <= DO_RD. . Mismatching range in an assignment. BEGIN local_var1 := in1 (sel1 + 1 DOWNTO sel1).Violation. or association should match. no incoming transition next_state <= DO_RD. . sel2 : IN integer range 0 TO 15. or association might result in logic overflow errors. including error states next_state <= AIS. since the range is actually static although --the left and right indices are not. The sensitivity list of a VHDL process should only include the required signals and 9 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. 8. --This is not --a violation. no outgoing transition WHEN OTHERS => -. Avoid Mismatching Ranges (CP7) Bit widths on both sides of an assignment. . WHEN DO_RD => IF (pre=’1’) THEN status <= WAITMEM. Default severity: Warning Example ENTITY nonStatRange IS PORT ( in1 : IN std_logic_vector(31 DOWNTO 0). in2) variable local_var1 : std_logic_vector (1 DOWNTO 0).Violation END PROCESS. .Others. sel1 : IN integer range 0 TO 15. -. -. END. comparison.transition to the AIS state -. ARCHITECTURE arch_nonStatRange OF nonStatRange is BEGIN sm_proc: PROCESS(in1. local_var2 := in2 (sel1 + sel2 DOWNTO sel1).Violation. . AIS is not a defined state END CASE. -. WHEN DO_READ => -. Missing signals potentially lead to mismatching simulation versus synthesized hardware function. -. functions. have only one exit point b. Default severity: Warning Example: FUNCTION logicop (in1. have no recursion c.rst. WHEN incr_count2 => IF (sample='1' AND rcv_bit_cnt_cld /= "111") THEN rcv_bit_cnt_cld <= unsigned(rcv_bit_cnt_cld) + 1. in2 : IN bit_vector. END PROCESS RCV_CLOCKED_PROC. Existence of unused signals should be justified. c2 : IN bit) RETURN bit_vector IS 10 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. The unused signals will slow down simulation. . IF (sin='0') THEN rcv_bit_cnt_cld <= "001". Default severity: Warning Example: RCV_CLOCKED_PROC : PROCESS ( clk. signal needed in sensitivity list rcv_bit_cnt_cld --Violation. --Violation. its justification should be documented. ) BEGIN IF (rst = '0') THEN rcv_current_state <= waiting. if the code is intentionally designed this way (such as a recursive sub-program). Ensure Proper Sub-Program Body (CP9) Each sub-program must: a. CASE rcv_current_state IS WHEN waiting => rcv_bit_cnt_cld <= "000". In some cases. signal unnecessary --will cause process to be trigger more than needed. END IF. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects.does not include any unnecessary signals. END CASE. WHEN OTHERS => NULL. and tasks. c1. END IF. 9. This position paper does not represent an official position for the FAA. ELSIF (falling_edge(clk)) THEN rcv_current_state <= rcv_next_state. EASA or RTCA / Eurocae related committees. access only local variables/signals Check for all these conditions in procedures. END IF. Default severity: Warning Example: ENTITY fifo_bk_pressure IS PORT( -. -. -. . This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects.Cut-and-paste error.Port Declarations clk_ck2 : IN std_logic. . . .register definitions -----------------------------------signal full_threshold_r : fifo_cntr_type. . EASA or RTCA / Eurocae related committees. This position paper does not represent an official position for the FAA. -. results in violation . . -. port) should be assigned a value before using it. multiple exit points ELSIF(c2 = '1') AND (adr_mode = ‘1’) THEN RETURN (in1 AND in2). .g. signal or constant value.GLOBAL: downstream clock rst_ck2_n : IN std_logic.Violation. END FUNCTION.9-bit -. Assign Value Before Using (CP10) Every object (e.BEGIN IF(c1 = '1') THEN RETURN (in1 OR in2). . full_threshold_r) BEGIN assert_bk_pressure_s <= ‘0’. which is most likely unintentional functional behavior for the design. ELSIF (cntr_ck2_i = full_threshold_r – CDC_DELAY) THEN --VIOLATION “cntr_ck2_i” should be assigned before being read assert_bk_pressure_s <= ‘1’.GLOBAL: downstream reset(N) cntr_ck1_i : IN std_logic_vector(FIFO_CNTR-1 DOWNTO 0). When objects are used before being defined.9-bit data type threshold_proc: PROCESS(cntr_ck2_i. 10.. ARCHITECTURE rtl OF fifo_bk_pressure is ------------------------------------.Violation END IF. 11 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. -. END PROCESS threshold_proc. . Avoid Unconnected Input Ports (CP11) All input ports should be driven by a port. a latch may be inferred during synthesis. signal. 11. variable. should be cntr_ck2_i. ). -. END IF. varying with changes in voltage-rails and operating conditions. out2 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0) ). U_bad: usable_vhd PORT MAP( in1 => d.unused input port “in2”. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. In these cases. Default severity: Error Example: component usable_vhd PORT ( in1 : IN std_logic . in2 : IN std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0).actively driven by another signal or fixed to ‘0’ or ‘1’ 12. out1 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0). out2 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0) ). EASA or RTCA / Eurocae related committees. that should be -. such as with built-in self test (BIST) output signals used for debug. . out1 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0). Unconnected input ports can cause the associated circuit blocks to exhibit nondeterministic functional behavior in hardware. out2 => q ). a floating output is acceptable.. Unit bound to instance “U_bad” has an -. This position paper does not represent an official position for the FAA. out1 => q. Default severity: Note Example: component usable_vhd PORT ( in1 : IN std_logic . the violation should be justified and documented. 12 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. out1 => FLOAT. . U_bad: usable_vhd PORT MAP ( in1 => d. in some cases.Input ports and bidirectional ports should be connected and not left floating. . out2 => q ). However. .. Avoid Unconnected Output Ports (CP12) Design output ports should be connected.VIOLATION. . in2 : IN std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0). -. Output ports should usually be connected to an internal signal. all. Unused declared objects are considered dead code. Note: While this sort of error will be caught downstream in compilation. read from or assigned to). Unit bound to instance “U_bad” has a unconnected output port “out1” unused output port “out1”. Default severity: Error Example: ENTITY top IS GENERIC (Speed: SpeedType := typical. Declare Objects Before Use (CP13) Objects should be declared before use.out2(2 DOWNTO 0) not used in RTL code ). Avoid Unused Declarations (CP14) All declared objects should be used. -. 14. ).‘SpeedType’ is an unknown type PORT( .-. ARCHITECTURE unuseddecl_rtl OF unuseddecl IS SIGNAL temp1. BEGIN 13 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group.…. . All objects used must be declared. Default severity: Warning Example: LIBRARY ieee. but are never used (i. out2 : OUT std_logic_vector(3 DOWNTO 0) -. USE ieee. .Violation -.Violation -. Check for objects that have been declared. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. .e. The dead code could be inadvertently activated during the code base port.).. EASA or RTCA / Eurocae related committees. Dead code can be detrimental when a design is reused.in1(3 DOWNTO 1)not used in RTL code out1.----- VIOLATION. END. that should be actively driven by another signal or by fixed ‘0’ or ‘1’ 13. temp2 : std_logic.std_logic_1164. ENTITY unuseddecl IS PORT ( in1 : IN std_logic_vector (3 DOWNTO 0).Violation out1 not used in RTL code below. -. it is useful to check for it as early as possible as it is a very common mistake that results in misinterpreted code. This position paper does not represent an official position for the FAA. temp1 <= in1(0).Violation Signal 'temp1' is never used out2(3) <= temp2. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. or if internally-generated clocks are allowed.mentor. analyzed to verify that they are properly addressed by a synchronizer circuit. This challenging design methodology should be identified due to the extreme difficulties associated with isolating and debugging the intermittent CDC-error-induced functional behavior at the hardware level. For those interested in learning more about clock domain crossing issues and analysis techniques. and. all digital designs should be reviewed for potential clock domain crossing boundaries. -. . Analyze Multiple Asynchronous Clocks (CDC1) Any time a design has multiple asynchronous clocks. Improper clock domain crossings result in metastability or indeterminate circuit operation. when found.pdf ) • “Automating Clock-Domain Crossing Verification for DO-254 (and other SafetyCritical) Designs” a whitepaper developed by Mentor Graphics (available here: http://www. It is often impossible to consistently duplicate these CDC-errorinduced behaviors in hardware for design debug. refer to: • 2008 FAA SW and AEH presentation “Mitigating the Dangers of Multi-Clock Designs” (available here: http://www. but it will occur during infield (i. in-flight) operating conditions given the right set of environmental factors for the targeted system application. a CDC error might not exhibit itself during normal testing conditions.. -.mentor. a thorough clock domain crossing (CDC) analysis should be done. voltage rails and ground bounce. even though clock domain crossing issues and analysis is beyond the scope of typical HDL linting tools and beyond the scope of this document. 1. transistor junction temperature. Making this situation worse. In a worst case scenario.com/products/fpga/do254/upload/multi-clock-designs. This position paper does not represent an official position for the FAA.e. EASA or RTCA / Eurocae related committees. circuit elements are affected by the operating conditions. As part of the design review process. Category: Clock Domain Crossing (CDC) This set of standards addresses potential hazards with designs containing multiple clock zones and asynchronous clock zone transitions. such as loading.Violation Signal 'temp2' is never assigned END. This design guidance needs to be mentioned.com/products/fpga/do-254/techpubs ) 14 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. which can have serious adverse affects on a device’s operation. av_i : IN std_logic_vector (10 DOWNTO 0). This sort of implied logic includes feed-throughs. such as inverters. Default severity: Warning Example: SIGNAL mode : std_logic. 15 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. this could be allowed and the applicant should document and justify the warning in these cases.Internal signal -.Do not allow internal tristates END IF. delay chains. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. -. ARCHITECTURE rtl OF feed_through_ea IS BEGIN x_o <= a_i. This position paper does not represent an official position for the FAA. This implied logic might prevent the design code base from being synthesized in a consistent manner across different device technologies. -. . Certain coding styles that are dependent on implied synthesis constructs can be dangerous. -. Delay chains are two or more consecutive components with a single fan-in and single fan-out. ELSE tri_bus <= "Z0". and internal tri-state drivers. such as tri-state assignments and small width counters.Internal Tri-state Control SIGNAL tri_bus : std_logic_vector (1 DOWNTO 0). Example: ENTITY feed_through_ea IS PORT( a_i : IN std_logic. x_o : OUT std_logic ). In some cases. END PROCESS Tristate_Control. EASA or RTCA / Eurocae related committees. delay chains.(not top level port) … Tristate_Control: PROCESS (mode) BEGIN IF (mode = '0') THEN -. and internal tri-state drivers.Do not allow internal tristates tri_bus <= "0Z". -.Category: Safe Synthesis (SS) The following standards are checked to ensure a proper netlist is created by the synthesis tool. 1. Avoid Implied Logic (SS1) Do not allow coding that implies feed-throughs. feed-through from input port “a_i” to output port “x_o” Example: ENTITY delay_ea IS GENERIC (ADR_WIDTH : INTEGER := 8). END feed_through_ea.Violation. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Incomplete case statements will not synthesize in a predictable manner.Violation. Default severity: Error Example: CASE addr IS WHEN "000" => clk_div_en <= '1'. END delay_ea. when this logic is driven by a non-predefined input pattern (e. signal adr_inv2_s : std_logic_vector(ADR_WIDTH-1 DOWNTO 0). Note that while this check of the HDL code is important. Never have unreachable case items d. Always include the “when others” clause Case statements need to define operations for all enumerations of the case variable. EASA or RTCA / Eurocae related committees. This position paper does not represent an official position for the FAA. its functional behavior will be dependent on the synthesis and place-and-route tools’ optimization algorithm settings.. and even the computing environment used to execute the downstream tool runs. BEGIN adr_inv1_s adr_inv2_s adrx_o “adr_i” to <= NOT(adr_i). Be complete b. Never have duplicate/overlapping statements c. Ensure Proper Case Statement Specification (SS2) Case statements should: a. . the synthesis tool must also be set up properly to implement fault-tolerant design consistently in the targeted hardware. delay chain from input port output port “adrx_o” 2.Not reachable case specification 16 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. WHEN "000" => clk_div_en <= '1'.g.PORT( adr_i : IN std_logic_vector(ADR_WIDTH-1 DOWNTO 0). during ground bounce condition or SEU). -. <= NOT(adr_inv1_s). the release version. Thus. ARCHITECTURE rtl OF delay_ea is signal adr_inv1_s : std_logic_vector(ADR_WIDTH-1 DOWNTO 0). av_i : IN std_logic_vector(10 DOWNTO 0).Incomplete case specification -. The synthesis tool control can be achieved through a pragma in the code or via an external control file. adrx_o : OUT std_logic_vector(ADR_WIDTH-1 DOWNTO 0) ). WHEN "001" => clk_div_en <= '1'.Duplicate/overlapping case specification -. <= adr_int2_s. WHEN "10X" => -. EASA or RTCA / Eurocae related committees. the synthesized hardware behavior may not match functional simulation. In many cases latches may be introduced unintentionally. While latches might simulate properly. Careful consideration should be given to the creation of latches in a design.Violation. Avoid Latch Inference (SS4) The HDL coding style should avoid inference of latches. This does not apply to the IF-statement for the clock. fred_s 4. END IF. pulse_r) BEGIN gated_in_s <= fred_s AND en_i. 3. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. This design check could also be referred to as “asynchronous feedback loops. Avoid Combinational Feedback (SS3) Do not allow reading and assigning to the same signal in the same combinational process.Violation. This position paper does not represent an official position for the FAA. WHEN "110" => ser_if_select <= addr(1 DOWNTO 0). at fred_s P_GATED_IN : PROCESS( en_i. The HDL coding style should avoid inference of latches. due to coding errors.Missing WHEN OTHERS clause END CASE.” Default severity: Error Example: <= gated_in_s OR pulse_r. -. feedback loop IF (en_i = '0') THEN gated_in_s <= NOT(fred_s). async.loop. ser_if_select <= addr(1 DOWNTO 0). WHEN "111" => clr_int_en <= '1'. a good HDL coding practice is to write every IF-statement ending with an ELSE to avoid unnecessary latches in the design. fred_s. -. feedback loop ELSIF (pulse_r <= '1') THEN gated_in_s <= '0'. . making the design’s functional behavior unpredictable. async. Such combinational feedback paths cause race conditions. -. To avoid this problem.Violation combinational feedback -. END PROCESS P_GATED_IN.xmitdt_en <= '1'. 17 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. as a result of synthesis inference of the IF-statement functional behavior. A non-used ELSE-statement should be declared with a NULL. -. out2(0) <= in2.If a project decides not to allow any asynchronous design. -. A waveform consists of an assignment value expression and an optional assignment delay expression. in2. in4 : IN std_logic. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. However. in4) BEGIN IF( in4 = '0') THEN out2(3) <= in1. in3. END PROCESS. synthesized hardware behavior will not match simulation. Default severity: Error Example: nRW <= '1' AFTER clk_prd. out2 : OUT std_logic_vector(3 DOWNTO 0)). out1 : OUT std_logic. the severity should be considered Warning. With multiple waveforms. Avoid Multiple Drivers (SS6) The same signal/variable should be assigned in only one sequential block. and the applicant should document and justify each case.Violation 5. in3. Multiple waveforms are non-synthesizable. Avoid Multiple Waveforms (SS5) Only one waveform should exist on the right-hand side of a signal assignment.Violation. END IF. Default severity: Warning Example: library ieee. in2. this should be considered an Error.std_logic_1164. -. use ieee. ARCHITECTURE arch OF vhdlatch IS BEGIN PROCESS (in1. EASA or RTCA / Eurocae related committees. 18 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. ELSE out2 <= (others => in3). Only first waveform element used for synthesis 6. ENTITY vhdlatch IS PORT ( in1.all. END. if it is acceptable in certain cases. '0' AFTER 8 * clk_prd. END. This position paper does not represent an official position for the FAA. . Multiply-driven signals can synthesize as “bucking drivers” in the hardware implementation and exhibit latent in-field failures of these circuits. test_proc: PROCESS(a2) BEGIN a3 <= a2. END. EASA or RTCA / Eurocae related committees. ARCHITECTURE rtl OF top IS BEGIN operate_proc: PROCESS(a1) BEGIN a3 <= a1 and "10101000". 19 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group.value may not be synthesizable END trafficPackage. they may not be synthesizable. ENTITY top IS PORT( a1. use ieee. Default severity: Warning Example: PACKAGE trafficPackage IS CONSTANT MaxTimerVal: integer –.Associated Violation END PROCESS. Deferred constant ‘MaxTimerVal’ without initial -. END rtl. -. simultaneously active drivers.Violation END PROCESS. A constant can be declared in a package without an initialization. Avoid Uninitialized VHDL Deferred Constants (SS7) Ensure all VHDL deferred constants are initialized. 7. -. When VHDL deferred constants are not initialized. Default severity: Error Example: library ieee. . a2 : IN std_logic_vector(7 DOWNTO 0).A signal/shared variable should not have multiple. It is important to ensure that VHDL deferred constants do actually get initialized.Violation.std_logic_1164. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. The corresponding package body should contain the initialization. which may become permanent.all. This position paper does not represent an official position for the FAA. a3 : OUT std_logic_vector(7 DOWNTO 0)). Constants defined using this style are called deferred constants. ELSIF rising_edge(mclk) THEN pulse_r <= gated_in_s. -. the reset signals should be coded in HDL in a clear manner to insure that they are mapped onto dedicated reset routing resources.8. clock signals should be coded in HDL in a manner to help the downstream tools synthesize and map them onto the dedicated clock routing resources.Violation clock used as data BEGIN -. Thus. IF (in1 = TRANSITION) and (mclk = '0') THEN -. mclk) BEGIN gated_in_s <= '0'. and therefore could easily be overlooked. since it can potentially be used as data outside the design. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. EASA or RTCA / Eurocae related committees. END PROCESS P_GATED_IN. Shared clock and reset functions for the same signal will cause race conditions in the design. the recommended severity is error. Similarly. This standard would also be violated in the case where a clock signal happens to be a primary output of the design (that is. output of the top design unit). Avoid Clock Used as Data (SS8) Clock signals should not be used in a logic path that drives the data input of a register. . Default severity: Error 20 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. it may only be shown as a “warning” in the synthesis environment. END IF. This will mitigate potential timing violations due to different routing implementations and design code base ports targeting a different device. This ensures the issue is caught and addressed. END PROCESS P_PULSE_FF. 9. rst_n) -. Clock signals used as data can result in potential race conditions. This position paper does not represent an official position for the FAA. P_PULSE_FF : PROCESS(mclk.See below END IF. In general. Default severity: Error Example: P_GATED_IN : PROCESS(in1. Avoid Shared Clock and Reset Signal (SS9) The same signal should not be used as both a clock and reset signal.Race condition can occur here IF (rst_n = '0') THEN pulse_r <= '0'. While synthesis engines should catch this issue.Associated Violation gated_in_s <= '1'. the suggested severity is generally Warning because in some cases (e. EASA or RTCA / Eurocae related committees. END PROCESS P_FRED_R. -. due to propagation delay and SET (Single Event Transient) effects. battery-power devices). If the project’s standards determine it is never OK to use clock gating. then the severity should be set to Error. 10. END IF. special consideration for the targeted FPGA device technology must be taken into account. Additionally. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Clock gating designs for FPGA should not be allowed if the targeted FPGA device does not contain special purpose-built clock gating circuitry in silicon.Example: reset_n <= mclk AND en_i.reset_n signal has embedded clock P_FRED_R : PROCESS(mclk. Careful consideration of potential adverse effects when halting and starting up the associated circuit block(s) must be reviewed. END PROCESS P_PULSE_FF. ELSIF rising_edge(clk_s) THEN pulse_r <= in1(DIR_BIT). ELSIF rising_edge(mclk) THEN fred_r <= in1(DIR_BIT). 21 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. This position paper does not represent an official position for the FAA. each implementation and justification must be documented thoroughly. Coding should be checked for the usage of gated clocks throughout the design. clock gating is intentionally designed in to save power. However. Default severity: Warning Example: clk_s <= mclk AND en_i. Gated clocks can cause clock skews and are sensitive to glitches.Violation shared clock & reset signal fred_r <= '0'. Avoid Gated Clocks (SS10) Data signals should not be used in a logic path that drives the clock input of a register. rst_n) -. When allowed. END IF. -. .Gating mclk as clk_s P_PULSE_FF : PROCESS(clk_s. Disallowing clock gating is good safety-critical design best practice for synchronous digital designs. which can lead to incorrect data being registered. reset_n) BEGIN IF (reset_n = '0') THEN -. A design based on synchronous enabled registers should be used instead of gated clocks.Violation gated clock BEGIN IF (rst_n = '0') THEN pulse_r <= '0'.g.. 12. Default severity: Warning Example: ARCHITECTURE rtl OF top IS BEGIN U_and: gate port map (a => clk_master. See “Category: Clock Domain Crossings” for more information. --Isolated Clock Generator instance synch_PROC: PROCESS (clk_c. Avoid Internally Generated Resets (SS12) Unless they are properly isolated. EASA or RTCA / Eurocae related committees. . For synchronous digital designs. Internally generated resets should only be allowed throughout the design if they are at the top-level of the design hierarchy and properly isolated. violating set-up or hold time. due to default rule configuration is Disallowed. clock-trees. rst_master) BEGIN IF (rst_master = '0') THEN … ELSIF (rising_edge(clk_c)) THEN -– VIOLATION: Internally generated clock signal “clk_c” used to drive synchronous block “synch_PROC”. clock-domain crossing (CDC) analysis should be run to detect metastable design errors. global clock drivers and routing. b => enable. internally generated reset propagation delay variance. In FPGA targeted designs. If allowed. This avoids race condition problems when the reset signal is de-asserted too close to the active edge of the clock. and signals crossing clock-domains need careful consideration and handling. the potential for CDC and propagation delay variance induced errors can be mitigated by requiring these clock signals to be generated with the FPGA’s special purpose-built clock management circuitry. Should the project team (or company) wish to allow isolation at top-level. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. c => clk_c). each implementation must be justified and thoroughly documented. If internally generated clocks are allowed in a design. See the coding standard to flag “Avoid Asynchronous Reset Release” for additional information. they could change the setting or severity of this rule and it would not violate the example above. it is considered best practice to use asynchronous reset signals. internally-generated resets should be avoided. When allowed. This position paper does not represent an official position for the FAA. each implementation must be justified and thoroughly documented.11. due 22 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. In FPGA targeted designs. Clocks. Avoid Internally Generated Clocks (SS11) Internally generated clocks should be avoided. which are synchronously released. 23 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. END IF. END rtl. END IF. BEGIN PROCESS(clk) -.is internally generated IF rising_edge(clk) THEN IF (rst = '1') THEN rst_int <= '0'. END reset_module. PROCESS(clk) BEGIN IF rising_edge(clk) THEN -. Reset signals should be used consistently throughout the entire design. END PROCESS. ELSE rst_int <= in1. Avoid Mixed Polarity Reset (SS13) The same reset signal should not be used with mixed styles or polarities. in1: IN std_logic. ELSE out1 <= in1. . END PROCESS. out1:OUT std_logic).to routing differences. its justification should be documented.Associated Violation IF (rst_int = '1') THEN out1 <= '0'. This can be mitigated by generating the reset signals with the FPGA’s special purpose-built reset management circuitry. Applying a reset signal inconsistently can cause unintended circuit behaviors during the reset signal’s assertion and de-assertion when the designer does not fully comprehend the interactions between active circuit blocks and the reset blocks. END IF. This position paper does not represent an official position for the FAA. 13. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. rst: IN std_logic. Default severity: Warning Example: ENTITY reset_module IS PORT( clk: IN std_logic.Violation. This is important for a safety-critical program from a design IP reuse and comprehension aspect. EASA or RTCA / Eurocae related committees. global reset drivers and routing. can induce timing violations. END IF. If this is intentionally implemented in the design. ARCHITECTURE rtl OF reset_module IS SIGNAL rst_int: std_logic. rst_int BEGIN -. This position paper does not represent an official position for the FAA. 24 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group.g. Default severity: Warning Example: ARCHITECTURE rtl OF top IS BEGIN proc1: PROCESS(clk_master. inconsistent q <= '0'. . EASA or RTCA / Eurocae related committees. missing reset control BEGIN IF(reset = '1') THEN out2 <= (others => '0'). This system initiated error recovery command is used as the last resort recovery mechanism for a non-responsive device.reset polarities & style ELSE q <= d1.reset polarities & style ELSIF (falling_edge(clk_n)) THEN q <= d2. rst_master) BEGIN IF rising_edge(clk_master) THEN IF (rst_master = '1') THEN -. IF (rst_master = '0') THEN -. 14.Unintended design behavior can occur due to potential race conditions.Violation. -. END rtl.Violation for out3. END IF. END IF. -. Default severity: Warning Example: PROCESS (clk. END IF.. inconsistent q <= '0'. out3 <= in1. reset) –.Violation. synchronizer flops and scan-chains). This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. END PROCESS. the applicant should document and justify each exception. Note that multi-dimensional signals/register declarations modeled as memories should be exempt from this check. In these cases. END IF. ELSIF(rising_edge(clk)) THEN out2 <= in2. Avoid Unresettable Registers (SS14) All registers should have a reset control. There are occasional situations where the registers are not implemented with a reset control intentionally (e. All registers in the design should have an explicit reset of a specified type. A reset signal is used to help initialize a device into a predetermined condition. clk_n. Default severity: Error Example: library ieee. reset) –. missing reset control BEGIN IF(reset = '1') THEN 25 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. This may reflect actual design issues in-hardware. it is considered best practice to generate reset control as asynchronous assertion and synchronous de-assertion signal to avoid problems when the reset signal is de-asserted during the active edge of the clock. PROCESS (clk. use ieee. 16. Avoid Asynchronous Reset Release (SS15) Reset signals should have a synchronous release. Avoid Initialization Assignments (SS16) Do not use register initialization assignments. 15. For synchronous digital designs. This position paper does not represent an official position for the FAA. Default severity: Error Example: Note that the following figure demonstrates a correct on-chip reset scheme as described in the preceding text. .Violation for out3.std_logic_1164. to detect and evaluate the Xpropagation through the design. It is desirable to allow uninitialized signals to simulate as unknown. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. It is best practice to use an explicit reset to set a register to a value as opposed to using an initialization assignment in the port/signal declaration..END PROCESS. EASA or RTCA / Eurocae related committees.all. . However. Moreover. Dead code can be detrimental when a design is reused and the dead code is inadvertently activated during the code base port. EASA or RTCA / Eurocae related committees. 18. Default severity: Error Example: As seen from this figure. and consequently those registers are unused as well. out3 <= in1. and even computing environments. and other logic are simply dead code. END PROCESS.out2 <= (others => '0'). Every register and latch must be used and driven in the design. A state bit might 26 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. Unused registers. END IF. Registers and latches affecting only unused logic must be examined. ELSIF(rising_edge(clk)) THEN out2 <= in2. the other (blue) registers are used since they drive output Z and hence they should be allowed. This position paper does not represent an official position for the FAA. even though they also drive unused logic n1 and n2. release versions. b. Avoid Undriven and Unused Logic (SS17) a. latches. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Ensure Register Controllability (SS18) Each register should be controllable from its inputs. n1 and n2 are not used in the design and hence constitute unused logic violations. 17. the registers in red are only feeding nets that are unused. Dead code effects on safety-critical design assurance is not predictable nor insured to be consistent across different synthesis tools. All registers/latches (state bits) must be controlled from their inputs. It is difficult for timing optimizers to optimize the critical path of a design. taking into account logic propagation delays’ negative effect on the design’s timing requirements. which means that the register always drives a constant value. These situations can lead to inconsistent synthesis results.violation. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Default severity: Warning Example: flag_s <= (OTHERS => ’0’). Default severity: Warning 20. All of these aspects are important in a fail-safe design. The project team should determine the maximum levels of permissible user hierarchy level that a path can span. Avoid Snake Paths (SS19) Combinational paths should not exceed a maximum allowable logic depth.suffer from a dead-end value. EASA or RTCA / Eurocae related committees. which is desirable to insure that the code base will more likely implement a fully verifiable design that can also be modified quickly for design reuse and debugging. and should be broken at an appropriate point by inserting registers. a maximum limit for nesting depth for conditional branching constructs. mclk) BEGIN IF (rst_n = ’0’) THEN cmd_r <= (OTHERS => ’0’). ELSIF RISING_EDGE(mclk) THEN cmd_r <= request_in AND flag_s. Violations should be examined to see if 27 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. Any path longer than this should be reported as a violation. Long combinational paths. in addition to being more complex to debug and fix when an error has been found. and then check for. . This position paper does not represent an official position for the FAA. A state bit might also suffer from a stuck-at-fault. END PROCESS P_CMD_R. . END IF. Deeply nested conditional branching logic will tend to synthesize with longer propagation delay depths. The project teams should specify. can pose synthesis problems. . Ensure Nesting Limits (SS20) Conditional branching constructs should have a maximum nesting depth. which means that the bit drives a constant unless an asynchronous reset is applied. including resets. also called snake paths. The nesting limit can be set at the discretion of the project team. Controlling the nesting depth and format improves readability and reduces complexity. . -. if it spans multiple levels of hierarchy. stuck-at-0 fault 19. P_CMD_R : PROCESS(rst_n. irrespective of any changes to the inputs. Ensure Consistent Vector Order (SS21) Use the same multi-bit vector order consistently throughout the design. . the multi-bit vector order should be consistent throughout the design. IF in_two = '1'THEN out_two <= in_two. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. -. out_one <= '0'. But each of these violations should be examined and justification/assurance should be given that the issue is appropriately addressed in the design.. out_three <= '0'. ELSIF RISING_EDGE(clk) THEN IF in_one = '1' THEN out_one <= in_one. Bus_decending : IN std_logic_vector (0 T0 7). If the design requires the use of a logic implementation exceeding the maximum allowable nesting limit. 21. The vector range should consistently use either an ascending or descending order. Default severity: Warning Example: Bus_ascending : IN std_logic_vector (7 DOWNTO 0).. as 4th level out_three <= in_three.Violation if Descending order enabled Category: Design Reviews (DR) The following standards are checked to make design reviews and code comprehension easier.Violation if set to 3. This position paper does not represent an official position for the FAA. Default severity: Warning Example: FLIP_FLOP: PROCESS(rst.clk) BEGIN IF rst = '1' THEN qout <= '0'. then this violation and its impact study should be documented. In order to promote code comprehension and reduce potential interconnection errors. IF in_three = '1' THEN -.they are acceptable or require re-design. . EASA or RTCA / Eurocae related committees. out_two <= '0'. Note that violations often occur when a design uses reused code or IP. 28 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. Case Statements. However. Violating this coding standard will cause confusion regarding the design’s intention. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Default severity: Note Example: ARCHITECTURE flow OF top IS BEGIN -. 2. EASA or RTCA / Eurocae related committees. Labels should be added to the End constructs to assist with following the scope of the code. ARCHITECTURE flow OF top BEGIN Nrw <= ‘0’. Processes. Use Statement Labels (DR1) Statements should have labels. Do not allow mixing of case identifier “nrw” -. Ensure Unique Name Spaces (DR3) The same name should not be used for different types of identifiers. this should not be allowed. -. Note that this is different than mixed case naming for a single object.1.Violation. END top. It is a bad coding practice with respect to design comprehension for a safety-critical application.Identifiers “nrw” and “Nrw” are differentiated by case only END 3. Avoid Mixed Case Naming for Differentiation (DR2) Names should not be differentiated by case alone. and Initial Blocks should have labels to improve clarity for design code reviews and tracing during simulation. -. For example. This position paper does not represent an official position for the FAA. . Always Blocks. when design code uses the same name for two different objects. Port names having the same names as connected signals can 29 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. with the only difference being character case.Violation.Architecture concurrent statements data_out <= div_data WHEN clk_div_en = '1' ELSE ser_if_data. Concurrent statements should be labeled END flow. the same name should not be used to identify a signal in one part of the design but also used as a process label elsewhere. The same name is not used in different name spaces. Mixed case naming is sometimes preferred for clarity/readability. Default severity: Warning Example: ENTITY top IS PORT (nrw: OUT std_logic ). in2 : std_logic. Declarations are excluded unless there is a declaration on the same line as another statement. Default severity: Note Example: ARCHITECTURE spec OF status_registers IS SIGNAL xmitting_r. END spec. -. with each group of ports of the same mode (input. 4. the design could pass synthesis without any violation but its in-hardware functionally will not follow the HDL code’s intention.declarations should be on separate lines.declaration -. 5. done_xmitting_r : std_logic. At worst. Use Separate Declaration Style (DR4) Each declaration should be placed on a separate line. EASA or RTCA / Eurocae related committees. . Use Separate Statement Style (DR5) Each statement should be placed on a separate line. out1 <= in1 AND in2. Do not use identifier “i” since it exists in -. Multiple signals declared in one line.Identifier name “i” already used in another namespace BEGIN i := '1'. This position paper does not represent an official position for the FAA. -. out1 : OUT std_logic) is VARIABLE i : std_logic.another namespace within the same design PROCEDURE my_and (in1 : std_logic.Violation. -. violating this standard will cause confusion regarding the design’s intention. Default severity: Error Example: ARCHITECTURE rtl OF top IS SIGNAL i : std_logic.Violation. Thus declarations should be formatted with each on a separate line or. Having statements on separate lines ensures readability of the code. END PROCEDURE. Having declarations on separate lines dramatically improves code reviews and readability. in the case of ports. At best. 30 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. -. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. Note that the “begin” keyword can be removed from this check. output etc) on a separate line.be excluded. ENDIF. x2_s <= '0'. END IF. . tout_three <= '0'. Tabs should not be used. -. code should be consistently indented in terms of spaces and the number of indentation steps. -. IF in_two = '1' THEN tout_two <= in_two.clk) –.Violation.Default severity: Note Example: IF (en_i = '1') THEN x1_s <= NOT(a1_i). Avoid Using Tabs (DR7) Tabs should not be used. This position paper does not represent an official position for the FAA. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. x2_s <= a1_i. 7. Default severity: Note Example: FLOP_FLIP: PROCESS(rst. In order to promote readability of code between different editors. Ensure Consistent Indentation (DR6) Code should be consistently indented. Default severity: Warning 31 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group.Consistently formatted BEGIN IF rst = '1' THEN tout_one <= '0'. multiple statements 6. multiple statements ELSE x1s <= '0'. IF in_three = '1' THEN tout_three <= in_three. ENDIF.Violation. EASA or RTCA / Eurocae related committees. ENDIF. as they can result in problems when moving source code from one editing environment to another. ELSIF rising_edge(clk) THEN IF in_one = '1' THEN tout_one <= in_one. tout_two <= '0'. ENDIF. In order to promote code comprehension. The amount of design code inline commenting should allow a different designer to be able to understand the design well enough to be able to modify it for a different project in a reasonable amount of time. a design file should be of a limited size to promote better design partitioning. Default severity: Warning 11. This design check helps 32 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. Ensure Proper Placement of Comments (DR12) Comments should be placed in appropriate places to aid understanding. A brief summary of the code’s intention should be placed in the file header as well. organization. Enforce the placement of comments near (preferably above) code statements and code blocks to aid design code functionality understanding. Default severity: Warning 10. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. This position paper does not represent an official position for the FAA.e. EASA or RTCA / Eurocae related committees. legal briefing. In order to promote code comprehension and reduce potential interconnection errors. commenting) should be enforced. Default severity: Warning 12. a signal/bus should have a constant name when it spans across hierarchical levels. In order to promote code comprehension. The acceptable size should be at the discretion of the project team. Important information such as the code’s author. Ensure Consistent File Header (DR10) Ensure a consistent file header. Ensure Consistent Signal Names Across Hierarchy (DR9) Signals and busses should have consistent names when they span the design hierarchy. Default severity: Warning 9. . a minimum design code in-line documentation (i. Ensure Sufficient Comment Density (DR11) Code should be sufficiently documented via inline comments. This will help force the design structure into a more hierarchical partition away from a large flat code structure. a consistent file header comment style should be enforced through out the design project. statement of proprietary information. creation and modification dates. In order to promote code comprehension. Avoid Large Design Files (DR8) Designs should be partitioned and files should be of limited size. etc should be included if deemed appropriate.8.. registers. on-chip inputs use “_i” g. labels etc. and therefore cannot be explicitly included in a generic set of DO-254 coding standards. This section discusses the benefits. or even project to project. Benefits of Automated Checking First. generics. and issues (such at Tool Qualification) involved when using an automated means to check HDL coding standards. they should be considered and included in each company’s HDL coding standards. The sorts of things to consider include: • Having the component have the same name as the associated entity • Ensuring name association between formal and actual generics. processes use “_p” e. based on an organization’s digital 33 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. with a prefix or postfix appended to the object name. Default severity: Note 13. FSM State Variables. However. registers use “_r” c. on-chip outputs use “_o” i. signals. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects.to enforce stricter degrees of design code documentation/commenting for more complex language constructs usage. Ensure Company Specific Naming Standards (DR13) Each company or project should establish and enforce its own naming standards. processes. off-chip inputs use “_I” f. off-chip outputs use “_O” h. constants. signals use “_s” b. etc. Choose only one of these two methods (prefix vs. ports or parameters • Enforcing specific filename matching with associated entity • Enforcing specific object type naming convention. EASA or RTCA / Eurocae related committees. For example: a.0 Best Practice Usage of Automated HDL Standards Checking Tools can automate nearly all of the HDL standards presented in this paper. . This position paper does not represent an official position for the FAA. Consideration should be give to naming conventions for clocks. These standards will vary from company to company. postfix labels) and consistently apply it through out the entire design. resets. automation brings to the design checking process a standard metric for finding coding violations and weighing violation severities. Default severity: Note 7. constants use “_c” d. variables. Most standards can be automated with linting tools. . it should be used as early and often as possible. Machine based checking guided by an organization’s design standards ensures a consistent result. Becoming proficient with a HDL language for digital design requires using it in practice and learning from design as well as coding mistakes. a well written set of digital design coding guidelines keeps HDL based design mistakes from propagating in an organization and within a design flow. and then map them into the capabilities of a tool. it is nearly impossible to guarantee a consistent and error free design checking process based on manual code reviews. Thus. while others might not easily lend themselves to be machine checked. Add and delete additional standards from other packaged rule sets as well as from all available base rules. one of the coding guideline documents’ primary goal is to pass on best practice digital design knowledge to less experienced design engineers. a prepackaged rule set provides a quick and easy way to get started. even as designs grow in size. high cost is an issue in DO-254 programs. These refinements can be added back into the rule set and checking tool to constantly improve the design checking process over time. by leveraging tool automation capability. An automated design checking tool can also help as a digital design guidelines teaching tool when it is used in an interactive fashion during the initial design coding phase. Alternately. such as naming. and leveraging automation (when appropriate) is a way to bring down these costs. this can dramatically reduce the large man-hour labor cost from manual design code reviews. If a team does not have a set of coding guidelines. For large. With each design. Some of these can be automatically checked and enforced. Each company or project team may also have their own “style” standards as well. complex designs. Third. EASA or RTCA / Eurocae related committees.design coding guidelines. In this 34 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. if a company does not have a set of standard checks. A company should first define the standards they want to use. Additionally. Building the rule set. and so on. choose a wellconstructed. the more senior design engineers who typically oversee these design code reviews are now freed to concentrate on the more difficult tasks of correcting the design functionality and refining the design architecture. That is. Second. While this may not tie directly to design assurance. comments. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. indentations. automating HDL coding checks can assist in managing growing design complexity and size. Select appropriate built-in rules based on the defined standard requirements. while reducing design review cost and schedule impact as they are aligned to the organization’s standard HDL design coding guidelines. Use Model for Automated HDL Code Checking In order to get maximum use out of automated standards checking. This position paper does not represent an official position for the FAA. lessons are learned and improved practices are identified. pre-defined set and then modify the parameters and severity to meet the project style preferences and design assurance requirements. a design teams’ most valuable resources are used more effectively. Finally. However. Some violations may later be flagged as uncovered by code coverage metrics. run the checks again as well. a subset of the full coding standards can be used to verify the quality of the reused code. If reused code passes the safety-critical checks. Any time code is reused. check the quality of the previously-written code against the organization’s design coding standards. On the other hand. Oftentimes reused code was developed prior to an organization’s current set of coding standards. Many of the coding violations in HDL development would be caught later on in the process where they are tedious. With today’s level of automation. such as simulation and synthesis. many of these standards could be caught. as the automation does not replace the need for other aspects of code reviews. a designer can literally code a block of logic. and has a proven track record. Likewise. Each time the design code is integrated with other code into a larger design.regard. the tool used would have to go through tool assessment. supplement a packaged rule set with customizations and even some manual checks that must be examined during code reviews. For example. Manual code reviews to understand code intent can never be replaced. if reused code has numerous violations against safety-critical standards. and/or that any violations are examined to ensure they will not have any safety impact. The key is simply ensuring reused code does not violate any of the most critical/serious checks. Check during design. reused code is often taken from other projects where it may have proven usage. it should be fine to use. In the absence of a tool to automate the process. and press a button to check for any violations against the automatable coding standards. Others may be caught in simulation or other verification activities. the reuse potential may have to be reconsidered. and during this process. It could be possible to use an “independent output assessment” argument for tool assessment. some of these checks would be caught in downstream processes. if credit was taken for this activity via an automated tool. . Therefore. Thus. Downstream checks. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. EASA or RTCA / Eurocae related committees. This position paper does not represent an official position for the FAA. and costly to fix. Considerations for Tool Assessment Checking of HDL code against a set of standards via a review would be considered a verification activity in DO-254. reused code may often have violations of some of the newer standards. some violations may be caught at compile time. as coding standards tend to evolve and become more mature over time. a manual code review process would be followed. Check at integration. While others may be caught as bugs very late in the design process (or even in silicon). 35 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. For these cases. Check reused code. This allows him to clean up his code prior to integrating that code into the larger design. Note that because this is not a “functional” verification activity (in other words. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. This could be run by the applicant to demonstrate that the tool is indeed performing the standards checking correctly. including both good and bad code for each standard. These standards (or rules) can be used as-is by companies who don’t have their own standards and are seeking guidance. Mentor has implemented this set of checks as a predefined ruleset called “DO-254” which runs in the DesignChecker available in HDL Designer. credit taken for the automated code review activity should be assured. and enable debugging. it can improve the 36 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. If the set of standards the tool is checking is modified in any way. Using a tool to automate the checking of these coding standards is common practice. This ruleset can be run “as is” or modified as per a project’s specific needs. and run various tasks on an HDL project. For more information on using HDL Designer to run DO-254 rules checking.0 Summary Defining and checking HDL coding standards is a best practice that is generally accepted and employed by many companies today. As a result of their effort to lead the initiative to create this foundational set of DO-254 coding rules in the user group. explore. the tool checking HDL coding standards is not verifying that the design implementation meets its intended function as per requirements). a member of the DO-254 user group. a “best practice” set of foundational standards was presented in this paper. report resulting violations. visit www. a preferred method would be to conduct a basic tool qualification.” 9.4. In order to assist with this compliance objective. DesignChecker is a configurable design rule checker that can apply checks to HDL code. analyze. One key feature of HDL Designer is the DesignChecker. It is also a recent requirement imposed by DO254. This could consist of a document identifying the standards to be checked. 8. the set of tests run to demonstrate correct results would have to change accordingly. While automated checking cannot fully replace manual code reviews.mentor.com/go/do-254 and locate the paper entitled “Understanding and Running DO-254 Coding Checks in HDL Designer. . This position paper does not represent an official position for the FAA. as defined by DO254 § 11. this approach should be sufficient.0 The “DO-254” Ruleset in Mentor Graphics HDL Designer Tool Mentor Graphics. EASA or RTCA / Eurocae related committees. and an electronic design automation (EDA) company committed to aerospace and DO-254. Likewise this rule set can also be modified and augmented by companies wanting to do more or different types of checks. provides a tool called HDL Designer which is used to create.However. Using this approach. along with a set of test cases. This position paper does not represent an official position for the FAA. This document is provided for educational and informational purposes only and should be discussed with the appropriate certification authority when considering for actual projects. .efficiency of the design review process – helping meet compliance objectives more effectively. 37 NOTE: This position paper has been coordinated among representatives from the US and Europe DO-254 users group. EASA or RTCA / Eurocae related committees.