How to report latency at a sink pin in encounter

Hi abhiroy03 and aidans,

I did some research on this topic, and it appears that our expectation of what latency_rise_max should return isn't aligned with what latency_rise_max was designed to return. From the "Advanced Timing TCL Scripting Commands" section of the FE Text Command Reference document it says:

encounter> man get_property
Pin Properties:
latency_rise_max Returns the maximum rise insertion delay specified by an
[i]explicit set_clock_latency[/i] at the pin.
Return type: float

This hints that latency_rise_max only tells us if set_clock_latency has been applied directly to the clock pin in question. Of course, it is possible for a CK pin to have a latency other than 0 by applying it to the master clock associated with the CK pin, or even an pin "upstream" in the clock tree from the CK pin (say for example you've SDC-asserted a set_clock_latency an integrated clock gating cell).

I hope this clarifies the intended use model for the latency_rise_max field.

From this, it seems that arrival_max_rise is the best way to gain insight into the cumulative arrival time at the CK pin. I understand that the values you're seeing for arrival_max_rise aren't making sense with respect to what you see in the timing report. I did some tests here on a small/simple design and I see it working as I'd expect it to, but I seem to recall in the past that under more complex scenarios it was indeed hard to discern how the values were being calculated. Maybe we can turn our collective attention to trying to understand why arrival_max_rise isn't returning the values we'd expect it to?

Thanks,
Bob

Hi abhiroy03 and aidans,

I did some research on this topic, and it appears that our expectation of what latency_rise_max should return isn't aligned with what latency_rise_max was designed to return. From the "Advanced Timing TCL Scripting Commands" section of the FE Text Command Reference document it says:

encounter> man get_property
Pin Properties:
latency_rise_max Returns the maximum rise insertion delay specified by an
[i]explicit set_clock_latency[/i] at the pin.
Return type: float

This hints that latency_rise_max only tells us if set_clock_latency has been applied directly to the clock pin in question. Of course, it is possible for a CK pin to have a latency other than 0 by applying it to the master clock associated with the CK pin, or even an pin "upstream" in the clock tree from the CK pin (say for example you've SDC-asserted a set_clock_latency an integrated clock gating cell).

I hope this clarifies the intended use model for the latency_rise_max field.

From this, it seems that arrival_max_rise is the best way to gain insight into the cumulative arrival time at the CK pin. I understand that the values you're seeing for arrival_max_rise aren't making sense with respect to what you see in the timing report. I did some tests here on a small/simple design and I see it working as I'd expect it to, but I seem to recall in the past that under more complex scenarios it was indeed hard to discern how the values were being calculated. Maybe we can turn our collective attention to trying to understand why arrival_max_rise isn't returning the values we'd expect it to?

Thanks,
Bob