Turn on suggestions

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.

Showing results for

- Community Forums
- :
- Forums
- :
- Vivado RTL Development
- :
- Timing Analysis
- :
- Timing constraints are not met

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page

nithinrngowda@gmail.com

Visitor

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-16-2020 02:27 AM

485 Views

Registered:
11-09-2019

Hello,

I am working on a design and I am getting a critical warning- timing constraints are not met. I am completely new to this and not sure how to fix and how to analyse the report. Below is the error

Max Delay Paths

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

Slack (VIOLATED) : -0.006ns (required time - arrival time)

Source: rom/A_r_reg[0]_rep__0/C

(rising edge-triggered cell FDRE clocked by Clk_in {rise@0.000ns fall@5.000ns period=10.000ns})

Destination: rom/A_r_reg[2]_rep/D

(rising edge-triggered cell FDRE clocked by Clk_in {rise@0.000ns fall@5.000ns period=10.000ns})

Path Group: Clk_in

Path Type: Setup (Max at Slow Process Corner)

Requirement: 10.000ns (Clk_in rise@10.000ns - Clk_in rise@0.000ns)

Data Path Delay: 9.437ns (logic 2.073ns (21.966%) route 7.364ns (78.034%))

Logic Levels: 14 (LUT2=1 LUT6=11 MUXF7=1 RAMD64E=1)

Clock Path Skew: -0.486ns (DCD - SCD + CPR)

Destination Clock Delay (DCD): 3.759ns = ( 13.759 - 10.000 )

Source Clock Delay (SCD): 4.630ns

Clock Pessimism Removal (CPR): 0.385ns

Clock Uncertainty: 0.035ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE

Total System Jitter (TSJ): 0.071ns

Total Input Jitter (TIJ): 0.000ns

Discrete Jitter (DJ): 0.000ns

Phase Error (PE): 0.000ns

Can someone explain me how to analyse this report and what can be done to fix this? I have attached the complete timing report for reference.

1 Solution

Accepted Solutions

Highlighted
As a first stab,

timing is measured register to register,

so the more LUTs you have in a path , the more time the path takes, making your timing harder to meet.

So your report is saying your trouble path has a delay of 9.437ns, and takes 14 levels of

logic.

Your source fo the net is

rom/A_r_reg[0]_rep__0

and the designation is

rom/A_r_reg[2]_rep

So the way to go about this is ,

a) simulate the design, does it perform the function you want ?

if not, then address your code till it does.

b) only once a is working, then synthesis and P&R and check timing.

If it does not meet timing , look at the longest path, and you have to re address how you do the function , to make the logic simpler , adding pipe line registers is a useful technique.

after a while you will learn how to describe a logic function to meet your timing, unfortunatly its a skill, as the solution one would select depends upon the fpga series and the timing you want,

its a constant trade off between speed, area of design, and latency through design that you only learn by practice,

drjohnsmith

Teacher

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-16-2020 03:06 AM

469 Views

Registered:
07-09-2009

timing is measured register to register,

so the more LUTs you have in a path , the more time the path takes, making your timing harder to meet.

So your report is saying your trouble path has a delay of 9.437ns, and takes 14 levels of

logic.

Your source fo the net is

rom/A_r_reg[0]_rep__0

and the designation is

rom/A_r_reg[2]_rep

So the way to go about this is ,

a) simulate the design, does it perform the function you want ?

if not, then address your code till it does.

b) only once a is working, then synthesis and P&R and check timing.

If it does not meet timing , look at the longest path, and you have to re address how you do the function , to make the logic simpler , adding pipe line registers is a useful technique.

after a while you will learn how to describe a logic function to meet your timing, unfortunatly its a skill, as the solution one would select depends upon the fpga series and the timing you want,

its a constant trade off between speed, area of design, and latency through design that you only learn by practice,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>

4 Replies

Highlighted
As a first stab,

timing is measured register to register,

so the more LUTs you have in a path , the more time the path takes, making your timing harder to meet.

So your report is saying your trouble path has a delay of 9.437ns, and takes 14 levels of

logic.

Your source fo the net is

rom/A_r_reg[0]_rep__0

and the designation is

rom/A_r_reg[2]_rep

So the way to go about this is ,

a) simulate the design, does it perform the function you want ?

if not, then address your code till it does.

b) only once a is working, then synthesis and P&R and check timing.

If it does not meet timing , look at the longest path, and you have to re address how you do the function , to make the logic simpler , adding pipe line registers is a useful technique.

after a while you will learn how to describe a logic function to meet your timing, unfortunatly its a skill, as the solution one would select depends upon the fpga series and the timing you want,

its a constant trade off between speed, area of design, and latency through design that you only learn by practice,

drjohnsmith

Teacher

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-16-2020 03:06 AM

470 Views

Registered:
07-09-2009

timing is measured register to register,

so the more LUTs you have in a path , the more time the path takes, making your timing harder to meet.

So your report is saying your trouble path has a delay of 9.437ns, and takes 14 levels of

logic.

Your source fo the net is

rom/A_r_reg[0]_rep__0

and the designation is

rom/A_r_reg[2]_rep

So the way to go about this is ,

a) simulate the design, does it perform the function you want ?

if not, then address your code till it does.

b) only once a is working, then synthesis and P&R and check timing.

If it does not meet timing , look at the longest path, and you have to re address how you do the function , to make the logic simpler , adding pipe line registers is a useful technique.

after a while you will learn how to describe a logic function to meet your timing, unfortunatly its a skill, as the solution one would select depends upon the fpga series and the timing you want,

its a constant trade off between speed, area of design, and latency through design that you only learn by practice,

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>

Highlighted
##

Jump to solution
Some good information:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug1292-ultrafast-timing-closure-quick-reference.pdf

https://www.xilinx.com/products/design-tools/vivado/quicktake-videos/design-analysis-timing-closure.html

markgraf

Adventurer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-16-2020 06:03 AM

433 Views

Registered:
04-04-2018

Re: Timing constraints are not met

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug1292-ultrafast-timing-closure-quick-reference.pdf

https://www.xilinx.com/products/design-tools/vivado/quicktake-videos/design-analysis-timing-closure.html

Steve Markgraf - Distinguished FPGA Design & Support Engineer E5-E

www.designlinxhs.com

www.designlinxhs.com

Highlighted
##

Jump to solution
-0.006ns slack is quite small considering the clock frequency. I believe it can be fixed by just changing the implementation strategy (Settings -> Implementation -> Options).

baltintop

Explorer

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-21-2020 06:02 AM

332 Views

Registered:
06-28-2018

Re: Timing constraints are not met

Highlighted
##

Jump to solution

avrumw

Guide

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

01-21-2020 03:26 PM

292 Views

Registered:
01-23-2009

Re: Timing constraints are not met

In addition to what others have said, you have problems with your clocking.

From the report, you clock comes in on an input buffer (IBUF) then goes to a LUT3 - clocks really shouldn't go through any combinatorial logic. From there it goes to both the starpoint and endpoint of your failing path **without**** a clock buffer **- this makes it a "locally routed clock". Clocking like this is highly discouraged, and results in (among other things) a larger than normal clock skew (in your case 0.486ns). If you fix the clock skew by using a dedicated clock tree, your clock skew will improve by significantly more than 0.006ns, which will make this path pass with ease.

You also have problems with your constraints and/or design structure, which result in lots of warnings from "check_timing" (the top part of the timing summary report). The most concerning is the "no_clock" section, which shows that there aer a huge number of registers with no clock. From some of the names, it appears that you are trying to generate clocks from flip-flops. Again, this is highly discouraged... But if you do do this, you **must** manually create generated clocks on the outputs of these flip-flops. By not doing so, a singificant portion of your design is unconstrained. Since it is unconstrained, no timing analysis is performed on it - so your timing problems may be significantly worse than what you are currently seeing.

Avrum