cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
933 Views
Registered: ‎07-31-2018

Correct way to cross clock domains and pass timing closure

Jump to solution

Hi there, 

 

I have a design that uses a number of clock domains.

 

There is a 'slow' clock domain that is used to generate reset signals for other, faster, domains. However, I can't get it to pass timing closure for *some* of the reset/calibration ready signals. 

 

I have attempted to set the paths as false - since they are reset signals I would expect this to not be a problem. However, only some of the reset signals appear to be not being analysed by the timing tools, and others are (and failing timing closure). I have also ensured that reset signals are synchronised to the faster clock domains using a flip-flop chain clocked by the destination clock. 

 

What would be the correct way to ensure these signals pass timing closure - preferably without the need for false paths?

 

 

As an example here are the constraints to mark paths as false: 

 

set_false_path -through [get_nets startup_reset]
set_false_path -through [get_nets io_reset]
set_false_path -through [get_nets clock_reset]
set_false_path -through [get_nets delay_reset]
set_false_path -through [get_nets MemoryDomain0/init_calib_complete]

I have checked that the get_nets command returns an entry. 

 

Here is the timing report summary for a reset signal that is failing timing (despite the false path) 

reset_sig_fail.png

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
928 Views
Registered: ‎01-23-2009

I have attempted to set the paths as false - since they are reset signals I would expect this to not be a problem.

 

This is a very common (and wrong) misconception - resets are not false paths. All resets, whether they use synchronous set/reset pins of flip-flops or asynchronous preset/clear pins of flip-flops must be properly synchronized to the clock domain of the flip-flops. Failure to do so will result in systems that are unreliable at start-up.

 

Take a look at this "Adaptable Advantage" blog on resets and the comments that follow it - there is a lot of good information on resets, reset bridges, and the needs for properly synchronized resets there.

 

Once you fix your design to have proper reset synchronization, the constraints should be more clear - the only paths that need timing exceptions are the inputs to the reset bridges; because they are synchronizers, the timing to their inputs are not to be timed normally...

 

Avrum

View solution in original post

2 Replies
Highlighted
Guide
Guide
929 Views
Registered: ‎01-23-2009

I have attempted to set the paths as false - since they are reset signals I would expect this to not be a problem.

 

This is a very common (and wrong) misconception - resets are not false paths. All resets, whether they use synchronous set/reset pins of flip-flops or asynchronous preset/clear pins of flip-flops must be properly synchronized to the clock domain of the flip-flops. Failure to do so will result in systems that are unreliable at start-up.

 

Take a look at this "Adaptable Advantage" blog on resets and the comments that follow it - there is a lot of good information on resets, reset bridges, and the needs for properly synchronized resets there.

 

Once you fix your design to have proper reset synchronization, the constraints should be more clear - the only paths that need timing exceptions are the inputs to the reset bridges; because they are synchronizers, the timing to their inputs are not to be timed normally...

 

Avrum

View solution in original post

Highlighted
Observer
Observer
901 Views
Registered: ‎07-31-2018

Thank you for the link, I will examine it at length 

 

I have further questions (following a brief look at the info you provided). I am using a number of clock and SERDES primitives that I am fanning the reset signal out to. I have used the Xilinx design example to judge how to generate the reset signals for them and then created these using rather rudimentary logic to build timers - is there a better way to generate these reset signals?  

0 Kudos