Best Practice VHDL Coding Standards for DO-254 Programs

38
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 DO- 254 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.

description

Best Practice VHDL Coding Standards for DO-254Programs

Transcript of Best Practice VHDL Coding Standards for DO-254 Programs

Page 1: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 1/38

 

DO-254 Users Group

Position PaperDO254-UG-001 

Best Practice VHDL Coding Standards for DO-254Programs 

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 DO-

254 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.

Page 2: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 2/38

 

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 theappropriate 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

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 

Page 3: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 3/38

 

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 theappropriate 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. 

2

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 companieshaving 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 generallyaccepted 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 foundationalset 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 thatmay 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 donemanually, an automated approach (when possible) guarantees a more consistent HDL

code quality assessment. Automating the HDL code assessment process, often calledlinting, has the added benefit of promoting regular HDL design checking steps

throughout the design development process, as opposed to waiting for gating designreviews 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. 

Page 4: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 4/38

 

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 theappropriate 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. 

3

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 alreadyhave 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 toHDL 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 digitalcircuit. 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 systemssuch 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 andcreativity 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,

Page 5: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 5/38

 

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 theappropriate 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. 

4

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 categoriesare arbitrarily named, but each category serves a distinct purpose as described. Thecategories 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 toensure there is no impact on safe design operation.

The standards and severity levels are potentially editable by the project team, dependingon 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.

Page 6: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 6/38

 

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 theappropriate 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. 

5

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 <= rf2fe_vec (f_txindex_hi DOWNTO f_txindex_lo);

-- Type error at ‘rf2fe_vec’. Needed type ‘std_logic_vector’ 

END rtl;

2.  Avoid Duplicate Signal Assignments (CP2) The same signal should not be assigned a value more than once within the same

statement region. 

A violation leads to a potential conflict on the signal assignment, and this may or maynot be flagged by the synthesis tool. 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. Default assignments (one occurrence) should be acceptable asindicated in the example below. This check ensures the designer will be warned

consistently during HDL design development, as opposed to waiting until synthesis,

which could have different results across different synthesis tools. It will also ensure

implementation of a more portable design IP review process.

Default severity: Warning

Example:same_signal <= '0'; -- Default assignment 

IF (reset = '1') THEN

same_signal <= '1'; -- This is NOT a duplicate assignment. 

END IF;

IF (reset = '1') THEN

-- Default Reset Values

beep <= '0';

-- more lines

beep <= '1'; -- Duplicate assignment maybe a mistake 

ELSIF (falling_edge(clk)) THEN

3.  Avoid Hard-Coded Numeric Values (CP3) For design IP reuse and portability ease, hard-coded numeric values should not be

Page 7: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 7/38

 

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 theappropriate 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. 

6

used.

Constants or generics should be used and documented within the design. 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.

Default severity: Warning

Example:PACKAGE dcc_pkg is

------------------------------------

-- constant declarations

------------------------------------

CONSTANT CPU_ADR_WIDTH : INTEGER := 16; -- cpu address bus width

CONSTANT CPU_DATA_WIDTH : INTEGER := 32; -- cpu data bus width

. . .

ENTITY dual_clock_cache_struct isPORT(

cpu_addr : IN std_logic_vector( 15 DOWNTO 0 ); -- violation 

cpu_di : IN std_logic_vector(CPU_DATA_WIDTH-1 DOWNTO 0); --32-bit

cpu_clk : IN std_logic;

4.  Avoid Hard-Coded Vector Assignment (CP4) For vector reset assignments; do not use hard-coded values. 

The reset assignment should be done in a way that is independent of the size of the

vector. This limits the impact of changing vector sizes and enhances design

portability ease.

Default severity: Note

Example:WHEN OTHERS =>

clk_div_en <= '0';

xmitdt_en <= '0';

ser_if_select <= "00000000"; -- Violation 

ser_in_select <= (OTHERS => ‘0’); -- This is preferred

5.  Ensure Consistent FSM State Encoding Style (CP5) a. A design should employ a consistent state encoding style for Finite State Machines

(FSM).

b.FSM state types should not be hard-coded, unless unavoidable.

Page 8: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 8/38

 

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 theappropriate 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. 

7

Inconsistent FSM encoding style may interfere with the design’s FSM error detection

and recovery scheme for the operating environment. Enumerated state types makeHDL code more readable generally. Enumerated types facilitate more flexibility in

the synthesis implementation as users can select the encoding style used (one-hot,

gray, binary etc.) without modifying the HDL code. These aspects support greater

design portability and insure FSM error detection and recovery.

Note that in general, care must be taken in designing state machines and each projectmust determine the FSM coding styles allowed. Considerations may include whether

one-hot encoding is allowed, whether TMR (Triple Modular Redundancy) is required,

how to minimize the number of bit-flips at state transitions, the error detection, errorisolation and recovery mechanisms to be employed, etc. When these decisions are

made, this rule ensures that the appropriate FSM style is consistently used throughout

the design. As an exception to this rule, some organizations’ coding guidelines may

enforce a hard coded FSM state definition to avoid unexpected synthesis results.

 Note that while this check of the HDL code is important, the synthesis tool must also be set up properly to implement the FSM state encoding consistently in the

targeted hardware. The synthesis tool control can be achieved through a pragma

in the code or via an external control file. Consult your synthesis tool vendor for 

more information.

Default severity: Error

Example:TYPE cpu_sm_state_type IS (

IDLE, -- reset & default state 

START_OP,

WRITE_DATA,DO_READ,

WAITMEM,

STALL_WAIT,

DO_RD -- Note, FSM states are encoded as enumerated type 

);

P_CPU_SM_NEXT_STATE : PROCESS( . . . )

BEGIN

CASE current_state_r is

WHEN IDLE =>

. . .

WHEN START_OP =>

. . .

WHEN “0011” => -- Violation, inconsistent state encoding 

. . .

END CASE;

END PROCESS P_CPU_SM_NEXT_STATE; 

Page 9: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 9/38

 

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 theappropriate 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. 

8

6.  Ensure Safe FSM Transitions (CP6)

a. An FSM should have a defined reset state.

b. All unused (illegal or undefined) states should transition to a defined state,

whereupon this error condition can be processed accordingly.

c. There should be no unreachable states (i.e., those without any incoming

transitions) and dead-end states (i.e., those without any outgoing transitions) in anFSM. 

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.

In general, memory logic, including FSM state registers, can change stateunpredictably due to supply-rail transients, ground bounces and SEUs (Single Event

Upsets). If the FSM design contains a fault condition detection and default error

recovery transition, then the transient event(s) inducing the invalid state will be

recoverable by way of a defined transition to a safe recovery state. Thus, it ispossible to check for improperly written HDL code that does not implement a fault-

tolerant FSM design at the RTL level.

 Note that while this check of the HDL code is important, the synthesis tool must 

also be set up properly to implement the safe FSM design consistently in the

targeted hardware. The synthesis tool control can be achieved via an external

control file. If the synthesis tool’s control options have not been properly

configured for safe FSM implementation, then it will remove the fault condition

detection and recovery logic during synthesis optimization. This will result in a

incorrect in-hardware logic implementation of the RTL code. Check with your 

synthesis tool vendor for more information.

It should be noted that some designs may have other well-defined schemes for faultcondition mitigation and recovery, and in those cases, this standard would be

modified or unnecessary.

Default severity: Error

Example:TYPE fsm_state_type IS (

IDLE, -- reset & default state 

START_OP,

WRITE_DATA,

DO_READ,

WAITMEM, -- wait for memory response 

STALL_WAIT, -- cpu stall 

DO_RD

-- AIS -- Commented out AIS state will cause violation 

);

. . .

CASE current_state IS

WHEN IDLE =>

Page 10: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 10/38

 

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 theappropriate 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. 

9

IF (rd_req=’1’ AND pre=’0’) THEN

next_state <= DO_RD;

. . .

WHEN DO_READ => -- Violation, no incoming transition 

next_state <= DO_RD; 

. . .

WHEN DO_RD =>

IF (pre=’1’) THEN

status <= WAITMEM; -- Violation, no outgoing transition 

WHEN OTHERS => -- Others, including error states 

next_state <= AIS; -- transition to the AIS state 

-- Violation, AIS is not a defined state

END CASE;

7.  Avoid Mismatching Ranges (CP7)  Bit widths on both sides of an assignment, comparison, or association should match. 

Mismatching range in an assignment, comparison, or association might result in logic

overflow errors.

Default severity: Warning

ExampleENTITY nonStatRange IS 

PORT (

in1 : IN std_logic_vector(31 DOWNTO 0);

in2 : IN std_logic_vector(31 DOWNTO 0);

sel1 : IN integer range 0 TO 15;

sel2 : IN integer range 0 TO 15;

out1 : OUT std_logic_vector(31 DOWNTO 0));

END;

ARCHITECTURE arch_nonStatRange OF nonStatRange is

BEGIN

sm_proc: PROCESS(in1, in2)

variable local_var1 : std_logic_vector (1 DOWNTO 0);

variable local_var2 : std_logic_vector (1 DOWNTO 0);

BEGIN

local_var1 := in1 (sel1 + 1 DOWNTO sel1); --This is not

--a violation, since the range is actually static although

--the left and right indices are not.

local_var2 := in2 (sel1 + sel2 DOWNTO sel1); -- Violation 

END PROCESS;

END;

8.  Ensure Complete Sensitivity List (CP8) The sensitivity list should only contain the signals needed by the process.  

The sensitivity list of a VHDL process should only include the required signals and

Page 11: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 11/38

 

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 theappropriate 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. 

10

does not include any unnecessary signals. The unused signals will slow down

simulation. Missing signals potentially lead to mismatching simulation versussynthesized hardware function. Existence of unused signals should be justified. 

Default severity: Warning

Example:RCV_CLOCKED_PROC : PROCESS (

clk,

-- rst, --Violation, signal needed in sensitivity list 

rcv_bit_cnt_cld --Violation, signal unnecessary 

--will cause process to be trigger more than needed. 

)

BEGIN

IF (rst = '0') THEN

rcv_current_state <= waiting;

ELSIF (falling_edge(clk)) THEN

rcv_current_state <= rcv_next_state;

CASE rcv_current_state IS

WHEN waiting =>

rcv_bit_cnt_cld <= "000";

IF (sin='0') THEN

rcv_bit_cnt_cld <= "001";

END IF;

WHEN incr_count2 =>

IF (sample='1' AND rcv_bit_cnt_cld /= "111") THEN

rcv_bit_cnt_cld <= unsigned(rcv_bit_cnt_cld) + 1;

END IF;

WHEN OTHERS =>

NULL;

END CASE;

END IF;

END PROCESS RCV_CLOCKED_PROC;

9.  Ensure Proper Sub-Program Body (CP9) 

 Each sub-program must:

a. have only one exit point 

b. have no recursion

c. access only local variables/signals 

Check for all these conditions in procedures, functions, and tasks. In some cases, if 

the code is intentionally designed this way (such as a recursive sub-program), its

 justification should be documented.

Default severity: Warning

Example:FUNCTION logicop (in1, in2 : IN bit_vector; c1, c2 : IN bit) RETURN

bit_vector IS

Page 12: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 12/38

 

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 theappropriate 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. 

11

 

BEGIN

IF(c1 = '1') THEN

RETURN (in1 OR in2); -- Violation, multiple exit points 

ELSIF(c2 = '1') AND (adr_mode = ‘1’) THEN

RETURN (in1 AND in2); -- Violation 

END IF;

END FUNCTION;

10. Assign Value Before Using (CP10)  Every object (e.g., signal, variable, port) should be assigned a value before using it. 

When objects are used before being defined, a latch may be inferred during synthesis,

which is most likely unintentional functional behavior for the design.

Default severity: Warning

Example:ENTITY fifo_bk_pressure IS

PORT(

-- Port Declarations

clk_ck2 : IN std_logic; -- GLOBAL: downstream clock 

rst_ck2_n : IN std_logic; -- GLOBAL: downstream reset(N) 

cntr_ck1_i : IN std_logic_vector(FIFO_CNTR-1 DOWNTO 0); -- 9-bit

-- Cut-and-paste error, should be cntr_ck2_i, results in violation

. . .

);

ARCHITECTURE rtl OF fifo_bk_pressure is

------------------------------------

-- register definitions

------------------------------------

signal full_threshold_r : fifo_cntr_type; -- 9-bit data type

. . .

threshold_proc: PROCESS(cntr_ck2_i, full_threshold_r)

BEGIN

assert_bk_pressure_s <= ‘0’;

. . .

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’;

END IF;

END PROCESS threshold_proc; 11. Avoid Unconnected Input Ports (CP11) 

 All input ports should be driven by a port, signal or constant value. 

Page 13: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 13/38

 

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 theappropriate 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. 

12

Input ports and bidirectional ports should be connected and not left floating.

Unconnected input ports can cause the associated circuit blocks to exhibit non-deterministic functional behavior in hardware, varying with changes in voltage-rails

and operating conditions.

Default severity: Error

Example:component usable_vhd

PORT (

in1 : IN std_logic ;

in2 : IN std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0);

out1 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0);

out2 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0)

);

. . .

U_bad: usable_vhd PORT MAP(

in1 => d,

out1 => q,out2 => q

);

-- VIOLATION. Unit bound to instance “U_bad” has an

-- unused input port “in2”, that should be

-- actively driven by another signal or fixed to ‘0’ or ‘1’ 

12. Avoid Unconnected Output Ports (CP12)  Design output ports should be connected. 

Output ports should usually be connected to an internal signal. However, in some

cases, such as with built-in self test (BIST) output signals used for debug, a floatingoutput is acceptable. In these cases, the violation should be justified and documented.

Default severity: Note

Example:component usable_vhd

PORT (

in1 : IN std_logic ;

in2 : IN std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0);

out1 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0);

out2 : OUT std_logic_vector(MEM_ADR_WIDTH-1 DOWNTO 0)

);

...

U_bad: usable_vhd PORT MAP (

in1 => d,

out1 => FLOAT,

out2 => q

);

Page 14: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 14/38

 

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 theappropriate 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. 

13

-- VIOLATION. Unit bound to instance “U_bad” has a

-- unconnected output port “out1” -- unused output port “out1”, that should be

-- actively driven by another signal or by fixed ‘0’ or ‘1’

13. Declare Objects Before Use (CP13) Objects should be declared before use. 

All objects used must be declared. Note: While this sort of error will be caught

downstream in compilation, it is useful to check for it as early as possible as it is avery common mistake that results in misinterpreted code.

Default severity: Error

Example:ENTITY top IS GENERIC (Speed: SpeedType := typical;….);

-- ‘SpeedType’ is an unknown type 

PORT(

. . .

); 

14. Avoid Unused Declarations (CP14)  All declared objects should be used. 

Check for objects that have been declared, but are never used (i.e., read from or

assigned to). Unused declared objects are considered dead code. Dead code can bedetrimental when a design is reused. The dead code could be inadvertently activated

during the code base port.

Default severity: Warning

Example:LIBRARY ieee;

USE ieee.std_logic_1164.all;

ENTITY unuseddecl IS

PORT (

in1 : IN std_logic_vector (3 DOWNTO 0);-- Violation

-- in1(3 DOWNTO 1)not used in RTL code

out1, -- Violation out1 not used in RTL code below,

out2 : OUT std_logic_vector(3 DOWNTO 0) -- Violation 

-- out2(2 DOWNTO 0) not used in RTL code);

END;

ARCHITECTURE unuseddecl_rtl OF unuseddecl IS

SIGNAL temp1, temp2 : std_logic;

BEGIN

Page 15: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 15/38

 

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 theappropriate 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. 

14

temp1 <= in1(0); -- Violation Signal 'temp1' is never used 

out2(3) <= temp2; -- Violation Signal 'temp2' is never assigned 

END;

Category: Clock Domain Crossing (CDC)

This set of standards addresses potential hazards with designs containing multiple clock 

zones and asynchronous clock zone transitions. 

1.  Analyze Multiple Asynchronous Clocks (CDC1)  Any time a design has multiple asynchronous clocks, or if internally-generated clocks

are allowed, a thorough clock domain crossing (CDC) analysis should be done.  

Improper clock domain crossings result in metastability or indeterminate circuitoperation, which can have serious adverse affects on a device’s operation. This design

guidance needs to be mentioned, even though clock domain crossing issues and

analysis is beyond the scope of typical HDL linting tools and beyond the scope of thisdocument.

As part of the design review process, all digital designs should be reviewed for

potential clock domain crossing boundaries, and, when found, analyzed to verify thatthey 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 atthe hardware level. It is often impossible to consistently duplicate these CDC-error-

induced behaviors in hardware for design debug. Making this situation worse, circuit

elements are affected by the operating conditions, such as loading, transistor junction

temperature, voltage rails and ground bounce. In a worst case scenario, a CDC errormight not exhibit itself during normal testing conditions, but it will occur during in-

field (i.e., in-flight) operating conditions given the right set of environmental factors

for the targeted system application.

For those interested in learning more about clock domain crossing issues and analysis

techniques, refer to:

•  2008 FAA SW and AEH presentation “Mitigating the Dangers of Multi-Clock Designs” (available here: http://www.mentor.com/products/fpga/do-

254/upload/multi-clock-designs.pdf  )

•  “Automating Clock-Domain Crossing Verification for DO-254 (and other Safety-

Critical) Designs” a whitepaper developed by Mentor Graphics (available here:http://www.mentor.com/products/fpga/do-254/techpubs )

Page 16: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 16/38

 

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 theappropriate 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. 

15

Category: Safe Synthesis (SS)

The following standards are checked to ensure a proper netlist is created by the synthesistool.

1.  Avoid Implied Logic (SS1) 

 Do not allow coding that implies feed-throughs, delay chains, and internal tri-statedrivers.

Certain coding styles that are dependent on implied synthesis constructs can be

dangerous. This implied logic might prevent the design code base from beingsynthesized in a consistent manner across different device technologies. This sort of 

implied logic includes feed-throughs, delay chains, and internal tri-state drivers.

Delay chains are two or more consecutive components with a single fan-in and singlefan-out, such as inverters. In some cases, such as tri-state assignments and small

width counters, this could be allowed and the applicant should document and justify

the warning in these cases.

Default severity: Warning

Example: SIGNAL mode : std_logic; -- Internal Tri-state Control

SIGNAL tri_bus : std_logic_vector (1 DOWNTO 0); -- Internal signal

-- (not top level port)

Tristate_Control: PROCESS (mode)

BEGIN

IF (mode = '0') THEN

tri_bus <= "0Z"; -- Do not allow internal tristates 

ELSE

tri_bus <= "Z0"; -- Do not allow internal tristates 

END IF;

END PROCESS Tristate_Control;

Example:ENTITY feed_through_ea IS

PORT(

a_i : IN std_logic;

av_i : IN std_logic_vector (10 DOWNTO 0);

x_o : OUT std_logic

);

END feed_through_ea;

ARCHITECTURE rtl OF feed_through_ea IS

BEGINx_o <= a_i; -- Violation, feed-through from input port “a_i” to

output port “x_o” 

Example:ENTITY delay_ea IS

GENERIC (ADR_WIDTH : INTEGER := 8);

Page 17: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 17/38

 

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 theappropriate 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. 

16

PORT(

adr_i : IN std_logic_vector(ADR_WIDTH-1 DOWNTO 0);

av_i : IN std_logic_vector(10 DOWNTO 0);

adrx_o : OUT std_logic_vector(ADR_WIDTH-1 DOWNTO 0)

);

END delay_ea;

ARCHITECTURE rtl OF delay_ea is

signal adr_inv1_s : std_logic_vector(ADR_WIDTH-1 DOWNTO 0);

signal adr_inv2_s : std_logic_vector(ADR_WIDTH-1 DOWNTO 0);

BEGIN

adr_inv1_s <= NOT(adr_i);

adr_inv2_s <= NOT(adr_inv1_s);

adrx_o <= adr_int2_s; -- Violation, delay chain from input port

“adr_i” to output port “adrx_o” 

2.  Ensure Proper Case Statement Specification (SS2) Case statements should:

a. Be complete

b. Never have duplicate/overlapping statements

c. 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.

Incomplete case statements will not synthesize in a predictable manner. Thus, when

this logic is driven by a non-predefined input pattern (e.g., during ground bouncecondition or SEU), its functional behavior will be dependent on the synthesis and

place-and-route tools’ optimization algorithm settings, the release version, and even

the computing environment used to execute the downstream tool runs. 

 Note that while this check of the HDL code is important, the synthesis tool must 

also be set up properly to implement fault-tolerant design consistently in the

targeted hardware. The synthesis tool control can be achieved through a pragma

in the code or via an external control file. Default severity: Error

Example:CASE addr IS

WHEN "000" =>

clk_div_en <= '1';WHEN "001" =>

clk_div_en <= '1';

WHEN "000" => -- Duplicate/overlapping case specification 

clk_div_en <= '1';

-- Incomplete case specification

WHEN "10X" => -- Not reachable case specification 

Page 18: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 18/38

 

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 theappropriate 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. 

17

xmitdt_en <= '1';

ser_if_select <= addr(1 DOWNTO 0);

WHEN "110" =>

ser_if_select <= addr(1 DOWNTO 0);

WHEN "111" => 

clr_int_en <= '1';

-- Missing WHEN OTHERS clause

END CASE;

3.  Avoid Combinational Feedback (SS3)  Do not allow reading and assigning to the same signal in the same combinational

 process. 

Such combinational feedback paths cause race conditions, making the design’s

functional behavior unpredictable. This design check could also be referred to as

“asynchronous feedback loops.”

Default severity: Error

Example:fred_s <= gated_in_s OR pulse_r; -- Violation combinational feedback

-- loop, at fred_s 

P_GATED_IN : PROCESS(

en_i,

fred_s,

pulse_r)

BEGIN

gated_in_s <= fred_s AND en_i;  -- Violation, async. feedback loop 

IF (en_i = '0') THEN

gated_in_s <= NOT(fred_s);  -- Violation, async. feedback loop 

ELSIF (pulse_r <= '1') THENgated_in_s <= '0';

END IF;

END PROCESS P_GATED_IN;

4.  Avoid Latch Inference (SS4) The HDL coding style should avoid inference of latches. 

Careful consideration should be given to the creation of latches in a design. In manycases latches may be introduced unintentionally, due to coding errors. The HDL

coding style should avoid inference of latches. While latches might simulate

properly, the synthesized hardware behavior may not match functional simulation.To avoid this problem, a good HDL coding practice is to write every IF-statement

ending with an ELSE to avoid unnecessary latches in the design, as a result of 

synthesis inference of the IF-statement functional behavior. This does not apply to theIF-statement for the clock. A non-used ELSE-statement should be declared with a

NULL.

Page 19: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 19/38

 

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 theappropriate 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. 

18

 

If a project decides not to allow any asynchronous design, this should be consideredan Error. However, if it is acceptable in certain cases, the severity should be

considered Warning, and the applicant should document and justify each case.

Default severity: Warning

Example:library ieee;

use ieee.std_logic_1164.all;

ENTITY vhdlatch IS

PORT (

in1, in2, in3, in4 : IN std_logic;

out1 : OUT std_logic;

out2 : OUT std_logic_vector(3 DOWNTO 0));

END;

ARCHITECTURE arch OF vhdlatch ISBEGIN

PROCESS (in1, in2, in3, in4) -- Violation

BEGIN

IF( in4 = '0') THEN

out2(3) <= in1;

out2(0) <= in2;

ELSE

out2 <= (others => in3);

END IF;

END PROCESS;

END;

5.  Avoid Multiple Waveforms (SS5) Only one waveform should exist on the right-hand side of a signal assignment.

A waveform consists of an assignment value expression and an optional assignment

delay expression. Multiple waveforms are non-synthesizable. With multiple

waveforms, synthesized hardware behavior will not match simulation.

Default severity: Error

Example:nRW <= '1' AFTER clk_prd, '0' AFTER 8 * clk_prd;

-- Violation, Only first waveform element used for synthesis

6.  Avoid Multiple Drivers (SS6) The same signal/variable should be assigned in only one sequential block.

Page 20: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 20/38

 

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 theappropriate 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. 

19

A signal/shared variable should not have multiple, simultaneously active drivers.

Multiply-driven signals can synthesize as “bucking drivers” in the hardwareimplementation and exhibit latent in-field failures of these circuits, which may

become permanent.

Default severity: Error

Example:library ieee;

use ieee.std_logic_1164.all;

ENTITY top IS

PORT(

a1, a2 : IN std_logic_vector(7 DOWNTO 0);

a3 : OUT std_logic_vector(7 DOWNTO 0));

END;

ARCHITECTURE rtl OF top IS

BEGINoperate_proc: PROCESS(a1)

BEGIN

a3 <= a1 and "10101000"; -- Violation 

END PROCESS;

test_proc: PROCESS(a2)

BEGIN

a3 <= a2; -- Associated Violation 

END PROCESS;

END rtl;

7.  Avoid Uninitialized VHDL Deferred Constants (SS7)  Ensure all VHDL deferred constants are initialized. 

A constant can be declared in a package without an initialization. The corresponding

package body should contain the initialization. Constants defined using this style are

called deferred constants. It is important to ensure that VHDL deferred constants doactually get initialized. When VHDL deferred constants are not initialized, they may

not be synthesizable.

Default severity: Warning

Example:PACKAGE trafficPackage IS

CONSTANT MaxTimerVal: integer

–- Violation. Deferred constant ‘MaxTimerVal’ without initial

-- value may not be synthesizable 

END trafficPackage;

Page 21: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 21/38

 

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 theappropriate 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. 

20

8.  Avoid Clock Used as Data (SS8) Clock signals should not be used in a logic path that drives the data input of a

register. 

Clock signals used as data can result in potential race conditions. This standard

would also be violated in the case where a clock signal happens to be a primaryoutput of the design (that is, output of the top design unit), since it can potentially be

used as data outside the design.

While synthesis engines should catch this issue, it may only be shown as a “warning”

in the synthesis environment, and therefore could easily be overlooked. Thus, therecommended severity is error. This ensures the issue is caught and addressed.

Default severity: Error

Example:P_GATED_IN : PROCESS(in1, mclk)

BEGIN

gated_in_s <= '0';

IF (in1 = TRANSITION) and (mclk = '0') THEN -- Associated Violation 

gated_in_s <= '1'; -- See below 

END IF;

END PROCESS P_GATED_IN;

P_PULSE_FF : PROCESS(mclk, rst_n) -- Violation clock used as data 

BEGIN -- Race condition can occur here 

IF (rst_n = '0') THEN

pulse_r <= '0';

ELSIF rising_edge(mclk) THEN

pulse_r <= gated_in_s;

END IF;END PROCESS P_PULSE_FF; 

9.  Avoid Shared Clock and Reset Signal (SS9) The same signal should not be used as both a clock and reset signal.  

Shared clock and reset functions for the same signal will cause race conditions in thedesign. In general, 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. Similarly, the reset signals should be coded in HDL in a clear manner toinsure that they are mapped onto dedicated reset routing resources. This will mitigate

potential timing violations due to different routing implementations and design codebase ports targeting a different device.

Default severity: Error

Page 22: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 22/38

 

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 theappropriate 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. 

21

Example:reset_n <= mclk AND en_i; -- reset_n signal has embedded clock 

P_FRED_R : PROCESS(mclk, reset_n)

BEGIN

IF (reset_n = '0') THEN -- Violation shared clock & reset signal 

fred_r <= '0';

ELSIF rising_edge(mclk) THEN

fred_r <= in1(DIR_BIT);

END IF;

END PROCESS P_FRED_R; 

10. Avoid Gated Clocks (SS10)  Data signals should not be used in a logic path that drives the clock input of a

register. 

Gated clocks can cause clock skews and are sensitive to glitches, due to propagation

delay and SET (Single Event Transient) effects, which can lead to incorrect data

being registered. Coding should be checked for the usage of gated clocks throughoutthe design. Disallowing clock gating is good safety-critical design best practice for

synchronous digital designs. A design based on synchronous enabled registers should

be used instead of gated clocks.

If the project’s standards determine it is never OK to use clock gating, then the

severity should be set to Error. However, the suggested severity is generally Warning

because in some cases (e.g., battery-power devices), clock gating is intentionallydesigned in to save power. When allowed, each implementation and justification

must be documented thoroughly. Careful consideration of potential adverse effects

when halting and starting up the associated circuit block(s) must be reviewed.Additionally, special consideration for the targeted FPGA device technology must be

taken into account. Clock gating designs for FPGA should not be allowed if the

targeted FPGA device does not contain special purpose-built clock gating circuitry insilicon.

Default severity: Warning

Example:clk_s <= mclk AND en_i; -- Gating mclk as clk_s 

P_PULSE_FF : PROCESS(clk_s, rst_n) -- Violation gated clock 

BEGIN

IF (rst_n = '0') THEN

pulse_r <= '0';

ELSIF rising_edge(clk_s) THEN

pulse_r <= in1(DIR_BIT);

END IF;

END PROCESS P_PULSE_FF;

Page 23: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 23/38

 

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 theappropriate 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. 

22

 

11. Avoid Internally Generated Clocks (SS11)  Internally generated clocks should be avoided.

Clocks, clock-trees, and signals crossing clock-domains need careful consideration

and handling. If internally generated clocks are allowed in a design, clock-domaincrossing (CDC) analysis should be run to detect metastable design errors. See

“Category: Clock Domain Crossings” for more information.

If allowed, each implementation must be justified and thoroughly documented. InFPGA targeted designs, 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, global clock driversand routing.

Default severity: Warning

Example:ARCHITECTURE rtl OF top IS

BEGIN

U_and: gate port map (a => clk_master, b => enable,

c => clk_c); --Isolated Clock Generator instance

synch_PROC: PROCESS (clk_c, 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”, due to default rule configuration is

Disallowed. Should the project team (or company) wish to allowisolation at top-level, they could change the setting or severity of

this rule and it would not violate the example above.

12. Avoid Internally Generated Resets (SS12) Unless they are properly isolated, internally-generated resets should be avoided.

Internally generated resets should only be allowed throughout the design if they are at

the top-level of the design hierarchy and properly isolated. For synchronous digital

designs, it is considered best practice to use asynchronous reset signals, which aresynchronously released. This avoids race condition problems when the reset signal is

de-asserted too close to the active edge of the clock, violating set-up or hold time.See the coding standard to flag “Avoid Asynchronous Reset Release” for additionalinformation.

When allowed, each implementation must be justified and thoroughly documented.In FPGA targeted designs, internally generated reset propagation delay variance, due

Page 24: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 24/38

 

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 theappropriate 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. 

23

to routing differences, can induce timing violations. This can be mitigated by

generating the reset signals with the FPGA’s special purpose-built reset managementcircuitry, global reset drivers and routing.

Default severity: Warning

Example:ENTITY reset_module IS

PORT(

clk: IN std_logic;

rst: IN std_logic;

in1: IN std_logic;

out1:OUT std_logic);

END reset_module;

ARCHITECTURE rtl OF reset_module IS

SIGNAL rst_int: std_logic;

BEGIN

PROCESS(clk) -- Violation, rst_int 

BEGIN -- is internally generated 

IF rising_edge(clk) THEN

IF (rst = '1') THEN

rst_int <= '0';

ELSE

rst_int <= in1;

END IF;

END IF;

END PROCESS;

PROCESS(clk)

BEGIN

IF rising_edge(clk) THEN

IF (rst_int = '1') THEN -- Associated Violation 

out1 <= '0';ELSE

out1 <= in1;

END IF;

END IF;

END PROCESS;

END rtl;

13. Avoid Mixed Polarity Reset (SS13) The same reset signal should not be used with mixed styles or polarities.

Reset signals should be used consistently throughout the entire design. This is

important for a safety-critical program from a design IP reuse and comprehension

aspect. Applying a reset signal inconsistently can cause unintended circuit behaviors

during the reset signal’s assertion and de-assertion when the designer does not fullycomprehend the interactions between active circuit blocks and the reset blocks. If this

is intentionally implemented in the design, its justification should be documented.

Page 25: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 25/38

 

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 theappropriate 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. 

24

Unintended design behavior can occur due to potential race conditions.

Default severity: Warning

Example:ARCHITECTURE rtl OF top IS

BEGIN

proc1: PROCESS(clk_master, clk_n, rst_master)

BEGIN

IF rising_edge(clk_master) THEN

IF (rst_master = '1') THEN -- Violation, inconsistent 

q <= '0'; -- reset polarities & style 

ELSE

q <= d1;

END IF;

END IF;

IF (rst_master = '0') THEN -- Violation, inconsistent 

q <= '0'; -- reset polarities & style 

ELSIF (falling_edge(clk_n)) THENq <= d2;

END IF;

END PROCESS;

END rtl;

14. Avoid Unresettable Registers (SS14)  All registers should have a reset control.

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. This system

initiated error recovery command is used as the last resort recovery mechanism for anon-responsive device.

There are occasional situations where the registers are not implemented with a reset

control intentionally (e.g., synchronizer flops and scan-chains). In these cases, the

applicant should document and justify each exception. Note that multi-dimensional

signals/register declarations modeled as memories should be exempt from this check.

Default severity: Warning

Example:PROCESS (clk, reset) –- Violation for out3, missing reset control BEGIN 

IF(reset = '1') THEN out2 <= (others => '0'); 

ELSIF(rising_edge(clk)) THEN 

out2 <= in2; out3 <= in1; 

END IF; 

Page 26: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 26/38

 

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 theappropriate 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. 

25

END PROCESS; 

15. Avoid Asynchronous Reset Release (SS15)  Reset signals should have a synchronous release. 

For synchronous digital designs, it is considered best practice to generate reset controlas asynchronous assertion and synchronous de-assertion signal to avoid problems

when the reset signal is de-asserted during the active edge of the clock..

Default severity: Error

Example:

Note that the following figure demonstrates a correct on-chip reset scheme as

described in the preceding text.

16. Avoid Initialization Assignments (SS16)  Do not use register initialization assignments. 

It is best practice to use an explicit reset to set a register to a value as opposed tousing an initialization assignment in the port/signal declaration. It is desirable to

allow uninitialized signals to simulate as unknown, to detect and evaluate the X-

propagation through the design. This may reflect actual design issues in-hardware.

Default severity: Error

Example:library ieee;

use ieee.std_logic_1164.all;

PROCESS (clk, reset) –- Violation for out3, missing reset control BEGIN 

IF(reset = '1') THEN 

Page 27: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 27/38

 

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 theappropriate 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. 

26

out2 <= (others => '0'); ELSIF(rising_edge(clk)) THEN 

out2 <= in2; out3 <= in1; 

END IF; END PROCESS; 

17. Avoid Undriven and Unused Logic (SS17) a. Every register and latch must be used and driven in the design.

b. Registers and latches affecting only unused logic must be examined.

Unused registers, latches, and other logic are simply dead code. Dead code can be

detrimental when a design is reused and the dead code is inadvertently activatedduring the code base port. Dead code effects on safety-critical design assurance is not

predictable nor insured to be consistent across different synthesis tools, release

versions, and even computing environments.

Default severity: Error

Example:

As seen from this figure, n1 and n2 are not used in the design and hence constitute

unused logic violations. Moreover, the registers in red are only feeding nets that are

unused, and consequently those registers are unused as well. However, the other(blue) registers are used since they drive output Z and hence they should be allowed,

even though they also drive unused logic n1 and n2.

18. Ensure Register Controllability (SS18)  Each register should be controllable from its inputs.

All registers/latches (state bits) must be controlled from their inputs. A state bit might

Page 28: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 28/38

 

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 theappropriate 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. 

27

suffer from a dead-end value, which means that the bit drives a constant unless an

asynchronous reset is applied. A state bit might also suffer from a stuck-at-fault,which means that the register always drives a constant value, irrespective of any

changes to the inputs, including resets. These situations can lead to inconsistent

synthesis results.

Default severity: Warning

Example:flag_s <= (OTHERS => ’0’);

. . .

P_CMD_R : PROCESS(rst_n, mclk)

BEGIN

IF (rst_n = ’0’) THEN

cmd_r <= (OTHERS => ’0’);

ELSIF RISING_EDGE(mclk) THEN

cmd_r <= request_in AND flag_s; -- violation, stuck-at-0 fault 

END IF;

END PROCESS P_CMD_R;

19. Avoid Snake Paths (SS19) Combinational paths should not exceed a maximum allowable logic depth.

It is difficult for timing optimizers to optimize the critical path of a design, if it spans

multiple levels of hierarchy. Long combinational paths, also called snake paths, can

pose synthesis problems. The project team should determine the maximum levels of permissible user hierarchy level that a path can span. Any path longer than this

should be reported as a violation, and should be broken at an appropriate point by

inserting registers.

Default severity: Warning

20. Ensure Nesting Limits (SS20) Conditional branching constructs should have a maximum nesting depth. 

Deeply nested conditional branching logic will tend to synthesize with longer

propagation delay depths, in addition to being more complex to debug and fix whenan error has been found. The project teams should specify, and then check for, a

maximum limit for nesting depth for conditional branching constructs. Controlling

the nesting depth and format improves readability and reduces complexity, which isdesirable 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. All of these

aspects are important in a fail-safe design. The nesting limit can be set at thediscretion of the project team, taking into account logic propagation delays’ negative

effect on the design’s timing requirements. Violations should be examined to see if 

Page 29: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 29/38

 

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 theappropriate 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. 

28

they are acceptable or require re-design.

If the design requires the use of a logic implementation exceeding the maximum

allowable nesting limit, then this violation and its impact study should be

documented.

Default severity: Warning

Example:FLIP_FLOP: PROCESS(rst,clk)

BEGIN

IF rst = '1' THEN

qout <= '0';

out_one <= '0';

out_two <= '0';

out_three <= '0';

ELSIF RISING_EDGE(clk) THEN

IF in_one = '1' THEN

out_one <= in_one;IF in_two = '1'THEN

out_two <= in_two;

IF in_three = '1' THEN -- Violation if set to 3, as 4th level 

out_three <= in_three;

...

21. Ensure Consistent Vector Order (SS21) Use the same multi-bit vector order consistently throughout the design.

In order to promote code comprehension and reduce potential interconnection errors,

the multi-bit vector order should be consistent throughout the design. The vectorrange should consistently use either an ascending or descending order. Note that

violations often occur when a design uses reused code or IP. But each of these

violations should be examined and justification/assurance should be given that theissue is appropriately addressed in the design.

Default severity: Warning

Example:Bus_ascending : IN std_logic_vector (7 DOWNTO 0);

Bus_decending : IN std_logic_vector (0 T0 7); -- Violation if

Descending order enabled

Category: Design Reviews (DR)The following standards are checked to make design reviews and code comprehension

easier.

Page 30: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 30/38

 

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 theappropriate 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. 

29

1.  Use Statement Labels (DR1) Statements should have labels.

Case Statements, Processes, Always Blocks, and Initial Blocks should have labels to

improve clarity for design code reviews and tracing during simulation. Labels should

be added to the End constructs to assist with following the scope of the code.

Default severity: Note

Example:ARCHITECTURE flow OF top IS

BEGIN

-- Architecture concurrent statements

data_out <= div_data WHEN clk_div_en = '1' ELSE ser_if_data;

-- Violation. Concurrent statements should be labeled

END flow;

2.  Avoid Mixed Case Naming for Differentiation (DR2)  Names should not be differentiated by case alone.

Note that this is different than mixed case naming for a single object. Mixed case

naming is sometimes preferred for clarity/readability. However, when design codeuses the same name for two different objects, with the only difference being character

case, this should not be allowed. Violating this coding standard will cause confusion

regarding the design’s intention. It is a bad coding practice with respect to designcomprehension for a safety-critical application.

Default severity: Warning

Example:ENTITY top IS

PORT (nrw: OUT std_logic );

END top;

ARCHITECTURE flow OF top

BEGIN

Nrw <= ‘0’;

-- Violation. Do not allow mixing of case identifier “nrw”

-- Identifiers “nrw” and “Nrw” are differentiated by case only

END

3.  Ensure Unique Name Spaces (DR3) The same name should not be used for different types of identifiers.

The same name is not used in different name spaces. For example, the same name

should not be used to identify a signal in one part of the design but also used as aprocess label elsewhere. Port names having the same names as connected signals can

Page 31: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 31/38

 

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 theappropriate 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. 

30

be excluded.

At best, violating this standard will cause confusion regarding the design’s intention.

At worst, the design could pass synthesis without any violation but its in-hardware

functionally will not follow the HDL code’s intention.

Default severity: Error

Example:ARCHITECTURE rtl OF top IS

SIGNAL i : std_logic;

-- Violation. Do not use identifier “i” since it exists in

-- another namespace within the same design

PROCEDURE my_and (in1 : std_logic; in2 : std_logic; out1 : OUT

std_logic) is

VARIABLE i : std_logic;

-- Identifier name “i” already used in another namespace 

BEGIN

i := '1';out1 <= in1 AND in2;

END PROCEDURE; 

4.  Use Separate Declaration Style (DR4)  Each declaration should be placed on a separate line.

Having declarations on separate lines dramatically improves code reviews and

readability. Thus declarations should be formatted with each on a separate line or, in

the case of ports, with each group of ports of the same mode (input, output etc) on aseparate line.

Default severity: Note

Example:ARCHITECTURE spec OF status_registers IS

SIGNAL xmitting_r, done_xmitting_r : std_logic; -- declaration 

-- Violation. Multiple signals declared in one line,

-- declarations should be on separate lines.

END spec; 

5.  Use Separate Statement Style (DR5) 

 Each statement should be placed on a separate line.

Having statements on separate lines ensures readability of the code. Declarations areexcluded unless there is a declaration on the same line as another statement. Note

that the “begin” keyword can be removed from this check.

Page 32: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 32/38

 

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 theappropriate 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. 

31

Default severity: Note

Example:IF (en_i = '1') THEN

x1_s <= NOT(a1_i); x2_s <= a1_i; -- Violation, multiple statements 

ELSE

x1s <= '0'; x2_s <= '0';  -- Violation, multiple statements 

END IF;

6.  Ensure Consistent Indentation (DR6) Code should be consistently indented.

In order to promote readability of code between different editors, code should be

consistently indented in terms of spaces and the number of indentation steps.

Default severity: Note

Example:FLOP_FLIP: PROCESS(rst,clk) –- Consistently formatted

BEGIN

IF rst = '1' THEN

tout_one <= '0';

tout_two <= '0';

tout_three <= '0';

ELSIF rising_edge(clk) THEN

IF in_one = '1' THEN

tout_one <= in_one;

IF in_two = '1' THEN

tout_two <= in_two;IF in_three = '1' THEN

tout_three <= in_three;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

7.  Avoid Using Tabs (DR7)Tabs should not be used.

Tabs should not be used, as they can result in problems when moving source code

from one editing environment to another.

Default severity: Warning

Page 33: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 33/38

 

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 theappropriate 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. 

32

8.  Avoid Large Design Files (DR8)  Designs should be partitioned and files should be of limited size.

In order to promote code comprehension, a design file should be of a limited size to

promote better design partitioning. This will help force the design structure into a

more hierarchical partition away from a large flat code structure. The acceptable sizeshould be at the discretion of the project team.

Default severity: Warning

9.  Ensure Consistent Signal Names Across Hierarchy (DR9) Signals and busses should have consistent names when they span the design

hierarchy.

In order to promote code comprehension and reduce potential interconnection errors,a signal/bus should have a constant name when it spans across hierarchical levels.

Default severity: Warning

10. Ensure Consistent File Header (DR10)  Ensure a consistent file header.

In order to promote code comprehension, a consistent file header comment style

should be enforced through out the design project. Important information such as thecode’s author, organization, creation and modification dates, legal briefing, statement

of proprietary information, etc should be included if deemed appropriate. A brief 

summary of the code’s intention should be placed in the file header as well.

Default severity: Warning

11. Ensure Sufficient Comment Density (DR11) Code should be sufficiently documented via inline comments.

In order to promote code comprehension, a minimum design code in-line

documentation (i.e., commenting) should be enforced. The amount of design code in-

line commenting should allow a different designer to be able to understand the designwell enough to be able to modify it for a different project in a reasonable amount of 

time.

Default severity: Warning

12. Ensure Proper Placement of Comments (DR12) Comments should be placed in appropriate places to aid understanding.

Enforce the placement of comments near (preferably above) code statements and

code blocks to aid design code functionality understanding. This design check helps

Page 34: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 34/38

 

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 theappropriate 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. 

33

to enforce stricter degrees of design code documentation/commenting for more

complex language constructs usage.

Default severity: Note

13. Ensure Company Specific Naming Standards (DR13)  Each company or project should establish and enforce its own naming standards.

These standards will vary from company to company, or even project to project, and

therefore cannot be explicitly included in a generic set of DO-254 coding standards.However, 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, ports orparameters

•  Enforcing specific filename matching with associated entity

• Enforcing specific object type naming convention, with a prefix or postfixappended to the object name. Choose only one of these two methods (prefix

vs. postfix labels) and consistently apply it through out the entire design.Consideration should be give to naming conventions for clocks, resets,

signals, constants, variables, registers, FSM State Variables, generics, labels

etc. For example:a.  signals use “_s”

b.  registers use “_r”

c.  constants use “_c”d.  processes use “_p”e.  off-chip inputs use “_I”

f. 

on-chip inputs use “_i”g.  off-chip outputs use “_O”h.  on-chip outputs use “_o”

i.  etc.

Default severity: Note

7.0 Best Practice Usage of Automated HDL Standards Checking

Tools can automate nearly all of the HDL standards presented in this paper. This section

discusses the benefits, processes, and issues (such at Tool Qualification) involved when

using an automated means to check HDL coding standards.

Benefits of Automated Checking

First, automation brings to the design checking process a standard metric for findingcoding violations and weighing violation severities, based on an organization’s digital

Page 35: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 35/38

 

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 theappropriate 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. 

34

design coding guidelines. If a team does not have a set of coding guidelines, a pre-

packaged rule set provides a quick and easy way to get started.

Second, by leveraging tool automation capability, this can dramatically reduce the large

man-hour labor cost from manual design code reviews. Additionally, the more senior

design engineers who typically oversee these design code reviews are now freed toconcentrate on the more difficult tasks of correcting the design functionality and refining

the design architecture. Thus, a design teams’ most valuable resources are used moreeffectively, while reducing design review cost and schedule impact as they are aligned to

the organization’s standard HDL design coding guidelines. While this may not tie

directly to design assurance, high cost is an issue in DO-254 programs, and leveragingautomation (when appropriate) is a way to bring down these costs.

Third, a well written set of digital design coding guidelines keeps HDL based design

mistakes from propagating in an organization and within a design flow. That is, one of the coding guideline documents’ primary goal is to pass on best practice digital design

knowledge to less experienced design engineers. Becoming proficient with a HDLlanguage for digital design requires using it in practice and learning from design as wellas coding mistakes. 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. With each design, lessons are learned and improved practices areidentified. These refinements can be added back into the rule set and checking tool to

constantly improve the design checking process over time.

Finally, automating HDL coding checks can assist in managing growing designcomplexity and size. For large, complex designs, it is nearly impossible to guarantee a

consistent and error free design checking process based on manual code reviews.

Machine based checking guided by an organization’s design standards ensures aconsistent result, even as designs grow in size.

Use Model for Automated HDL Code CheckingIn order to get maximum use out of automated standards checking, it should be used as

early and often as possible.

Building the rule set. Most standards can be automated with linting tools. A companyshould first define the standards they want to use, and then map them into the capabilities

of a tool. Alternately, if a company does not have a set of standard checks, choose a well-

constructed, pre-defined set and then modify the parameters and severity to meet theproject style preferences and design assurance requirements. Select appropriate built-in

rules based on the defined standard requirements. Add and delete additional standards

from other packaged rule sets as well as from all available base rules. Each company orproject team may also have their own “style” standards as well, such as naming,

indentations, comments, and so on. Some of these can be automatically checked and

enforced, while others might not easily lend themselves to be machine checked. In this

Page 36: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 36/38

 

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 theappropriate 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. 

35

regard, supplement a packaged rule set with customizations and even some manual

checks that must be examined during code reviews. 

Check during design. With today’s level of automation, a designer can literally code a

block of logic, and press a button to check for any violations against the automatable

coding standards. This allows him to clean up his code prior to integrating that code intothe larger design.

Check at integration. Each time the design code is integrated with other code into a

larger design, run the checks again as well.

Check reused code. Any time code is reused, check the quality of the previously-written

code against the organization’s design coding standards. Oftentimes reused code was

developed prior to an organization’s current set of coding standards, as coding standards

tend to evolve and become more mature over time. Thus, reused code may often haveviolations of some of the newer standards. However, reused code is often taken from

other projects where it may have proven usage. The key is simply ensuring reused codedoes not violate any of the most critical/serious checks, and/or that any violations areexamined to ensure they will not have any safety impact. For these cases, 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, and has a proven track record, it should be fine to use.On the other hand, if reused code has numerous violations against safety-critical

standards, the reuse potential may have to be reconsidered.

Downstream checks. Many of the coding violations in HDL development would becaught later on in the process where they are tedious, and costly to fix. For example,

some violations may be caught at compile time. Others may be caught in simulation or

other verification activities. Some violations may later be flagged as uncovered by codecoverage metrics. While others may be caught as bugs very late in the design process (or

even in silicon).

Considerations for Tool AssessmentChecking of HDL code against a set of standards via a review would be considered a

verification activity in DO-254. Therefore, if credit was taken for this activity via an

automated tool, the tool used would have to go through tool assessment.

It could be possible to use an “independent output assessment” argument for tool

assessment, as the automation does not replace the need for other aspects of codereviews. Manual code reviews to understand code intent can never be replaced, and

during this process, many of these standards could be caught. Likewise, some of these

checks would be caught in downstream processes, such as simulation and synthesis. Inthe absence of a tool to automate the process, a manual code review process would be

followed.

Page 37: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 37/38

 

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 theappropriate 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. 

36

However, a preferred method would be to conduct a basic tool qualification, as defined

by DO254 § 11.4. This could consist of a document identifying the standards to bechecked, along with a set of test cases, including both good and bad code for each

standard. This could be run by the applicant to demonstrate that the tool is indeed

performing the standards checking correctly. If the set of standards the tool is checking is

modified in any way, the set of tests run to demonstrate correct results would have tochange accordingly. Using this approach, credit taken for the automated code review

activity should be assured.

Note that because this is not a “functional” verification activity (in other words, the tool

checking HDL coding standards is not verifying that the design implementation meets itsintended function as per requirements), this approach should be sufficient.

8.0 The “DO-254” Ruleset in Mentor Graphics HDL Designer Tool

Mentor Graphics, a member of the DO-254 user group, and an electronic designautomation (EDA) company committed to aerospace and DO-254, provides a tool called

HDL Designer which is used to create, explore, analyze, and run various tasks on anHDL project. One key feature of HDL Designer is the DesignChecker. DesignChecker isa configurable design rule checker that can apply checks to HDL code, report resulting

violations, and enable debugging.

As a result of their effort to lead the initiative to create this foundational set of DO-254

coding rules in the user group, Mentor has implemented this set of checks as a pre-

defined ruleset called “DO-254” which runs in the DesignChecker available in HDL

Designer. This ruleset can be run “as is” or modified as per a project’s specific needs.

For more information on using HDL Designer to run DO-254 rules checking, visit

www.mentor.com/go/do-254 and locate the paper entitled “Understanding and RunningDO-254 Coding Checks in HDL Designer.”

9.0 Summary

Defining and checking HDL coding standards is a best practice that is generally accepted

and employed by many companies today. It is also a recent requirement imposed by DO-

254.

In order to assist with this compliance objective, a “best practice” set of foundational

standards was presented in this paper. These standards (or rules) can be used as-is bycompanies who don’t have their own standards and are seeking guidance. Likewise this

rule set can also be modified and augmented by companies wanting to do more or

different types of checks.

Using a tool to automate the checking of these coding standards is common practice.

While automated checking cannot fully replace manual code reviews, it can improve the

Page 38: Best Practice VHDL Coding Standards for DO-254  Programs

7/15/2019 Best Practice VHDL Coding Standards for DO-254 Programs

http://slidepdf.com/reader/full/best-practice-vhdl-coding-standards-for-do-254-programs 38/38

  37

efficiency of the design review process – helping meet compliance objectives more

effectively.