How to resolve loops and latch_loops flagged with check_timing report?

[MARKed]

Hello,

When running check_timing, I get both loops and latch_loops. It is not possible for me to change RTL. Paths showing under loops are expected ring oscillators. Given that the tool is timing-driven, what can I do to help it to ignore them?

For the loops I tried with

set_false_path -through X -through Y

where X and Y are the respectively input output pins of two consecutive elements in the loop, but that did not work. Shall I set a false path for the whole loop?

What can I do for the latch_loops instead? (the tool has a lot of reports, but I often struggle to understand the warnings/critical/errors being reported, is there any source for it? User guides tend to be very generic)

[avrumw · Accepted solution]

A false path can only disable the timing checks on a path. A path starts at a clock, a clock pin of a clocked element or a primary input, and ends at a clock, a data pin of a clocked element or a primary output. A combinatorial loop is therefore not part of a path. Since it is not a part of a path, a set_false_path has no effect on the loop.

There are a couple of ways of breaking a combinatorial loop. 

One is to use "set_disable_timing" on one of the cells in the loop. This disables the propagation path from the input to the output of the cell, which, therefore breaks the loop.

Another is to do "path segmentation", which is done using the set_max_delay. If the -from of a set_max_delay is not a current valid startpoint (a clock, the clock pin of a clocked cell, the clocked cell itself, or a primary input), then the set_max_delay turns the -from into a timing path startpoint. The driver of the listed startpoint is no longer connected (from a timing point of view0 to the startpoint. The same is true of the -to; if the -to is not a valid endpoint (a clock, the data pin of a clocked cell, the clocked cell itself, or a primary output), then it will be changed to a timing endpoint, but anything driven by the endpoint is no longer connected from a static timing point of view.

I don't know what a latch_loop is - I don't work with latches. Are you intentionally uses latches in your design? Latch design in Vivado is pretty messy...

Avrum

[MARKed]

Thank you!

Regarding the latches, the design is primarily asic and the fpga is only used for functional verification. Perhaps they are a side effect of this porting? I guess latches can only be fixed in RTL?

[avrumw]

Latches can only be fixed in RTL. And RTL is RTL - if the FPGA tool is interpreting the RTL code as a latch, the ASIC synthesis tool would too - it probably isn't a side effect of the porting - the latches probably exist in the RTL.

In both ASICs and FPGAs, latches are usually unintentional - they are caused by coding errors. If these are intentional, that is surprising since latch based design is equally frowned upon in the ASIC community. 

Also, you need to treat the ring oscillator carefully. Ring oscillators in the ASIC can, at least somewhat, be controlled through synthesis - hand instantiating library components and then putting DONT_TOUCH on them. In an FPGA, it is very difficult to get the tools to implement the ring oscillators as you intend them...

Avrum