cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
12,818 Views

Timing after P&R is bad then synthesis ?

Jump to solution

 

 

After synthesis my project's biggest setup slack is -0.03 ns, and there is less than 20 path cannot match the timing. So I believe the P&R tool will help to fix this violation.

 

But after P&R, the timing is absolute wrong! The worst path has a -0.5 ns setup slack. And the number of path can't match the timing is more than 500.

 

My question is is this normal? Or am I make some mistake? 

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
driesd
Xilinx Employee
Xilinx Employee
20,249 Views
Registered: ‎11-28-2007

Hi Askformyhand1,

 

As you can find in the Ultrafast Methodology Guide (see link Deepika), it is perfectly normal that you can (almost) meet timing after synthesis, but have problems after placement or after routing.

According to the methodology guide, we recommend to verify timing and solve problem after each stage (synthesis, placement, (physopt), routing) as they each have their own type of problems.

 

Typical causes for large timing violations after synthesis are:
–Invalid constraint → Fix constraint
–Requirements too restrictive → Check clock interaction
–Many levels of logic → Improve RTL (ex: pipeline)
–Missing synthesis attributes → Modify synthesis settings
 
Typical causes for large timing violations after placement are:
–High fanout nets
–Bad floorplan and/or bad IO placement
–Over utilization
–SLR crossings on SSI devices
 
Physopt is not enabled by default but can resolve some of these issue like high-fanout.
Typical causes for large timing violations after physopt are:
–PhysOpt only works on top 100 offenders -> rerun physopt with various options
–High fanout nets driven from LUTs 
–DONT_TOUCH properties that prevent optimizations
 
Typical causes for large timing violations after routing are:
–Hold fixing → to identify, run route_design with:
• set_false_path –hold –from [all_registers]
• Report timing actual vs estimated
–Congestion
 
Tips to resolving timing issues after route:
– Overconstrain during placement using set_clock_uncertainty to 500ps and set it back to 0 after physopt.
– Incremental placement
– OOC place and route of sub blocks
 
Try to get WNS below 300ps after each stage. (this is a guideline, no hard rule) ... of course you need to meet timing after routing! ;)
There are definitely designs that have much larger WNS after synthesis, but this will have an effect on runtime and you are not guaranteed to easily meet timing after routing. The earlier you can resolve problems, to more the tools can concentrate on the typical problems of that stage.
 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

0 Kudos
4 Replies
hongh
Moderator
Moderator
12,804 Views
Registered: ‎11-04-2010

After synthesis, the route delay used is estimated value, not actually value.

So it's an expected behavior for timing tool.

 

You can try the other stratedies in implementation.

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
vemulad
Xilinx Employee
Xilinx Employee
12,799 Views
Registered: ‎09-20-2012

Hi,

 

To add, you may go through this UG http://www.xilinx.com/support/documentation/sw_manuals/ug949-vivado-design-methodology.pdf

 

From Page-212, it talks about Timing closure techniques.

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Anonymous
Not applicable
12,767 Views

Hi, V

 

Thanks for your reply. That's acture what I want to know.

 

But I'm confused about the following situation.

------------------------------------------------------------------

1. Run Synthesis.  Only 5 paths cannot reach the timing, and each slack is less than 0.03 ns.

2. I think the timing after synthesis is good enough. So stop optimize the HDL and Constrain.

3. Run P&R. Got really bad timing. More than 100 path cannot reach the timing. 

4. The bad path of Syn and P&R is different.

 

Question: Which path should I optimize first ?

0 Kudos
driesd
Xilinx Employee
Xilinx Employee
20,250 Views
Registered: ‎11-28-2007

Hi Askformyhand1,

 

As you can find in the Ultrafast Methodology Guide (see link Deepika), it is perfectly normal that you can (almost) meet timing after synthesis, but have problems after placement or after routing.

According to the methodology guide, we recommend to verify timing and solve problem after each stage (synthesis, placement, (physopt), routing) as they each have their own type of problems.

 

Typical causes for large timing violations after synthesis are:
–Invalid constraint → Fix constraint
–Requirements too restrictive → Check clock interaction
–Many levels of logic → Improve RTL (ex: pipeline)
–Missing synthesis attributes → Modify synthesis settings
 
Typical causes for large timing violations after placement are:
–High fanout nets
–Bad floorplan and/or bad IO placement
–Over utilization
–SLR crossings on SSI devices
 
Physopt is not enabled by default but can resolve some of these issue like high-fanout.
Typical causes for large timing violations after physopt are:
–PhysOpt only works on top 100 offenders -> rerun physopt with various options
–High fanout nets driven from LUTs 
–DONT_TOUCH properties that prevent optimizations
 
Typical causes for large timing violations after routing are:
–Hold fixing → to identify, run route_design with:
• set_false_path –hold –from [all_registers]
• Report timing actual vs estimated
–Congestion
 
Tips to resolving timing issues after route:
– Overconstrain during placement using set_clock_uncertainty to 500ps and set it back to 0 after physopt.
– Incremental placement
– OOC place and route of sub blocks
 
Try to get WNS below 300ps after each stage. (this is a guideline, no hard rule) ... of course you need to meet timing after routing! ;)
There are definitely designs that have much larger WNS after synthesis, but this will have an effect on runtime and you are not guaranteed to easily meet timing after routing. The earlier you can resolve problems, to more the tools can concentrate on the typical problems of that stage.
 

 

Best regards

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.

View solution in original post

0 Kudos