cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
1,034 Views
Registered: ‎11-09-2019

Timing constraints are not met

Jump to solution

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.

0 Kudos
1 Solution

Accepted Solutions
drjohnsmith
Teacher
Teacher
1,018 Views
Registered: ‎07-09-2009
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,

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

View solution in original post

4 Replies
drjohnsmith
Teacher
Teacher
1,019 Views
Registered: ‎07-09-2009
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,

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

View solution in original post

markgraf
Adventurer
Adventurer
982 Views
Registered: ‎04-04-2018
baltintop
Voyager
Voyager
881 Views
Registered: ‎06-28-2018

Hi nithinrngowda@gmail.com 

-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).

0 Kudos
avrumw
Guide
Guide
841 Views
Registered: ‎01-23-2009

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