Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] Hold time calculation for single Flip-flop

Status
Not open for further replies.

ahmad898

Junior Member level 3
Joined
Aug 21, 2022
Messages
26
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
187
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.

Capture.PNG
 

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.
 

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 ---

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.
 
Last edited:

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
 

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 ---

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.
 

Attachments

  • 1.PNG
    1.PNG
    52.8 KB · Views: 152
  • 2.PNG
    2.PNG
    12.7 KB · Views: 138
  • 2.PNG
    2.PNG
    12.7 KB · Views: 136
Last edited:

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 ---


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.
 

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.
 

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 ---

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.
 

Attachments

  • 3.PNG
    3.PNG
    50.2 KB · Views: 132
  • 4.PNG
    4.PNG
    53.3 KB · Views: 138
  • 5.PNG
    5.PNG
    16.9 KB · Views: 132
Last edited:

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top