0% found this document useful (0 votes)
272 views2 pages

SpyGlass CDC

CDCs rank near the top in difficulty for system-on-chip (SoC) designers. CDCs have become a leading cause of design errors. Conventional static CDC analysis tools fall short in both areas.

Uploaded by

yuga_aran
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
272 views2 pages

SpyGlass CDC

CDCs rank near the top in difficulty for system-on-chip (SoC) designers. CDCs have become a leading cause of design errors. Conventional static CDC analysis tools fall short in both areas.

Uploaded by

yuga_aran
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
  • SpyGlass-CDC Overview
  • The Atrenta Difference

THINK

SpyGlass-CDC
Industry Most Comprehensive, Practical, and Powerful CDC Solution
THINK

Among the many verification challenges confronting system-on-chip (SoC) designers these days, clock domain crossings (CDCs) rank near the top in difficulty. Todays SoCs have dozens or sometimes even hundreds of clock domains, many of them difficult to verify using conventional simulation or static timing analysis (STA). For these bugs to be detected in simulation, it requires long simulation runs and a chance encounter and STA does not check for asynchronous clock domains. As a consequence, CDCs have become a leading cause of design errors. Such errors can add significant time and expense to the design-and-debug cycle, and may even find their way into silicon, necessitating costly re-spins.

The Problem
The success of static CDC verification tools is determined by two critical measures--the time taken to signoff and the completeness of CDC verification. Conventional CDC analysis tools fall short in both areas. They generate large amounts of noise (false violations)--extending the verification cycle--and provide poor coverage of complex CDC synchronization schemes. Two particularly troublesome CDC-related issues involve FIFO- and handshake-based synchronization mechanisms. Both can be difficult or impossible to accurately verify using simulation. And conventional static CDC analysis tools do too little and too much at the same time, simultaneously overlooking real design errors and over-reporting large numbers of false violations. As a result the user is forced into an endless bug-hunting process, which often discourages the designer and leaves real bugs undetected.

The Atrenta Solution SpyGlass-CDC


Supports widest variety of synchronizers and produces the least amount of false violations Automatically recognizes and formally verifies complex handshake and FIFO synchronization schemes Formally verifies data stability Automatically recognizes and formally verifies gray-code logic in re-convergent signals Works without the manual effort to supplement CDC testing with simulation vectors and writing assertions Integrates with Atrenta SpyGlass capabilities targeted for RTL like constraints, constraints and DFT > Easy to ramp up and begin productive use within half a day, even for non-experts > A structured methodology enables quick adoption by engineers and constraints optimized designs

SpyGlass-CDC Methodology
Provides easy-to-use and a comprehensive method for solving CDC problems at RTL to avoid costly silicon re-spins Provides methodology documentation and rulesets as part of the product software installation User-guided CDC sub-methodology flow results in fewer but meaningful violations, thus saving time for the RTL designer Walks users through a series of recommended steps to analyze CDC problems at block and chip level - the steps include design setup, setup checks, design-unit integration chip level CDC verification, report review and CDC verification sign-off

The Atrenta Difference SpyGlass-CDC


Separating True From False Violations In order to isolate real clock domain crossing issues, it is necessary to detect various synchronization schemes--not just basic two-flop or multi-flop synchronizers, but more complex mechanisms, such as handshakes and FIFObased schemes. Once detected, these synchronizers need to be verified as working correctly. Both detection and verification have their own set of challenges, but when done properly, one can confidently claim correctness of these clock domain crossings. This knowledge can be used to filter out false violations, which typically result when a tool fails to recognize properly synchronized crossings and instead reports them as unsynchronized. Many tools lack the ability to detect and functionally verify handshake structures. Given that it is now commonplace to find up to 80 percent of CDCs controlled by handshakes in large design modules, false violations can be numbering in the hundreds. These false violations make designers give up on CDC verification with conventional tools in the market. Similar problems arise with FIFO synchronizers as well. Verifying Handshake Synchronizers Fig 1 shows a typical handshake synchronization scheme. Traditional CDC tools that look only for a double-flop synchronizer will report these crossings as unsynchronized, resulting in a large number of false violations.
Fig1: Typical Handshake Sychronization Scheme
clk_A Other CDC tools report these as CDC violations DATA BUS REQ clk_B ACK clk_A clk_B clk_A DATA BUS write _en

The SpyGlass-CDC solution also formally verifies to see if the following conditions can be violated (Fig 2).
Fig 2: Functional Checks for Handshake
Handshake1 check REQ DATA Violation: Data changing while request is active Handshake2 check REQ ACK N cycle window

Violation: ACK does not become active within N cycles after REQ (default N=5 cycles)

Verifying FIFO Synchronizers FIFOs are commonly used to transfer data generated by a source to a destination where the source and destination are clocked at different or variable rates. Very often the source and destination reside in different clock domains, in which case an asynchronous FIFO is needed. Asynchronous FIFOs involve multiple clock domain crossings for empty and full flag calculation as well as data read to the destination domain. In a FIFO, these crossings are not always synchronized using traditional synchronization methods. Again, other CDC tools are unable to recognize such FIFO scheme (Fig 3), and will report these crossings as unsynchronized, resulting in a large number of false violations.
Fig 3: Typical FIFO Synchronization Scheme
Other CDC tools report these as CDC violations DATA BUS
read_ FSM addr

clk_A read _en

clk_A Domain

EN Sender Handshake FSM

EN Receiver Handshake FSM

clk_B Domain

clk_A Domain
Full

Write write_ FSM addr

Read

FIFO memory array


synchronize read_addr synchronize write_addr Gray to Binary

clk_B Domain
Empty

comparator

comparator

clk_A

clk_B
Binary to Gray

The SpyGlass-CDC solution automatically identifies such handshake schemes, and can thus eliminate a large number of false violations. However, the crossing cannot be considered safe until its functionality is proven to be correct.

The SpyGlass-CDC solution not only automatically identifies the above FIFO scheme but also performs formal checking for data stability (on double-flop synchronizers), and re-convergence signals (from the gray encoder).
Copyright 2008 Atrenta Inc. All rights reserved. Atrenta, the Atrenta logo, SpyGlass, 1Team, Early Design Closure are registered trademarks and is aof Atrenta Inc. All others are the property of their respective holders.

CONTACT: 1.408.453.3333

moreinfo@[Link] [Link]

Atrenta Inc. is the leading provider of Early Design Closure solutions to radically improve design efficiency throughout the IC design flow. Customers benefit from Atrenta tools & methodologies to optimize their designs early in the RTL phase for linting, clock domain crossings, power estimation and reduction, design for test, constraints generation and validation including timing exceptions, and RTL prototyping. Atrenta, Right from the Start!

Atrenta Inc. 2077 Gateway Place, Suite 300, San Jose, California 95110, USA

You might also like