02-07-2020 11:26 AM
There are places where set_disable_timing or set_false_path could both be used to achieve the same desired outcome with regard to logic optimization and timing analysis. I am curious if one is preferred over the other from a computational intensity perspective when an equivalent constraint could be constructed from either of the commands.
02-08-2020 04:02 PM
For the casual reader: A timing path often extends from the clock-pin of a clocked component thru combinational logic to the data-pin of another clocked component (eg. see Fig 5.2, UG906). A timing path can be described as interconnected timing arcs. The set_false_path timing exception is used to disable timing analysis for a timing path. The set_disable_timing timing constraint is used to disable a timing arc and thus prevent timing analysis for all timing paths that contain the disabled timing arc.
@robdrw : To answer your question directly, I can find only the discussion in UG903 under “Ordering Constraints for Better Runtime” indicating computational advantages of set_false_path over set_disable_timing. Specifically, when set_disable_timing is used improperly, it can trigger unnecessary updates of the timing database – whereas set_false_path will not do this.
However, other aspects of set_disable_timing should be considered.
I feel that set_disable_timing is a risky constraint because the casual user may forget that it is possible for a timing arc to be part of many timing paths. So, disabling a timing arc can potentially disable timing analysis for many timing paths.
Also, timing paths usually persist from implementation to implementation. However, timing arcs (eg. thru a LUT) can come and go as logic is optimized. So, set_disable_timing constraints could be difficult to maintain.
All things considered, I’d encourage use of set_false_path instead of set_disable_timing; the latter seemingly designed for use by the Xilinx tools rather than by users.
Finally, set_false_path (and the nearly equivalent “set_clock_groups -async”) should be used cautiously since other constraints like “set_max_delay -datapath_only” are often more appropriate (see Avrum’s comments <here>).
02-08-2020 04:32 PM
I agree with everything that firstname.lastname@example.org said, but just want to add one thing...
In "common" timing constraints, one almost never sees the set_disable_timing; using set_false_path is far more accpeted and understood...
02-10-2020 07:39 AM
Thank you email@example.com & @avrumw . The information you point to is good and I definitely take those points into consideration when constructing my flow. I guess my question had more to do with how things are handled under the hood given that set_disable_timing impacts the timing graph, but set_false_path does not. Does this mean that set_disable_timing reduces the timing path space while set_false_path does not but will tell you that a path in the timing space does not need to be considered? If thats the case, I was guessing that the tool may be able run synthesis and P&R algorithms more efficiently due to the reduced set of timing paths considered when using set_disable_timing. Do you have any info on this?
02-10-2020 04:54 PM
I was guessing that the tool may be able run synthesis and P&R algorithms more efficiently due to the reduced set of timing paths considered when using set_disable_timing. Do you have any info on this?
I can find no info on this - sorry.
-just wanted to emphasize Avrum's comment.
Some day you will hand off your project to a young bright face. That bright face may not thank you for using set_false_path but will very likely curse you for using set_disable_timing.