Drones must comply with DO-254

The drone market is being awarded multi-billion dollar valuations by companies such as Google and Amazon. As the market grows, the Federal Aviation Agency realises the need to describe the operational role for unmanned aerial vehicles (UAVs) as well as a need for drones to comply to DO-254.

The great thing about a standard is that once you decide to use it, your life as a designer is suddenly easier. Using a standard reduces the long list of choices and decisions that need to be made to get a working product out the door. It also gives assurance to the customer that you are following best practices of the industry.

A standard for the world of aviation electronics (avionics) is the RTCA/DO-254, Design Assurance Guidance For Airborne Electronic Hardware. It is a process assurance flow for civilian aerospace design of complex electronic hardware typically implemented using ASICs or big FPGAs (field-programmable gate arrays). In the United States, the Federal Aviation Administration (FAA) requires that the DO-254 process is followed. In Europe there is an equivalent standard called EUROCAE ED-80.

At first glance, the standard seems daunting. It defines how design and verification flows must be strongly tied to both implementation and traceability. In DO-254 projects, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards. They address the following issues:

• Catching potential design problems in HDL code that may not normally surface until later in the process and may not be caught by other verification activities
• Supporting error detection, containment and recovery mechanisms
• Enforcing style and readability practices to improve code comprehension, portability and reviews

The specific rules or guidelines can be grouped into the following categories:

• Coding Practices: Ensure that a safety-critical coding style and good digital design practices are used
• Clock Domain Crossing: Addresses potential hazards with designs containing multiple clock zones and asynchronous clock zone transitions
• Safe Synthesis: Checks to ensure a proper netlist is created by the synthesis tool
• Design Reviews: Checks to make the process of design reviews and code comprehension easier

A specific guideline, "Coding Practice 6" that ensures safe finite-state-machine (FSM) transitions declares:

1. An FSM should have a defined reset state.

2. All unused (illegal or undefined) states should transition to a defined state, whereupon this error condition can be processed accordingly.

3. In an FSM there should be no unreachable states (i.e., those without any incoming transitions) and no dead-end states (i.e., those without any outgoing transitions).

Guideline CP6 is an example of the granularity within the standard. It addresses how you write state machines, the coding style you use and the conformity of the state machines to that style. Diagram below illustrates how environmental radiation can cause incorrect behaviour and the need to prevent that.



Diagram 1: A single event upset (SEU) due to environmental radiation can cause an FSM to perform invalid transitions. With guideline CP6, this behaviour in DO-254 compliant designs can be eliminated.

While reviews can be done manually, an automated approach (when possible) guarantees a more consistent HDL-code quality assessment. It takes a lot of pain out of the process and makes it less daunting. Automating the HDL code assessment process has the added benefit of promoting regular HDL design-checking steps throughout the design development process, as opposed to waiting for gating design reviews in which issues can be overwhelming and more costly to address.




1 • 2