the challenge of clock domain verification in do-254

5
This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval. The Challenge of the Clock Domain Crossing verification in DO-254 Florent Checa Arion Entreprise‘s digital conception engineer April 2012

Upload: silkan

Post on 15-Jan-2015

1.121 views

Category:

Technology


3 download

DESCRIPTION

This article deals with the challenge of CDC Verification activities in a DO-254 project, FPGA or ASIC.

TRANSCRIPT

Page 1: The challenge of Clock Domain Verification in DO-254

This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval.

The Challenge of the Clock Domain

Crossing verification in DO-254

Florent Checa

Arion Entreprise‘s digital conception engineer

April 2012

Page 2: The challenge of Clock Domain Verification in DO-254

This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval.

The context

In order to meet high-performance and low-power requirements, FPGA and ASIC designs often include many separate clock domains. This practice creates Clock Domain Crossing (CDC), which occurs whenever a signal is transferred from a clock domain to another. However, these signals may cause data corruption issues, only occurring during post-layout verification, because conventional RTL verification techniques cannot detect resynchronization problems. As a consequence, critical bugs may escape the verification process and simulation does not accurately predict asynchronous silicon behavior. To predict these problems and debug a design, the Mentor Graphics® CDC analysis tools, 0-In CDC, could be included in your DO-254 design flow.

CDC issues

Because there are many solutions to design CDC, designers have to check if their CDC synchronization logics prevent data corruption across clock domains. Whenever there is a CDC implementation, bugs could be introduced by several issues.

Metastability, the most commonly issue, could occurs when the signal’s target and source clocks are asynchronous. They can have different frequencies or same frequencies but not in phase alignment. If the signal state change doesn’t respect the setup or hold time of the target clock, it may be entering in a metastable state before it randomly sets to a “1” or “0” logic value (Figure 1).

Output set randomly to "1"or

to "0"

clock_1

clock_2

input

output

output’

Figure 1: Metastability

A metastable signal could causes data loss, where hardware values may differ from values predicted by RTL simulation, causing unpredictable behavior in logic interpretation. As shown in the Figure 2, the resynchronized signal may not match with the original and cycle by cycle correspondence between the source and destination domain data are not respected.

Page 3: The challenge of Clock Domain Verification in DO-254

This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval.

clock_1

clock_2

input

output

Clock edges too close

Figure 2: Metastability’s effects

This type of metastability effect can introduce reconvergence issue when the design uses separately-propagated correlated signals. Due to variable delays introduced by the metastability, invalid data can be inserted (Figure 3) and cause unexpected results. This intermediate value which is an invalid state creates reconvergence bugs.

clock_2

clock_1

input[0]

output[0]

input[1]

output[1]

valid datavalid datainvalid data

Clock edges too close

Figure 3: Reconvergence CDC can introduce another type of problem when the target clock frequency is lower than the source clock one. As the figure 4 shows, some signal event may not be sampled by the destination domain. In this case, informations are lost and the resynchronized sequence is corrupted.

clock_2

clock_1

input

output

data loss

Figure 4: data loss To avoid unpredictable behavior related to metastability, ASIC and FPGA designs must properly implement the synchronization logic: synchronizers must be robust to metastability effects and handshaking procotocol logic must ensure that buses are resynchronized only when they are stable.

Page 4: The challenge of Clock Domain Verification in DO-254

This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval.

O-In CDC analyses

The Mentor Graphics® CDC verification tools, 0-In CDC, allows designers to check all CDC paths. CDC correct behaviors are verified thanks to two kinds of analysis, static and dynamic, which will ensure that data is transferred correctly across clock domains.

The Static analysis, supporting a hierarchical approach, examines the RTL source code of the design and identifies clocks, clocks domains, CDC signal and synchronizers. This structural analysis lists all CDC signal paths and their associated CDC schemes and categorizes each CDC logic according to a complete set of predefined CDC schemes. All of them are ranked in three categories corresponding to their critical level of severity, and reported to the user. This analysis highlights CDC paths liable to introduce metastability or reconvergence issues, like CDC paths where synchronizer misses.

If the Static analysis examines the correctness of the CDC paths logic, it does not ensure correct CDC functionality. To perform this task, the Dynamic analysis uses static analysis results as input files. Based on the user-defined simulation test benches, all CDC schemes identified by the static analysis are explicitly verified in dynamic conditions. The Dynamic analysis generates CDC protocol monitors that use assertions to check to correct CDC functionality and ensure proper data transfer. These protocol checkers are also used for the CDC-FX metastability analysis which verifies that all CDC paths are metastability hardened, and reconvergence issues don’t introduce error. For this dynamic simulation, metastability injection logic is extended to each CDC paths, which causes the tested design to act like a hardware implementation with random metastability effects. At the end of dynamic simulations, a coverage rate for each CDC checkers is provided to the user to evaluate each CDC paths in dynamic conditions. Thanks to CDC static and dynamic analyses, a complete and automatic CDC verification is accomplished from the RTL source code. With this tool the verification flow is improved and adapts itself to the increasing level of CDC paths in designs. The use of a CDC checker allows a design team to found bugs earlier in the project planning and mainly before last implementation phases. Another usage could be during IP inspection by the customer to assure enough confidence in the product they will buy.

O-In CDC in DO-254 flows

The DO-254 provides guidance for the development of airborne electronic hardware. As a consequence, in the avionic industry, hardware items must be DO-254 compliant. According to the Design Assurance Level (DAL A to DAL E) the DO-254 defines methods and rules that must be followed during design and verification processes, to ensure hardware item safety.

In response to the increasing CDC use in designs, the DO-254 standard takes close interest in CDC verifying tools. 0-In CDC could complete the RTL code review by verifying correct CDC implementation. Moreover, a metastability hardened design could be compliant with design standard rules specifying how to describe CDC. In another hand, many requirements, like clock specification requirements, don’t need test but code analysis verification. Here, 0-In CDC reports could be used as verification mean for this type of requirement. Especially for hardware items categorized as DAL A and B, where safety requirements are needed, 0-In CDC may be an added value for the verification process.

Page 5: The challenge of Clock Domain Verification in DO-254

This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the company's written approval.

About us

DMAP DMAP is focused on high reliability semiconductor application domains. With more than 40 years of experience we are able to combine IP and SoC development for ASIC and FPGA target with high reliability methods provided by the DO-254 guidance. High reliable domains as aeronautic, medical, defense and space like others mass markets are sensible to time-to-market constraints and a growing system complexity, that's why we offer to IP vendors the opportunity to address new markets and to high reliable sub-contractor community to buy DO-254 ready IP to speed up their development.

DMAP is Arion Entreprise’s components and services business unit.

For more information, please email: [email protected] or visit our website at www.dmap.fr

ARION Entreprise

ARION is delivering innovative solutions to keep industrial data transmission simple while guarantying their performances (real-time, bandwidth optimization, deterministic transmission, security and stability…).

ARION real-time products benefit from our significant experience in highly critical data transmission environment and allow our customers to easily distribute applications across industrial networks while keeping compatible with existing software and networks.

For more information, please email: [email protected] or visit the company’s website at www.arion.fr