min/max delays &f false paths on clock domains crossing logic

Hi All,

As far as I know, false paths should be applied between clock domains.

What about min/max constraints on the clock domain crossing logic? Can they replace the false paths constraints? How?

Thank you!

You are talking about CDC checks for making sure e.g. the set of signals crossing the domain do not have a delay spread larger than one receiving-domain clock period?

You still might want to declare a FP between the unrelated clocks, e.g. if you are specifying min/max delay constraints as point-to-point timing exceptions only for the actual CDC paths which would override the more general FP.
(however, I do not think you can instead use "set_clock_groups -async", else even those min/max exceptions might not work)
You should be able to see cause & effect by experimenting and examining full-path reports in your STA tool (i.e. debugging).

However, a more practical problem is that you start to get jacked by clock insertion delays (aka latencies) being unknown a-priori and/or very different between the two domains.
In an FPGA, this might not be an issue since the clock latencies and relative diffs are fairly small due to powerful dedicated clock buffering/routing.
But in an ASIC, the clock fanouts could vary tremendously between e.g. a small peripheral I/O block and the main core logic.
The large diffs between the two latencies can start to rival the clock period, and these differences can cause you to *falsely* violate the min/max delay constraints (because CTS latency diffs are included in the min/max checks).

Keep in mind that typically, the real constraint is the *relative* delta-delay spread across the set of signals, and *not* the absolute delay.
Unfortunately, setting min/max checks the absolute delay.

Re: min/max delays &f false paths on clock domains crossing logic

"You are talking about CDC checks" - I'm about the synthesis timing constraints.

Do the min/max delay constraints have the higher priority than FP one or the latest defined will always win?

"CTS latency diffs are included in the min/max checks" - this is for STA. But as for the synthesis constraints, are the min/max definitions for clocks crossing signals required?
So, as for the synthesis, should I set both False path and Min/Max Delay constraints or only one of them (if only one then which one)?

"Keep in mind that typically, the real constraint is the *relative* delta-delay spread across the set of signals, and *not* the absolute delay.
Unfortunately, setting min/max checks the absolute delay." - so, what's the solution?

Thank you!

If you are specifying the same paths, then FP has priority over SMD (you can see this in the man-page for the set_max_delay command, at the bottom where they list the rules for multiple overlapped exceptions).

BTW, as you should know, min-delays will not get "fixed" unless you issue the "set_fix_hold" command.
This could be dangerous if you have not completely defined all timing reqs to prevent DC from seeing erroneous hold-viols and so on.

Anyway, something like the following should be all you need ...
-> set_max_delay [expr $PER_CLKB+$DLAT_ATOB] -from [get_clocks CLKA] -to [get_clocks CLKB]
-> set_min_delay [expr $DLAT_ATOB] -from [get_clocks CLKA] -to [get_clocks CLKB]
-> set_max_delay [expr $PER_CLKA-$DLAT_ATOB] -to [get_clocks CLKA] -from [get_clocks CLKB]
-> set_min_delay [expr 0-$DLAT_ATOB] -to [get_clocks CLKA] -from [get_clocks CLKB]
Note that variable DLAT_ATOB is the ideal clock latency difference/delta between the two clocks (i.e. DLAT_ATOB = $LAT_CLKA-$LAT_CLKB).
This is needed to subtract-out the effect of latency differences, which could esp. cause you to artificially violate the min-delay.
This example assumes that you wish to apply this constraint to ALL signals that cross between the two clocks in BOTH directions.
You thus should NOT also need a FP between the clocks, because you've already caught all paths with the above commands.
(these are point-to-point *exceptions* to the implicit synchronous setup/hold checks between the two clocks)

However, post-CTS in STA, you could still potentially run into the problems I mentioned before if your final latencies differ by a "large" amount.
In my case, I had to stop checking absolute delays, and instead checked the relative delay-spread like I previously described.
My solution was to write a custom TCL procedure in PrimeTime to extract the delays using get_timing_path, get_attribute (on the points and other attributes of a path-object), perform calculations and compare against receive-domain period, and so on.
(A SolvNet search will find a number of PT TCL routines that you can study and modify to do stuff like this.)

Thank you, very useful