( ESNUG 389 Item 7 ) --------------------------------------------- [03/06/02]
Subject: ( ESNUG 388 #14 ) Six Letters On Detecting Clock Domain Crossings
> Are you aware of any EDA tools that identify a design's asynchronous
> crossings and check for safe design practice? I posed this question to a
> few EDA companies, but nobody I spoke with had anything available, in
> development, or even in mind.
>
> - Al Jacoutot
> Silicon Access Networks, Inc.
From: Louise Thorpe <louise@veritable.com>
Hi John,
Our Verity-Check design property checking tool ( http://www.veritable.com ),
supports clock domain boundary checking. Verity-Check identifies data
signals that cross boundaries between clock domains that are asynchronous
to each other and checks for synchronization of the data.
- Louise Thorpe
Veritable, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ Yo Quiero Taco Bell ]
Hello John,
I've use a PrimeTime script from the synopsys web site that can catch cross
domain comunications that don't have proper synchronizing flipflops. You
have to ferret out the false ones, though. Seems like we also had to tweak
the script to get it to work.
Also, I believe a tool called SpyGlass will work at the RTL level, sort of
VeriLint on Steroids.
- [ Yo Quiero Taco Bell ]
---- ---- ---- ---- ---- ---- ----
From: Hirendu Vaishnav <vaishnav@synappscorp.com>
Hi John,
I can not say for sure what Al means by "crossings"; however, we do have an
asynchronous timing engine which understands ack-in/ack-out, asynchrous
cycle time, maximum through put, and captures/reports orphans. On our
web site http://www.synappscorp.com we do not talk much about asynchronous
timing engine, but that is how our entire timing engine got started. Let
me give you a brief description of our Async STA:
1) We identify and report longest and shortest paths and cycle times
(i.e., data-launch to acknowledge in) after doing special timing
analysis.
2) We report presence of orphans (i.e., lingering timing events from
previous cycle that may cause logic errors in the next cycle).
3) As part of pre-check, we report any logical/structural interaction
between two different cycles (a cycle is something that is triggered
by a unified acknowledge generation circuitry.)
We report such logical/structural interactions as errors and in fact it is
a pre-check for Async STA.
- Hirendu Vaishnav
SynApps Software Corp. Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: Jiri Prevratil <jiri@avanticorp.com>
Hi, John,
Avanti has a tool called Clock Domain Checker that does exactly this kind of
check. It reads the design, identifies all clock domains, and checks all
signals crossing domains to prove whether they conform to selected
synchronization rules. Clock Domain Checker has built-in synchronization
rules, and also allows users to specify a synchronizer cell that must be in
the signal paths between clock domains. Go to http://www.avanticorp.com
and look up "Clock Domain Checker" under "products".
- Jiri Prevratil
Avanti Corporation Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Lee Eng Han <ehlee@ftdpl.com.sg>
Hi John,
There are two type of EDA tools you can use.
1. PrimeTime
Define the timing domains, and put the design in the desired mode.
Then set false path from a timing domain to the same timing domain.
List out all the timing path. The timing path collection are all
asynchronous crossings.
If you are following some naming convention, you can write a PrimeTime
script to detect bad asynchronous crossings.
2. Formal Verification Approach
Avanti has a formal verification tool that does exactly this. Look
up Clock Domain Checker on their web site.
Hope this helps.
- Lee Eng Han
www.eda-utilities.com
---- ---- ---- ---- ---- ---- ----
From: Richard Curtin <rcurtin@athdl.com>
Hi John,
We have a product called @Verifier, which reads in Verilog RTL and reports
errors related to clock domain synchronization between the signals crossing
between the domains.
Given the top level clocks in the design it can:
- identify the clock tree and partition the design into various
clock domains.
- identify all signals that cross clock domains
- identify valid synchronizers elements amongst these signals. It
recognizes various synchronization styles commonly in use. These
include synchronization based on flops, domain enable MUX logic,
FSM's and FIFOs.
- identify all signals that cross clock domains without proper
synchronization. These could be due to no synchronizers being
present, faulty synchronization schemes or due to combinatorial
logic in the synchronization paths.
The results are presented to the user in a GUI that highlights all
the errors in a source and RTL-schematic browser. All the signals
are color-coded to their respective clocks with all interactions
between clock domains shown in 'RED'. http://www.atHDL.com
- Richard Curtin
@HDL, Inc. San Jose, CA
|
|
