Best Practice VHDL Coding Standards for DO-254 Programs

DO-254 Users Group Position Paper DO254-UG-001 Best 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 BACKGROUND........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ..................... ....... 22 3.0 REFERENCES REFERENCES ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ....................... ......... 33 4.0 TERMINOLOGY TERMINOLOGY............................ .......................................... ............................ ............................ ............................ ........................... ........................... ............................ ................... ..... 33 5.0 INTRODUCTION INTRODUCTION ........................... ......................................... ............................ ............................ ............................ ........................... ........................... ............................ ................... ..... 33 6.0 SUGGESTED SUGGESTED CODING STANDARDS STANDARDS (RULES) ................... ................................. ............................ ............................ ............................ ................ .. 44

Category: Category: Coding Practices (CP) ..................................................... .................................................................................. .............................44 44 Category: Category: Clock Domain Crossing (CDC) ............................................................... 1414 Category: Category: Safe Synthe S ynthesis sis (SS) ........................................................................... .......1515 .......1515 Category: Category: Design Reviews (DR) .............................................................. ................2828 ................2828 7.0 BEST PRACTICE USAGE USA GE OF AUTOMATED HDL STANDARDS CHECKING CH ECKING ................... .......... ......... 3333

Benefits of Automated Checking ..................................................... .............................................................................. .........................3333 3333 Use Model for Automated HDL Code Checking ..................................................... 3434 Considerations 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 fro m 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 certific ation authority when considering for actual projects. This position paper does not represent an official position for the FAA, EASA or RTCA / Eurocae related committees .

Contents 1.0 PURPOSE ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ ................ ..

22

2.0 BACKGROUND BACKGROUND........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ..................... ....... 22 3.0 REFERENCES REFERENCES ........................... ......................................... ............................ ............................ ............................ ............................ ............................ ............................ ....................... ......... 33 4.0 TERMINOLOGY TERMINOLOGY............................ .......................................... ............................ ............................ ............................ ........................... ........................... ............................ ................... ..... 33 5.0 INTRODUCTION INTRODUCTION ........................... ......................................... ............................ ............................ ............................ ........................... ........................... ............................ ................... ..... 33 6.0 SUGGESTED SUGGESTED CODING STANDARDS STANDARDS (RULES) ................... ................................. ............................ ............................ ............................ ................ .. 44

Category: Category: Coding Practices (CP) ..................................................... .................................................................................. .............................44 44 Category: Category: Clock Domain Crossing (CDC) ............................................................... 1414 Category: Category: Safe Synthe S ynthesis sis (SS) ........................................................................... .......1515 .......1515 Category: Category: Design Reviews (DR) .............................................................. ................2828 ................2828 7.0 BEST PRACTICE USAGE USA GE OF AUTOMATED HDL STANDARDS CHECKING CH ECKING ................... .......... ......... 3333

Benefits of Automated Checking ..................................................... .............................................................................. .........................3333 3333 Use Model for Automated HDL Code Checking ..................................................... 3434 Considerations 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 fro m 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 certific ation 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 fro m 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 certific ation authority when considering for actual projects. This position paper does not represent an official position for the FAA, EASA or RTCA / Eurocae related committees .

This has led many applicants to ask for a good set of HDL coding standards. 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.0 References

a. RTCA/DO-254 (EUROCAE ED-80), Design Assurance Guidance For Airborne  Electronic Hardware; b. FAA AC 20-152, RTCA, Inc., Document RTCA/DO-254 c. FAA Order 8110.105 d. EASA Certification Memos and CRIs on recent programs (non public material) 4.0 Terminology

For this paper, the following terminology applies: HDL – Hardware Description Language. An HDL is any language from a class of  computer languages and/or programming languages for formal description of  electronic circuits, and more specifically, digital logic. It can describe the circuit's operation, its design and organization, and tests to verify its operation by means of simulation. Note that the coding standards shown in this document apply to HDL for use as a design language, not necessarily for verification testbenches. RTL – Register Transfer Level. In integrated circuit design, register transfer level (RTL) description is a way of describing the operation of a synchronous digital circuit. In RTL design, a circuit's behavior is defined in terms of the flow of  signals (or transfer of data) between hardware registers, and the logical operations performed on those signals. 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, from which technology specific implementations can be derived. VHDL – VHSIC Hardware Description Language; where VHSIC stands for “very-high-speed integrated circuit.” 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). 5.0 Introduction

HDL languages, such as VHDL, are very flexible. They allow extensive flexibility and creativity in coding. 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. By developing and following a good set of HDL coding standards, 3 NOTE: This position paper has been coordinated among representatives fro m 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 .

many potential problems can be caught early and addressed before they turn into bugs in a physical implementation. 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. From this collective experience and input, this paper provides a foundational set of standards that could be considered best practice coding guidelines for the VHDL language. 6.0 Suggested Coding Standards (Rules)

The following coding standards are suggested for VHDL synthesizable code for DO-254 projects. While the guidance of FAA Order 8110.105 states that HDL coding standards are required for DAL A/B devices, following these standards in general for all designs would be considered a best practice. Each coding standard listed hereafter falls under one of four categories. These categories are arbitrarily named, but each category serves a distinct purpose as described. The categories are 1) Coding Practices, 2) Clock Domain Crossings, 3) Safe Synthesis, and 4) Code Reviews. Each coding standard has a default severity level of Error, Warning, or Note, which provides a measure of the worst case impact a standard violation can have on safety. In general, errors should always be corrected, warnings should usually be corrected but may have documented and justified exceptions, and notes should simply be examined to ensure there is no impact on safe design operation. The standards and severity levels are potentially editable by the project team, depending on the design assurance level assigned to the design as well as the project team’s own coding style and preferences.  Note that in some cases, ensuring good HDL coding practice is only half of the solution. The other half lies with setting up the synthesis tool properly to ensure the intent of the HDL is properly synthesized. For example, both case statements and   finite state machines are prone to undesired synthesis optimizations, even if properly coded in HDL. These concerns are explained, where appropriate, in the coding rules descriptions that follow.

Category: Coding Practices (CP) This category of standards ensures that a coding style supporting safety-critical and good digital design practices are used. Each rule that follows is given a coding practice (CP) number for ease of reference.

4 NOTE: This position paper has been coordinated among representatives fro m 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 .

1. Avoid Incorrect VHDL Type Usage (CP1) Check for the incorrect use of types, incompatible bounds, and/or constraints. While these types of issues are usually caught during compilation, it is beneficial to correct the problem as early as possible. Default severity: Error Example: ENTITY top IS port (rf2fe_vec: IN dword); ARCHITECTURE rtl OF top IS signal tx_index: std_logic_vector (14 DOWNTO 0); …. tx_index