Automating Clock-Domain Crossing Verification for DO-254 (and other Safety-Critical) Designs
For the sake of safety (or rather design assurance), CDC verification should be employed on every level A/B airborne design with multiple asynchronous clock domains.
Metastability is a serious problem in safety-critical designs, frequently causing chips to exhibit intermittent bugs that may not be caught until an in-flight failure. Traditional simulation does not accurately analyze multi-clock designs and relies on a manual, error-prone process. This paper describes the automated clock domain crossing verification solution DO-254 projects need and tool assessment tips.
Overview of DO-254
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 information 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.
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 containing multiple asynchronous clocks, which occurs any time two or more discrete systems communicate.