DC timing violation, what to do first?

Discussion:

(too old to reply)

Davy

2007-01-04 07:51:08 UTC

Hi all,

I am new to Synopsys DC. And I have a basic problem. When I find timing
violation in DC report, what shall I do first?

1. Shall I change the script of DC? To let the tools do something like
retiming?
2. Shall I change the RTL code? To pipeline the comb logic manually?
3. Other choice, please recommend.

What circumstance to do "1" or "2" or "1 and 2 at the same time"?

Best regards,
Shenli

Jerome

2007-01-04 09:42:13 UTC

Permalink

Hi,

i will just describe what i do:

First, try to understand the violation:
is this a real one?
if not, add either a false path or a multicycle path or redefine
the timing definition in order to remove this false violation
if yes, change the RTL
regards.

Post by Davy
Hi all,
I am new to Synopsys DC. And I have a basic problem. When I find timing
violation in DC report, what shall I do first?
1. Shall I change the script of DC? To let the tools do something like
retiming?
2. Shall I change the RTL code? To pipeline the comb logic manually?
3. Other choice, please recommend.
What circumstance to do "1" or "2" or "1 and 2 at the same time"?
Best regards,
Shenli

Davy

2007-01-04 11:22:54 UTC

Permalink

Hi Jerome,

Thanks a lot!
Can you tell me what's false path and multicycle path mean?

Best regards,
Shenli

Post by Jerome
Hi,
is this a real one?
if not, add either a false path or a multicycle path or redefine
the timing definition in order to remove this false violation
if yes, change the RTL
regards.

Mike Lewis

2007-01-04 21:50:00 UTC

Permalink

A false path is not a real path ... the tool does not know what are real
paths and what are not .. it just reports the longest path.

A multi-cycle path is a path than can take more than one clock. The design
may be such that a signal is not going to be used for a few clocks after it
comes out of a FF. You can then tell the tool that this signal has more time
to propagate using a multi-cycle constraint.

Mike

"Davy" <***@gmail.com> wrote in message news:***@11g2000cwr.googlegroups.com...
Hi Jerome,

Thanks a lot!
Can you tell me what's false path and multicycle path mean?

Best regards,
Shenli

Post by Jerome
Hi,
is this a real one?
if not, add either a false path or a multicycle path or redefine
the timing definition in order to remove this false violation
if yes, change the RTL
regards.

Davy

2007-01-05 02:56:00 UTC

Permalink

Hi Mike,

Thanks a lot!
I am also confused with your explaination. What cause the tool think
there is a false path or multi-cycle path? IMHO, tools are the first
important thing to believe?

Best regards,
Shenli

Post by Mike Lewis
A false path is not a real path ... the tool does not know what are real
paths and what are not .. it just reports the longest path.
A multi-cycle path is a path than can take more than one clock. The design
may be such that a signal is not going to be used for a few clocks after it
comes out of a FF. You can then tell the tool that this signal has more time
to propagate using a multi-cycle constraint.
Mike
Hi Jerome,
Thanks a lot!
Can you tell me what's false path and multicycle path mean?
Best regards,
Shenli

Post by Jerome
Hi,
is this a real one?
if not, add either a false path or a multicycle path or redefine
the timing definition in order to remove this false violation
if yes, change the RTL
regards.

Mike Lewis

2007-01-05 17:58:53 UTC

Permalink

The tool doesn't know about multi-cycle or false path .. you have to tell
the tool through your constraints.

Mike

"Davy" <***@gmail.com> wrote in message news:***@i15g2000cwa.googlegroups.com...
Hi Mike,

Thanks a lot!
I am also confused with your explaination. What cause the tool think
there is a false path or multi-cycle path? IMHO, tools are the first
important thing to believe?

Best regards,
Shenli

Post by Jerome
Hi,
is this a real one?
if not, add either a false path or a multicycle path or redefine
the timing definition in order to remove this false violation
if yes, change the RTL
regards.

Kim Enkovaara

2007-01-04 11:08:18 UTC

Permalink

Post by Davy
I am new to Synopsys DC. And I have a basic problem. When I find timing
violation in DC report, what shall I do first?
1. Shall I change the script of DC? To let the tools do something like
retiming?
2. Shall I change the RTL code? To pipeline the comb logic manually?
3. Other choice, please recommend.
What circumstance to do "1" or "2" or "1 and 2 at the same time"?

This all depends how big the violation is and how fast the technology
is. If the violation is very small then just some playing with the
scripts (overconstraining) can help. Some other options can also help,
like retiming and more advanced optimizations in the more expensive DC
editions. Of course small violations can be fixed at layout phase with
careful manual placement etc.

If the violations are quite big, then it's wise to change the rtl. That
is usually the fastest and most reliable way to fix the problem. Usually
the tricks in synthesis and layout are done in very late phases, when
you don't want to touch the verified design.

--Kim

Nico Coesel

2007-01-04 22:53:21 UTC

Permalink

The first thing you should do is find out which part of the design
doesn't meet the timing specifications. The Xilinix tools for instance
show the elements causing the delay. From this you can decide whether
you'll need to split the path (extra pipeline stage), alter the
optimizer settings or change the timing constraints.

--
Reply to ***@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Thomas Stanka

2007-01-05 08:04:59 UTC

Permalink

Hi,

I guess you are new to synthesis, too.
First don't worry, synopsys dc doesn't know your timing, it estimates
your timing. The real timing is available after layout.
If Synopsys DC estimates you have a little slack, I would try to go
ahead. Else you need more detailed changes of the RTL-code.

If you like to meet timing during synthesis, you need to learn
something about how synopsys estimates if you meet timing or not (See
documentation for a first step).

bye Thomas

Jim Lewis

2007-01-05 20:48:55 UTC

Permalink

Davy,
You really have not provided enough information to
make any judgment at this point.

What is the desired frequency of your design?
What frequency does your static timing analysis
say it will run at?
What did you set your clock constraints at?

With DC and ASIC libraries, it is very common to
overconstrain the clock by between 10 to 20%.
If you did not do this, I would do this first.

If you are using DC for FPGAs, you are using the
wrong tool, my first step in this case would be
to use the free versions of Xilinx and Altera and
see if that does not fix your issue. If you
do use DC for FPGAs, expect it to be a wrestling
match - there are lots of coding and tool tricks.

Next I would look at the long timing paths.
What caused them? Look at the logic created.
Is it what you expected? If it is not what you
expected, then you need to re-write your code so
that it does create the hardware you want - this
can be a trial and error process. Usually you
start with a picture of what you want and make
the code match it. If that does not work, further
refine the picture until the code does give you
what you want.

Next I would look at potential false and multi-cycle
paths as the others suggested. However, I do not
like doing this unless I have to because if you are
wrong, your final silicon will not work.

Your last alternative is pipelining, architecture
exploration, and changing the clock frequency.

Good Luck,
Jim