DC timing violation, what to do first?

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

Reply to
Davy
Loading thread data ...

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.

Davy a écrit :

Reply to
Jerome

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

Reply to
Kim Enkovaara

Hi Jerome,

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

Best regards, Shenli

Jerome wrote:

Reply to
Davy

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

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

Best regards, Shenli

Jerome wrote:

Reply to
Mike Lewis

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 nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl
Reply to
Nico Coesel

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

Mike Lewis wrote:

it

ime

ng

Reply to
Davy

Hi,

Davy schrieb:

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

Reply to
Thomas Stanka

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

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

Mike Lewis wrote:

Reply to
Mike Lewis

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

Reply to
Jim Lewis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.