Setup and Hold Timing Equations - S-01| Easy Explanation with Examples | Same types of FF

[@KrishnaKumar-ev3xr]

One of the best explanation I have seen ... that's the video I was looking for ...thank you sir

[@TeamVLSI]

Glad it helped Krishna!!!

[@vikaspatel656]

yes, it is possible to occur setup and hold violation for the same path because in the setup analysis it contains the clock period but hold analysis does not contain the clock period.

[@TeamVLSI]

Hi Vikash, I see your statement is right, but justification/explanation is not true. Please take a deep dive into concept.

[@curiousflight5923]

Thank you very much sir . Very helpfull video.

[@TeamVLSI]

Thanks a lot. Its our pleasure that you liked it.

[@Mark4Jesus]

Well explained. Thank you.

[@TeamVLSI]

Thanks, Mark!

[@abishekguggari1180]

Yes both setup and hold violations can occur in same path. These violations will occur in half cycle paths when combinational delay is less than half of the clock period. Correct me if I m wrong.

[@TeamVLSI]

Yes Abishek, Right!

[@shubhamnayak9369]

I think hold analysis sometimes depends on Freq when you decrease path 4 delay Because that will eventually affect our 2nd clock(capture edge) as overall Tclk will reduce. I mean that while solving for hold time violation your Freq of clk may reduce but reduction of clk might not solve your hold violation

[@TeamVLSI]

Hi Subham, Thanks for attempting. I would like to correct one thing here, that changing any path delay, will not change the clock period. it will only affect the skew between them. I would suggest you to watch 2nd video of this series, you will be more clear.

[@jayp_2]

Very nice explanation sir 😁👌

[@TeamVLSI]

Thanks Jay.

[@meenapriya7232]

Setup and hold violation cannot happen for the same path with same start and end points. As per the equation, LHS can be either greater for setup violation or smaller for hold violation. Is that correct?

[@TeamVLSI]

Hi Meena, Can occur. but how, try to think.

[@meenapriya7232]

@@TeamVLSI Due to high value of setup and hold time of flop or uncertainty.....

[@akashwayal8797]

for setup timing we need more skew, and for hold timimg we need less skew, so if our value is in between that, it might affect both setup and hold timing violations? am i right ?

[@TeamVLSI]

Hi Akash, large unbalanced skew could be one reason but try to think of some other reasons too.

[@bhuvannaga8854]

sir u explained in reverse manner (in explanation u told that tcq + tcombo as arrival tym) but in solving the problem tcq + tcombo is RAT in these 2 which one is correct...

[@TeamVLSI]

Hi Bhuvan, I reviewed the the session. And I found both the places I have called tcq + tcombo is AT. equation: 11:30 example: 15:45 Anyway in case of confusion, consider left part as AT and right part is RAT in equation given at timestamp 11:30

[@vikaspatel656]

may be hold timing check will depend on the frequency when both the launch flop and capture flop are diiferent type of edgr triggered.

[@TeamVLSI]

Exactly.

[@User--jm5916]

Why hold is checked at same clock edge, and setup is checked at next clock edge, why hold is independent of frequency

[@TeamVLSI]

Hi Radha, In short I would like to say In setup we put condition on data that data should reach before a fix time in reference of clock edge. So we cant check it on same clock edge. Just think it, it would be like that we are expecting the data at capture flop even before launch it. In hold we are putting condition data should reach at capture flop after certain time in reference of capture clock edge. So just think if we put this condition on next edge then we will contradict the setup condition and we can't meet both together. Just think if we check setup and hold both at next clock edge, Setup will say data should reach at capture FF before clock edge and hold will say data should reach there after clock edge. So meeting one will violate other. Thanks

[@User--jm5916]

@@TeamVLSI thanks for your reply

[@satyamnigam4426]

There is a possibility of setup and hold violation in Multicycle paths. Is this correct?

[@TeamVLSI]

Very less, but yes.