CDC Verification for Safety-Critical Designs – What You Need to Know

Verification is always a top priority for any chip project. Re-spins result in lost time-to-market and significant cost overruns. Chip bugs that make it to the field present another level of lost revenue, lost brand confidence and potential costly litigation. If the design is part of the avionics or control for an aircraft, the stakes go up, way up. There are substantial rules and guidelines to be adhered to for this class of design. And some of those rules have evolved over decades, making interpretation and adherence challenging.

A recent white paper from Siemens Digital Industries Software examines this class of design for a particularly vexing design bug – clock domain crossing (CDC) issues and resultant metastability. The white paper does a great job explaining the subtleties of CDC bugs and how to address those issues against the rigors of safety-critical rules for airborne systems. If your chip is destined for airborne use, this white paper is must-read. A link is coming, but first I’d like to provide an overview of CDC verification for safety-critical designs – what you need to know.

CDC Challenges

The white paper does a great job explaining how CDC bugs can cause problems with a chip design, and in particular intermittent problems. In safety-critical applications, an intermittent problem can be difficult to find, and bugs that make it to silicon can result in catastrophic consequences.

To summarize the issue, we need to examine the impact of metastability on a design. This term refers to what happens in digital circuits when clock and data inputs of a flip-flop change at approximately the same time. When this occurs, the flip-flop output can oscillate and settle to a random value. This metastability will lead to incorrect design functionality such as data loss or data corruption on CDC paths. The more asynchronous clock domains there are in a design, the worse the problem can become. And in today’s highly integrated and concurrent designs, the number of independent clock domains in a typical device is growing.

The white paper presents many examples that illustrate the types of problems to look for and how to correct them. It points out that this is a serious problem in safety-critical designs in that it frequently causes chips to exhibit intermittent failures. These failures generally go undetected during simulation (which tests a chip’s logic functions) and static timing (which tests for timing – within a single clock domain).

The paper goes on to explain that a typical verification methodology simply does not consider potential bugs from clock-domain crossing paths. Thus, if CDC paths are not explicitly verified, CDC bugs are typically identified in the actual hardware device in the field, a very bad outcome for safety-critical designs.

Design Assurance – the Good and the Bad

Another important part of this story are the guidelines that must be adhered to when sourcing safety-critical airborne devices. The white paper describes document RTCA/DO-254 “Design Assurance Guidance for Airborne Electronic Hardware” in detail. This specification is used by the Federal Aviation Administration (FAA), European Union Aviation Safety Agency (EASA), and other aviation authorities to ensure that complex electronic hardware used in avionics works reliably as specified, avoiding faulty operation and potential air disasters.

This goal is clearly important. One of the challenges of implementing a methodology to achieve the goal is the size and scope of the DO-254 spec. The FAA began enforcing it in 2005. The document is modeled after earlier specifications for certifying software, which were originally published over 45 years ago.

So, there is a lot of information in this document, both old and new. All in-flight hardware (FPGA or ASIC designs) must now comply with DO-254, and correct interpretation of the requirements and implementation in a production design flow presents challenges.

Digging deeper, the white paper explains that DO-254 projects assign a design assurance level (DAL) of A through E. The level corresponds to the criticality of a resulting failure. A failure in a level A design would result in catastrophic conditions (such as the plane crashing), while a failure in a level E design might mean that some passengers could be subject to minor inconvenience. Level A (catastrophic) and level B (hazardous/severe/major) projects must not only follow DO-254 processes but must also address additional safety concerns.

How to Automate CDC Verification

The white paper then presents a detailed overview of how to build a methodology that will conform to DO-254 requirements and deliver reliable, safe chips. It is explained that a comprehensive CDC verification solution must do four distinct things:

1. Perform a structural analysis
2. Verify transfer protocols
3. Globally check for reconvergence
4. Implement netlist glitch analysis

Details of these tasks are presented, as well as some of the unique capabilities of the Siemens Questa CDC solution. The white paper explains that many companies have recognized the benefits of Questa CDC and have adopted it as an added design assurance strategy as part of their verification arsenal. Specific details are presented for several real commercial implementations using Quest CDC. These examples cover many diverse projects:

• S.-based storage/networking company
• Large global computer company
• Large Japanese consumer products company
• S.-based wireless communications provider
• Maker of military space systems
• Large aerospace technology company
• Defense and aerospace systems supplier

The white paper goes on to explain one of the key aspects of the DO-254 process is to deter- mine that the tools used to create and verify designs are working properly. The process to ensure this is called “tool assessment.”

There are many dimensions to this process, and substantial details about how to achieve a successful tool assessment are presented. The diagram below provides an overall flow of the process.

A tool vendor cannot assess or qualify their own tools, and the FAA does not provide blanket approval for use of any tools in DO-254 projects

This white paper does provide valuable details and suggestions for getting through the assessment process for Questa CDC as easily as possible.

To Learn More

If you’re involved in the development of safety-critical electronics this white paper provides substantial value regarding how to minimize CDC risks and how to build a compliant design flow.

The information presented is detailed, clear and actionable. And there is an Appendix with many additional and useful references. You can get your copy of Automating Clock-Domain Crossing Verification for DO-254 (and Other Safety-Critical) Designs here. 

You can also learn more about Questa CDC here. And that’s CDC verification for safety-critical designs – what you need to know.

Also Read:

A Compelling Differentiator in OEM Product Design

AI-Driven DRC Productivity Optimization: Revolutionizing Semiconductor Design

Visualizing hidden parasitic effects in advanced IC design