cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mdakram140
Adventurer
Adventurer
1,528 Views
Registered: ‎07-02-2014

Huge setup violation due to large routing delay

Jump to solution

Hi all,

 

I am presently working on 1G Ethernet Mac plus PCS custom core integration into a design with a custom processor on VCU118 KIT.

I am using vivado 2017.3.1 , afternoon implementation I am getting huge setup violations.

Please find the attached path report.

Like this there are few more violations are there.

Can please suggest what can be done for this setup violations

 

Thanks 

 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
1,421 Views
Registered: ‎01-23-2009

Your clocks are certainly a big part of your problem.

 

First of all, the clock and the path are in different SLRs. While it is legal to have logic driven by the same clock in different SLRs, this does degrade timing. If possible, find a way to have all logic on a given clock in one SLR.

 

But the bigger problem is your destination clock - you have two LUTs and an extra clock buffer on this clock. Whatever you are doing to this clock, don't do it. In FPGAs, you want your clocks to use dedicated clock resources only - this means no fabric logic on the clock. Your destination path should look the same as your source path - one BUFG_GT, the MMCM, and one BUFGCE, with no logic. If you need to gate the clock, do it properly by controlling the CE of the BUFGCE (that's what it's there for).

 

A clock structure like this is going to give you all kinds of problems. Even if you succeed in fixing the setup violations (which it is questionable that you will be able to), you will have huge hold time problems - your destination clock comes almost 2.5ns after your source clock. In fact, it is possible that you are seeing these large delays due to the tool intentionally inserting additional routing delay in order to fix this massive hold time failure (in fact it is very likely that this is the case)...

 

Avrum

View solution in original post

5 Replies
drjohnsmith
Teacher
Teacher
1,516 Views
Registered: ‎07-09-2009

without the full design, there is not much specific to say

 

there is quite a bit of info on what to do

 

https://www.xilinx.com/support/documentation-navigation/design-hubs/dh0006-vivado-design-analysis-and-timing-closure-hub.html

 

first things I'd look at is your clocks and clock constraits, and CDC 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
hemangd
Moderator
Moderator
1,473 Views
Registered: ‎03-16-2017

Hi @mdakram140,

 

Yes, the route delay is high and clock path skew also needs to be looked into. 

Can you provide the full timing report after implementation? Just run "report_timing_summary -file <filepath>/timingreport.txt" and provide timingreport.txt to evaluate further. 

 

Regards,

hemangd 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
0 Kudos
mdakram140
Adventurer
Adventurer
1,440 Views
Registered: ‎07-02-2014

please find the attached timing report with few violations mentioned in the text file

0 Kudos
hongh
Moderator
Moderator
1,429 Views
Registered: ‎11-04-2010

Hi, @mdakram140 ,

Suggestion for you:

1. Balance the structure of source and destination clock [rxuserclk_mmcm] and make them have same level, or handle the path as asynchronous paths with properly logic:

Source: GT -> BUFG_GT -> MMCM -> BUFGCE -> FF

Destination: GT -> BUFG_GT -> MMCM -> BUFGCE -> LUT -> LUT -> FF

2. Reduce the logic level of the path with long logic level (current value is 14)

 

3. Clock domain rxuserclk_mmcm(16ns) logic is sampling logic in Clock domain rxuserclk2_mmcm(8ns). The current requirement is 8ns. Is it possible to modify the requirement to 16ns with set_multicycle_paths constraint? 

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
avrumw
Guide
Guide
1,422 Views
Registered: ‎01-23-2009

Your clocks are certainly a big part of your problem.

 

First of all, the clock and the path are in different SLRs. While it is legal to have logic driven by the same clock in different SLRs, this does degrade timing. If possible, find a way to have all logic on a given clock in one SLR.

 

But the bigger problem is your destination clock - you have two LUTs and an extra clock buffer on this clock. Whatever you are doing to this clock, don't do it. In FPGAs, you want your clocks to use dedicated clock resources only - this means no fabric logic on the clock. Your destination path should look the same as your source path - one BUFG_GT, the MMCM, and one BUFGCE, with no logic. If you need to gate the clock, do it properly by controlling the CE of the BUFGCE (that's what it's there for).

 

A clock structure like this is going to give you all kinds of problems. Even if you succeed in fixing the setup violations (which it is questionable that you will be able to), you will have huge hold time problems - your destination clock comes almost 2.5ns after your source clock. In fact, it is possible that you are seeing these large delays due to the tool intentionally inserting additional routing delay in order to fix this massive hold time failure (in fact it is very likely that this is the case)...

 

Avrum

View solution in original post