Automating Clock-Domain Crossing Verification for DO-254 (and Other Safety-Critical) Designs

The focus of Document RTCA/DO-254 “Design Assurance Guidance for Airborne Electronic Hardware” (referred to herein as “DO-254”) is hardware reliability for flight safety. In other words, the FAA, EASA and other aviation authorities intend to ensure that the complex electronic hardware used in avionics works reliably as specified, avoiding faulty operation and potential air disasters. DO-254 defines a process that hardware vendors must follow to get their hardware certified for use in avionics. DO-254, which the FAA began enforcing in 2005 (through AC20-152), is modeled after DO-178B, the equivalent process for certifying software, which was published in its original version (DO-178) over 25 years ago. All in-flight hardware (i.e. FPGA or ASIC designs) must now comply with DO-254.

NOTE: This document does not provide general infor­mation on the DO-254 process, but rather focuses on the issue of clock-domain crossing verification and tool assessment, specifically for the tool Questa CDC. If you need general information or training on the DO-254 process, we advise that you visit the DO-254 user’s group web site (www.do-254.com).

The Problem with Clock-Domain Crossing (CDC)

Metastability is the term used to describe what happens in digital circuits when the clock and data inputs of a flip-flop change values at approximately the same time. This is not a problem in single-clock designs, but this becomes a problem on paths transmitting data between asynchronous clock domains. When the data changes in the setup/hold window, this leads to the flip-flop output oscillating and settling to a random value, as shown in figure 1. In this case, the output of the flip-flop is said to have gone metastable and will lead to incorrect design functionality, such as data loss or data corruption on CDC paths. This situation happens in every design con­taining multiple asynchronous clocks, which occurs any time two or more discrete systems communicate.

Metastability is a serious problem in safety-critical designs in that it frequently causes chips to exhibit intermittent failures. These failures generally go unde­tected during simulation (which tests a chip’s logic func­tions) and static timing (which tests for timing – within a single clock domain). A typical verification methodol­ogy simply does not consider potential bugs from clock-domain crossing paths. Thus, if CDC paths are not explic­itly verified, CDC bugs are typically identified in the actual hardware device in the field. For DO-254 projects, catching faulty operation “in the field” means critical bugs may not be caught until an in-flight failure.

With today’s highly integrated and concurrent designs, the number of independent clock domains found on the typical device is growing. According to an industry research study performed by Wilson Research in 2018, the average number of clock domains on a single device was between 5-10. This means that the probability of metastability bugs has grown substantially from previ­ous designs.

The real issue is that traditional simulation and timing analysis do not accurately analyze multi-clock designs. Designers are generally aware of the metastability problem and try to implement logic to isolate the out­puts of the metastable registers such that this meta­stable value does not propagate into the rest of the design. For example, experienced designers add syn­chronizers between clock domains, create protocols for transferring data between domains, and try to avoid situations where data from multiple clock domains reconverge, as shown in figure 2.