This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the com...
This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the com...
This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the com...
This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the com...
This document is the property of Arion Entreprise. Its content cannot be reproduced, disclosed or utilized without the com...
Upcoming SlideShare
Loading in …5
×

The challenge of Clock Domain Verification in DO-254

1,547 views

Published on

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

Published in: Technology, Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,547
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The challenge of Clock Domain Verification in DO-254

  1. 1. 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
  2. 2. 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.
  3. 3. 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 data valid 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.
  4. 4. 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.
  5. 5. 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: contact@dmap.fr 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: contact@arion.fr or visit the company’s website at www.arion.fr

×