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) has following number for ease of reference.
1)

Clock Domain Crossing (CDC):

This set of standards addresses potential hazards with designs containing multiple clock zones and asynchronous clock zone transitions. 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.

2)

Static Timing Analysis (STA):

Static Timing Analysis is a method for determining if a circuit meets timing constraints without having to simulate. STA approach typically takes a fraction of the time it takes to run logic simulation on a large design and guarantees 100% coverage of all true timing paths in the design without having to generate test vectors.
3) Safe

Synthesis (SS):

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

Synthesis optimization algorithms are geared towards synchronous designs. Unexpected synthesis gate level output can occur if the design is extremely asynchronous.
4)

Design Reviews (DR):

The following standards are checked to make design reviews and code comprehension easier i.e. should be source level Transparent, Verifiable, maintainable and readable and include those attributes of the software that facilitates the understanding of the software by project personnel.

5) Should have a formal syntax and be amenable to static analysis

1. Do not use flip-flop output as a clock(Rationale 1& 2)

Problem Description Do not use a flip-flop output as a clock - avoid internally generated clocks as much as possible unless they are isolated properly.
Example

Flip-flop "div_4.ff_0.q" output is used as data for the flip-flop "div_4.ff_1.q" => violation. library IEEE; Use IEEE.std_logic_1164.all; entity ff is port ( clk : in std_logic; ff_output : out std_logic ); end entity; architecture arch_ff of ff is signal q: std_logic; begin process (clk) begin if (clk'event and clk = '1') then q <= not q; end if; end process; ff_output <= q; end architecture;

2. Do not connect clocks to anything other than flip-flop clock pins. (Rationale 1& 2)

A clock signal should not be connected to latches, enable logic of multiplexers and tristates, and flip-flop pins other than clock pin. Such descriptions infer internally generated clocks that are not recommended. Global clock(s) connections are verified throughout the design: flip-flop clock pin: flip-flop: data, enable, sync. and async. controls - not allowed, clock - allowed; latch: data sync. and async. Controls - not allowed, enable - alllowed; multiplexer: select - not allowed, data inputs - allowed; tri-state: enable - not allowed, data - allowed.
Example 1

The global clock signal "clk" is connected to the select input of the multiplexer => violation.

3. Do not use combinatorial logic in reset lines(Rationale 1& 2)

Problem Description Combinatorial logic in a reset line may generate hazardous reset signal. Avoid internally generated resets and use the global resets only to feed the flip-flop asynchronous control pins. If combinatorial logic is really needed in the reset line it is recommended to explicitly group it explicitly in the hierarchically separated design unit (create the reset generator instance). . Example combinatorial logic is present on the reset line of "output" flip-flop => violation.

4. Do not use the same signal as clock and reset (Rationale 1& 2)

Problem Description Do not use the same signal both as a clock and reset. Clock-reset mixing is very hazardous practice that should be avoided as much as possible. both as clock and reset (details point to the appropriate flip-flops pins). Example

The "FF_VECTOR.clk" signal is connected both to reset pin of "FF_VECTOR.low_ff.output" flip-flop and clock pin of "FF_VECTOR.high_ff.output" flipflop => violation.

Declarations
Correct usage of VHDL data types

5. Use the 'std_logic_1164' standard package whenever it is possible. (Rationale 4 & 5)

Problem Description The 'std_logic' and 'std_logic_vector' are standard types that are required for RTL design. It is recommended to use "ieee.std_logic_1164" whenever it is possible. Example 1 The entity "FDCPE" doesn't use the standard package "std_logic_1164" => violation.

6. Do not use unsafe data types inside architecture(Rationale 4 & 5)

Problem Description

Data types used inside architecture are not subject for such strict rules as an interface port data types. Only the following types above the 'std_logic' are safe though: 'integer', 'Boolean', 'unsigned, signed' and user-defined data types based on these types. Example The forbidden "bit_vector" datatype is used for the internal "data" signal => violation. Note: there is another checker with stricter requirements for entity data types

7. Specify range for objects of 'integer' data type(Rationale 2 & 4)

Problem Description If range is not specified explicitly, an object of 'integer' data type is treated as 32-bit value and this may lead to redundant circuit generation in certain cases. Range specification is required in 'integer' object declarations. The only exception to this rule is generic clause. Example Range specification is missing in the signal "shift" declaration => violation.

8. Do not use the 'bit' data type (Rationale 4 & 5)

Problem Description Objects of the 'bit' and 'bit_vector' data types can be assigned only with '1' and '0', This may block simulation-time 'x'-es propagation. The 'std_logic' and 'std_logic_vector' data types should be used instead to ensure that related bugs are not missed. Example The forbidden type "bit" is used in the "and_4" entity port map => violation.

9. Do not use the 'enum_encoding' attribute for enumerations(Rationale 4)

Problem Description The 'enum_encoding' attribute is used to define the encoding scheme of a state machine in the design. Do not use this attribute to prevent the particular logic synthesis. Example The 'enum_encoding' attribute is specified for the "FSM_states" type => violation.

10. Specify range for interface objects of 'std_logic_vector' data type. (Rationale 4 & 5)
Problem Description If range is not specified explicitly, an object of 'std_logic_vector' data type is treated as unconstrained value and this may lead to mismatches between the RTL and postsynthesis simulation. Range specification is always required in port and generic declarations of 'std_logic_vector' data type. Example Unconstrained 'std_logic_vector' data type is used for entity "mux" ports => violation.

11. Do not use ordered port connections(Rationale 4 & 5)

Problem Description Ordered port connections should not be used in component instantiations. The probability to make a mistake is much higher when relying on ordered connections. Use named connections to explicitly show bindings between ports and signals. Example 1 Ordered port connection is used in the component "u_and_2" port map => violation.

Racing conditions

Hazardous clock connections 12. Do not use a clock signal as a data(Rationale 2 & 4)
Problem Description A clock signal should not be used as a data. This approach helps to prevent racing issues. . Example The clock signal "clk" is connected to the flip-flop "count(0)" data input => violation.

13. Match bit widths of relational operator arguments(Rationale 4)

Problem Description

Bit widths of relational operator arguments should match clearly. This approach prevents important mistakes (incorrect conditional branch may be executed). . Example Ports "operand1" and "operand2" with mismatching bit width are used as operands of relational operator =>violation.

14. Define all the necessary signals in the sensitivity list of a combinatorial in process (Rationale 4)
Problem Description A sensitivity list should include all the signals that are referenced within a combinatorial process. This approach prevents differences between the results of RTL and postsynthesis simulation. Example The signal "data" is read but not included in the sensitivity list => violation.

15. Do not define unnecessary objects in the sensitivity list of a combinatorial process (Rationale 4)
Problem Description A sensitivity list should not include any unnecessary objects. Redundant objects may result in unexpected process executions during the simulation. Example The signal "q" is an intermediate signal -- it is not needed in the sensitivity list => violation.

16. Do not use a signal within the same process statement it was assigned(Rationale 2 & 4)
Problem Description A code that contains a signal assigned and referenced within the same process statement is inefficient in simulation. Also the readability of such code is reduced. So do not use a signal within the same process statement it was assigned. NOTE: Variables are not considered. Example 1 The "sel" is both assigned and referenced within the same process => violation.

17. Do not read global signals in a function body(Rationale 4).

Problem Description Global signals should not be used within a function body. A function that reads a global signal does not operate when this signal changes - resulting circuit may not operate as

expected. All signals that are used within a function body should be input arguments of this function. Example The function "func_shift" refers to the global signal "shl_or_shr " => violation.

Unsafe return value description 18. A function should return at the end of its body(Rationale 4).
Problem Description Do not define a function return value anywhere else than at the end of the function body - it is recommended to use intermediate variable to calculate the results and return this variable. Also do not place any statements after the return - they won't be executed. Example 1 The function "comparision" does contain a 'return' statement => violation.

19. Function should not return in conditional branches(Rationale 4)

Problem Description Do not define function return value under control of conditional branches - such descriptions are hazardous - use intermediate variable to calculate the results and define function return value at the end on the function body. . Example The function "comparision" contains return statement in the conditional branch => violation.

20. Avoid incorrect VHDL type usage(Rationale 4)

Problem Description 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. Example: 21. Avoid Unconnected Input Ports(Rationale 2 & 4) Problem Description Input ports and bidirectional ports should be connected and not left floating. Unconnected input ports can cause the associated circuit blocks to exhibit nondeterministic functional behavior in hardware, varying with changes in voltage-rails and operating conditions.

2. Design reviews

The following standards are checked to make design reviews and code comprehension easier.

Namespaces 1. Do not describe same objects using both upper and lower letter case Rationale 4).
Problem Description The same signal names should not be described using both upper case and lower case English letters. It is even advised to avoid having similar names for the signals in different visibility regions. English letters in upper and lower case are not distinguished in VHDL but in many systems at subsequent stages, such signals are recognized as different, are distinguished signals which may cause a problem (e.g. Abc and abc). Example The input signal "Read_Addr" is referred to as "read_addr" (first letters are not capitalized) => violation.

2. Do not describe multiple statements in one line (Rationale 4)

Problem Description Each assignment should be located in a separate line - the same approach is recommended for other statements. Multiple statements in one line make description hard to read and understand.

3. Ensure company specific Naming standards (Rationale 4)

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 companys 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 or parameters Enforcing specific filename matching with associated entity Enforcing specific object type naming convention, with a prefix or postfix appended 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.

3. Safe synthesis
The following standards are checked to ensure a proper net list is created by the synthesis tool.

Multiple waveforms (VHDL only) 1. Do not use multiple waveform and optional delay expression in assignments (Rationale 2 & 4)
Problem Description Multiple waveforms are not synthesizable and should not be used, simple assignments only should be used in RTL description. Example The multiple waveform is assigned to the "data_out" signal => violation.

Conditional statement
Case overlapping and completeness 2. Case statement should always have 'others' choice.
Problem Description The 'others' choice should always be added. This approach prevents the situation when nothing is executed and ensures optimal synthesis results. Example The 'others' choice is missing in the case statement => violation.

General issues
1. Do not describe unreachable conditions(Rationale 4) Problem Description
Code that will never be executed should be removed from description. Unreachable conditions are prone to mistakes and usually are the source of further confusion. Example

Branches with "x < y" and "x > y" conditions are not reachable => violation.

Implied logic
Allowed implied logic

3. Do not connect in out directly to input or output (Rationale 4)

Problem Description Direct connections of inout to input or output ports imply generation of paths that have not been described in the RTL. Tri-state buffers should be inserted to correctly communicate with the 'inout' ports. Example The "data_left" inout port is directly connected to the "output_data_right" output port => violation.

Race conditions
Combinatorial feedback
4. Do not use combinatorial feedbacks(Rationale 2 & 4)
Problem Description Combinatorial feedbacks should be avoided as much as possible in the design. They cause number of problems - including racing conditions and problems with timing analysis. Example Combinational feedback is detected (feedback propagation chain is as following: "q_back" -> "nq_back" ->"q_back") => violation.

Registers inference
Hazardous blocks 5. Do not describe multiple independent conditions in the process (Rationale 4)
Problem Description Do not describe multiple independent conditions in the process - there is a number of problems related to such descriptions. This approach prevents generation of unintentional circuit and improves readability of the description. Example 1 Process contains two sequential case statements => violation.

Latches
6. Avoid latches as much as possible(Rationale 2 and 4).
Problem Description Each signal must be defined under all the possible conditions in combinatorial process description. Otherwise unwanted latches are inferred to retain signal value under certain condition(s). Example The "data_out" signal is assigned only when "enable" signal is equal to '1' whereas its value should be retained when it is equal to '0' => violation.

Clock Domain Crossing (CDC)

This set of standards addresses potential hazards with designs containing multiple clocks Zones and asynchronous clock zone transitions. Analyze Multiple Asynchronous Clocks 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 circuit operation, which can have serious adverse affects on a devices 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. .

Figure. Clock Domains, Metastability, and Mean Time between Failure Calculations 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 that they are properly addressed by a synchronizer circuit. This challenging design

methodology should be identified due to the extreme difficulties associated with isolating and debugging the intermittent CDC-error-induced functional behavior at the hardware level. 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 error might not exhibit itself during normal testing conditions, but it will occur during infield (i.e., in-flight) operating conditions given the right set of environmental factors for the targeted system application.

Some Other Coding Practices: Internal Tri-State

Generally, avoid internal tri-state signals. They introduce increased power consumption, reliability problems (if tri-state line remains undriven) and requirement for an analog simulator (for timing simulation of distributed tristate busses). If still using it, requirements are: _ clearly structured layout _ One hot encoded enable signal _ Bus keeper circuits

SEU(Single Event Upset)

State Machines can be developed to tolerate SEU's or detect SEU's depending upon the overhead required. Increasing the hamming distance between states and defining adjacent states can result in a SEU immune state machine. While use of a one hot state machine and calculating the odd parity of the state register will enable the detection of SEU occurrence allowing appropriate action to be taken.

Inactive Code
Do not leave code lines commented. Any inactive or wrong code has to be deleted. If needed use older versions (for instance from CVS, SVN) for comparison

Keyword After

For synthesizable code do not use after to symbolize delay: sum<=a+b after 5 ns; The after must only be used in test bench for modeling purpose.

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) e. www.mentor.com f. www.fpga-design-solutions.com g. www.opencores.org i. www.aldec.com