cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
joe306
Scholar
Scholar
311 Views
Registered: ‎12-07-2018

Help with Intra-Clock--Paths

Jump to solution

Hello, I'm doing my first timing closure and need some guidance. How to I handle failures in the Intra-Clock-Paths?

 

Clock_Interaction.jpg

 

What constraints do I use?

Clock_Interaction1.jpg

Clock_Interaction2.jpg

Here is a view of the clock interactions.

 

Clock_Interaction_view.jpg

I just don't know where to begin or what constraints to apply.

Can anyone give me some help please.

Thank you

Joe

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
287 Views
Registered: ‎01-23-2009

First - is this timing report done after synthesis or after implementation?

Hold time fixing is done by the router, so before the route step it is expected to have small hold time failures (the 300ps+ you are seeing is not unusual). These will be fixed by the router and can be ignored after synthesis. I highly suspect this is the case because intra-clock hold time failures should never exist unless you are doing something very wrong with your clock buffers - if the clock in question is on a single clock network (i.e. driven by a single clock buffer) then it should be impossible to have "real" hold time failures on it after routing.

That being said, fixing timing failures is rarely done by changing constraints. Adding exceptions (like you have highlighted) is done only if the code in question warrants a timing exception - it is the functionality of the code that determines if a path is false, multi-cycle, or needs a max delay. The "easy" mechanism that Xilinx has implemented to add exceptions on failing paths almost implies otherwise - that one often fixes failing paths by adding exceptions - this  is just not the case. The only time you would do this is if the timing report shows you a path that should have had an exception on it (because of its functionality), but the exception was forgotten...

So, again, this is probably not a real failure. If this is after implementation, then you need to figure out why this failure is occurring - you need to look at the complete path and the functionality of the design around this path and determine which of many possible reasons are causing this failure. Only then can you figure out how to fix it.

Avrum

 

View solution in original post

4 Replies
watari
Teacher
Teacher
295 Views
Registered: ‎06-16-2013

Hi @joe306 

 

>How to I handle failures in the Intra-Clock-Paths?

 

If your xdc is correct, you must change starege for synthesis and implementation.

Refer UG901

 

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug901-vivado-synthesis.pdf

 

Best regards,

avrumw
Guide
Guide
288 Views
Registered: ‎01-23-2009

First - is this timing report done after synthesis or after implementation?

Hold time fixing is done by the router, so before the route step it is expected to have small hold time failures (the 300ps+ you are seeing is not unusual). These will be fixed by the router and can be ignored after synthesis. I highly suspect this is the case because intra-clock hold time failures should never exist unless you are doing something very wrong with your clock buffers - if the clock in question is on a single clock network (i.e. driven by a single clock buffer) then it should be impossible to have "real" hold time failures on it after routing.

That being said, fixing timing failures is rarely done by changing constraints. Adding exceptions (like you have highlighted) is done only if the code in question warrants a timing exception - it is the functionality of the code that determines if a path is false, multi-cycle, or needs a max delay. The "easy" mechanism that Xilinx has implemented to add exceptions on failing paths almost implies otherwise - that one often fixes failing paths by adding exceptions - this  is just not the case. The only time you would do this is if the timing report shows you a path that should have had an exception on it (because of its functionality), but the exception was forgotten...

So, again, this is probably not a real failure. If this is after implementation, then you need to figure out why this failure is occurring - you need to look at the complete path and the functionality of the design around this path and determine which of many possible reasons are causing this failure. Only then can you figure out how to fix it.

Avrum

 

View solution in original post

joe306
Scholar
Scholar
230 Views
Registered: ‎12-07-2018

Hello and thank you for responding to my message. I'm a newbie with Timing Closure so my XDC may be wrong. I'll print out your reference.

 

Thank you

Joe

0 Kudos
joe306
Scholar
Scholar
227 Views
Registered: ‎12-07-2018

Hello, thank you for responding to my message. This is after Synthesis.

Joe

0 Kudos