how to catch glitch in the testbench

semi · Newbie Joined: Nov 13, 2004 Posts: 3

Our chip has a glitch that is caught by another clock domain. But it's impossible to find our simulation enviroment. What's the way to catch this kind of problems? Any tools can help?

thanks,

vhdlcohen · Posted: Sat Nov 13, 2004 7:08 pm **Post subject:**

srini

semi · Newbie Joined: Nov 13, 2004 Posts: 3

Are there anything you can do in testbench to find out this? One case is like this, one flop(that is running in B clock domain) is being async reset by A clock domain, and the flop output is used in B clock domain.

thanks,

vhdlcohen · Posted: Mon Nov 15, 2004 7:40 pm **Post subject:**

srini · Posted: Mon Nov 15, 2004 11:19 pm **Post subject:**

vhdlcohen · Posted: Tue Nov 16, 2004 12:22 am **Post subject:**

Srini wrote:

alexg · Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa

This is a good example, where the problem resides on the boundary between what we used to call "design" and what we used to call "verification".
As Srini wrote, there are 2 steps to solve CDC issues.

1. Topological checks.
The goals of these checks are:
- Extract all clock domain boundaries in multi-clock design and then audit these reports to make sure all clock domain crossings are implemented correctly
- Set/Rest checks: check that sets/resets feeding all registers originate from correct clock domains.
- Glitches elimination: glitch before sync. flops can create the level after transition. The best way to eliminate glitches is to check that only one flop is feeding signal to the sync. flops.

All these checks can be run on the post-synthesis netlist using dc-tcl with Synopsys Design Compiler or similar. However, post-synthesis database is heavy, and there is a need to wait for the synthesis stage completion to get the reports.
Fortunately, there is another way to generate such reports without the need of synthesis tools. Many existing LINT tools can generate these reports immediately after RTL code is written. Some LINT tools such as Synopsys LEDA have their own tcl shell, and is is very easy to write custom scripts to extract all needed topological information from design.

2. Dynamic Effects & Checks
Usage of two flops on the clock domain boundary practically eliminates metastability effect, where the signal is stuck between high and low voltage value. However, the races between clock and data still have an influence on digital simulation and have to be modeled / checked properly.
One of the good solutions is to create syncronization cell containing different "views" for design and for simulation. From design (synthesis) prospective, it contains only two sequentially connected flops. From verification prospective, it is more complex.
First, we have to model the outcome of clock/data conflicts. It may take either one or two clock cycles for data to propagate to the second sync flop, depending on who wins in the race: clock or data. Since it is absolutely unpredictable in RTL simulation, we have to model these races using randomization.

Second, there is a need to perform some checks, such as:
- Minimum pulse width check. Valid pulse can be ignored during clock domain crossing, if the pulse width is smaller that the period of capturing clock.
- Multi-bit signals crossing clock domain are coded properly. There is a need to check that only one bit of the multi-bit signal changes during every clock cycle.

Regards,
Alexander Gnusin

Ajeetha · Posted: Tue Nov 16, 2004 11:49 am **Post subject:**

semi · Newbie Joined: Nov 13, 2004 Posts: 3

yes, I know this is a bad design practice. But I take the design from other people. It's hard for me to review line by line and make sure they don't have bad design practice.

So I wonder if anything I can do to find out if this problem exists. So CDC should find out this problem?

thanks,

alexg · Senior Joined: Jan 07, 2004 Posts: 586 Location: Ottawa