[SOLVED] Hold time calculation for single Flip-flop

[ahmad898]

OK, I have an interesting question. Suppose you have a single flip-flop, where its input (D) comes from a combinational logic driven by its output (Q). In my opinion, the hold time violation in this case does not relate to clock skew or jitter at all, as we are inspecting the violation for that single flip-flop. But, something that I dont understand is that the Design Compiler uses the clock uncertanty (skew + jitter) in timing cacluation and becuase of that this structure violates in terms of hold timing. For example, see the following report generated by DC.

 

[danadakk]

This might help -

https://web.engr.oregonstate.edu/~traylor/ece474/beamer_lectures/tsu_and_th.pdf

https://support.xilinx.com/s/question/0D52E00006hpZdXSAU/setup-and-hold-time?language=en_US

https://www.engr.siu.edu/haibo/ece428/notes/ece428_synchr1.pdf

Regards, Dana.

 

[dick_freebird]

I'm not going to suppose anything but state that standard cell flip-flops are designed with zero or negative hold time. This, because you don't want to have to care what happens after the logical clock edge.

This being the case, any inter-register delay elements cannot take you into hold violation. Only setup-next.

 

[oratie]

Did you enabled CRPR before report_timing. It may help in your case.

 

[kaz1]

OK, I have an interesting question. Suppose you have a single flip-flop, where its input (D) comes from a combinational logic driven by its output (Q). In my opinion, the hold time violation in this case does not relate to clock skew or jitter at all, as we are inspecting the violation for that single flip-flop. But, something that I dont understand is that the Design Compiler uses the clock uncertanty (skew + jitter) in timing cacluation and becuase of that this structure violates in terms of hold timing. For example, see the following report generated by DC.

View attachment 181453

I guess your combinatorial node is driven from a clocked source or constrained input. A timing path is supposed to be checked if it is between two timing node. Otherwise the tool cannot determine violation and will not report it.

--- Updated Feb 26, 2023 ---

I'm not going to suppose anything but state that standard cell flip-flops are designed with zero or negative hold time. This, because you don't want to have to care what happens after the logical clock edge.

This being the case, any inter-register delay elements cannot take you into hold violation. Only setup-next.

I am afraid I don't agree. A flip flop is a sampling device and can only function if the D state is settled so data should not transition before/after clock edge at the point where sampling occurs. This point is internal to flip flop. The final device flip flops may have negative tH not because the rule doesn't apply but because at the D level there is internal delay within flip flop relative to the sampling point. The sum of tSU + tH is always constant.

 

[oratie]

CRPR - In this concept, we remove the extra pessimism from common path. (Clock Reconvergence Pessimism Removal)

In DC it is variable timing_remove_clock_reconvergence_pessimism

 

[ahmad898]

timing_remove_clock_reconvergence_pessimism

I have already enabled the clock reconvergence pessimism in PT using the following commands.
set_app_var timing_remove_clock_reconvergence_pessimism true, and the results are the same. I will post the schematic and the report generated by PT, where the hold timing violation occurs.

--- Updated Feb 26, 2023 ---

I guess your combinatorial node is driven from a clocked source or constrained input. A timing path is supposed to be checked if it is between two timing node. Otherwise the tool cannot determine violation and will not report it.

In fact, the input of my flip-flop is related to its output through a combinational logic as below image. My question is that why STA uses the clock uncertanity value here to evaluate the hold analysis. The capture and lanch flip-flop is the same and uncertanty is irrelevent here.

 

[kaz1]

I have already enabled the clock reconvergence pessimism in PT using the following commands.
set_app_var timing_remove_clock_reconvergence_pessimism true, and the results are the same. I will post the schematic and the report generated by PT, where the hold timing violation occurs.

--- Updated Feb 26, 2023 ---

In fact, the input of my flip-flop is related to its output through a combinational logic as below image. My question is that why STA uses the clock uncertanity value here to evaluate the hold analysis. The capture and lanch flip-flop is the same and uncertanty is irrelevent here.

so it is a feedback path through combinatorial logic. The launch and latch edges are not same. The Q outputs on the clock to be latched at D input of same flop on same clock through delay of comb logic. So it needs analysis as any timing path.

 

[oratie]

Try to use set_clock_latency instead of set_clock_uncertainty. From Synopsys User Guide:

Dynamic effects on the clock source latency, such as phase-locked loop (PLL) clock jitter
can be modeled using the -dynamic option of the set_clock_latency command. This
option allows you to specify a dynamic component of the clock source latency. Clock
reconvergence pessimism removal (CRPR) handles the dynamic component of clock
latency in the same way as it handles the PrimeTime SI delta delays. For more information
about CRPR, see CRPR With Dynamic Clock Arrivals.

You can model clock jitter using the set_clock_uncertainty command. However, the
clock uncertainty settings do not affect the calculation of crosstalk arrival windows and are
not considered by CRPR.

 

[ahmad898]

Try to use set_clock_latency instead of set_clock_uncertainty. From Synopsys User Guide:

Dynamic effects on the clock source latency, such as phase-locked loop (PLL) clock jitter
can be modeled using the -dynamic option of the set_clock_latency command. This
option allows you to specify a dynamic component of the clock source latency. Clock
reconvergence pessimism removal (CRPR) handles the dynamic component of clock
latency in the same way as it handles the PrimeTime SI delta delays. For more information
about CRPR, see CRPR With Dynamic Clock Arrivals.

You can model clock jitter using the set_clock_uncertainty command. However, the
clock uncertainty settings do not affect the calculation of crosstalk arrival windows and are
not considered by CRPR.

Thanks for your reply. I follow your suggestion, remove clock uncertainty and add the following constraints instead.
set_clock_latency 3 -source -early -dynamic 0.5 [get_clocks clk]
set_clock_latency 5 -source -late -dynamic 0.5 [get_clocks clk]
I expect to see the dynamic part in setup calculation, i.e., +0.5ns in arrival and -0.5ns on required parts, but I couldnt . I can only see 2ns crpr adjusted by the PT which is reasonable. When I see the example reported by PT , the dynamic part is avaiable, but for setup it isnt. I have also attached the report_clock command to see the constraint set.

--- Updated Feb 27, 2023 ---

Ok. I think i found the problem. The problem is that the PT only consider the dynamic portion of latency when using propagated clock, otherwise, CRPR uses only the static latency, not the dynamic latency, leading up to the common point in the clock path, and removes the resulting static pessimism from the timing results.