In the post (Setup and hold – basics of timinganalysis), we introduced setup and hold timing requirements and also discussed
why these requirements are needed to be applied. In this post, we will be
discussing how these checks are applied for different cases for paths starting
from flops and ending at latches and vice-versa.
Present day designs are focused mainly on the paths
between flip-flops as the elements dominating in them are flip-flops. But there
are also some level-sensitive elements involved in data transfer in current-day
designs. So, we need to have knowledge of setup and hold checks for
flop-to-latch and latch-to-flop paths too. In this post, we will be discussing the
former case. In totality, there can be total 4 cases involved in flop-to-latch
paths as discussed below:
1)
Paths launching from positive
edge-triggered flip-flop and being captured at positive level-sensitive latch: Figure 1 shows a path being
launched from a positive edge-triggered flop and being captured on a positive
level-sensitive latch. In this case, setup check is on the same rising edge (without time borrow) and next falling edge (with time borrow) and
hold check on the previous falling edge with respect to the edge at which data is
launched by the launching flop.
Figure 1: Timing path from positive edge flop
to positive level latch
|
Figure below shows the waveforms for setup and hold
checks in case of paths starting from a positive edge triggered flip-flop and
ending at a positive level sensitive latch. As can be figured out, setup and
hold check equations can be described as:
Tck->q +
Tprop + Tsetup < Tskew + Tperiod/2 (for setup
check)
Tck->q +
Tprop > Thold + Tskew - (Tperiod/2) (for hold check)
2)
Paths launching from positive
edge-triggered flip-flop and being captured at negative level-sensitive latch: Figure 3 shows a path starting
from positive edge-triggered flip-flop and being captured at a negative level
sensitive latch. In this case, setup check is on the next falling edge (without time borrow) and on next positive edge (with time borrow). Hold
check on the same edge with respect to the edge at which data is launched (zero cycle hold check).
Figure 3: Path from positive edge flop to negative
level latch
|
Figure below shows the waveforms
for setup and hold checks in case of paths starting from a positive edge
triggered flip-flop and ending at a negative level-sensitive latch. As can be
figured out, setup and hold check equations can be described as:
Tck->q +
Tprop + Tsetup < (Tperiod) + Tskew (for setup check)
Tck->q +
Tprop > Thold + Tskew (for
hold check)
3)
Paths launching from negative
edge-triggered flip-flop and being captured at positive level-sensitive latch: Figure 5 shows a path starting
from negative edge-triggered flip-flop and being captured at a positive level
sensitive latch. In this case, setup check is on the next rising edge (without time borrow) and next falling edge (with time borrow). Hold
check on the next rising edge with respect to the edge at which data is
launched.
Figure 5: Path from negative edge flop to
positive level latch
|
Figure below shows the waveforms
for setup and hold checks in case of paths starting from a negative edge
triggered flip-flop and ending at a positive level-sensitive latch. As can be
figured out, setup and hold check equations can be described as:
Tck->q +
Tprop + Tsetup < (Tperiod) + Tskew (for setup check)
Tck->q +
Tprop > Thold + Tskew (for
hold check)
1)
Paths launching from negative
edge-triggered flip-flop and being captured at negative level-sensitive latch: Figure 5 shows a path starting
from negative edge-triggered flip-flop and being captured at a negative level
sensitive latch. In this case, setup check is on the same edge (without time borrow) and on next rising edge (with time borrow). Hold
check on the next rising edge with respect to the edge at which data is
launched.
Figure below
shows the waveforms for setup and hold checks in case of paths starting from a negative
edge triggered flip-flop and ending at a negative level-sensitive latch. As can
be figured out, setup and hold check equations can be described as:
Tck->q +
Tprop + Tsetup < Tperiod/2 + Tskew (for
setup check)
Tck->q +
Tprop > Thold + Tskew - (Tperiod/2) (for hold check)
Hi
ReplyDeleteThis is just basic blogger theme with some customizations. Let me know if you need some help.
Amazing. Thank u for sharing this!
ReplyDeleteAmazing post, thank you for sharing this. So useful!
ReplyDeletehow could I get more detailed thing about this
ReplyDeleteHi
DeleteI guess following post will be useful for you.
https://vlsiuniverse.blogspot.com/2016/12/setup-hold-interview-questions.html
Hi,
ReplyDeleteFor the case of positive edge-triggered FF to positive level-sensitive latch, why does the setup check (without time borrow) happen on same edges of launch and capture clock. Isn't the intended logic that the data launched on active edge of launch clock be captured on the next active edge (low-to-high in this case) of capture clock? Or am I not understanding the functionality of the design correctly? Please advise.
Hi
DeleteIn case of latch, there is an active level (not active edge). This, in case of a positive latch, ranges from positive edge to negative edge. So, data can be captured anywhere in between.
Still should the capture not be in next active level instead of same active level?
DeleteI feel this post should be helpful to you. :-) Please provide feedback on it.
Deletehttps://vlsiuniverse.blogspot.com/2020/11/how-to-interpret-default-setup-and-hold.html
Yeah, I think its incorrect. you should check it in the next cycle for setup time. If you are checking in the same cycle then there should be no hold violations in case 2 and 4. Please edit the post or clarify it.
DeleteThis is really good!
ReplyDeleteGreat post! Thank you for this detailed analysis. Can you comment on the pros/cons of using time borrowing? In my understanding, you show that time borrowing gets you an extra 0.5 cycle on the setup check which could make timing easier to meet. On the other hand, it looks like time borrowing would allow Latch/Q to potentially be glitchy since Latch/D is allowed to change while the latch is transparent. If it's direct FF -> Latch with no combo logic in between then this is probably ok because you will only have 1 transition at Latch/D per clock cycle. However, if there is combo logic in between, (i.e., FF -> Combo -> Latch), then you could have many transitions at Latch/D per clock cycle which means power consumption could be increased if Latch/Q is driving any downstream logic. What are your thoughts on that? And are there any other pros/cons that you see with using time borrowing for FF -> Latch capture?
ReplyDeleteHi
DeleteTrue, but i dont it will be too much to bother about.
Remember, a flop is 2 latches in series. So by using a latch, we are saving area and power equivalent to half a flop as well.
And its only the output of latch that will toggles extra. If it had been a flop, all kogic upto flop input would have toggled as well for wach of the target cases.
i dont understand i 1st case hold is check for which data and it is checked even before the data is launched HOW ?? Can you explain it ?
ReplyDeleteHi, one of the definitions of hold check is that "it prevents the current data to NOT override the previous data at the capture flop". The previous data is captured at previous negative edge, hence, we must prevent the current data to NOT be captured on the previous falling edge. Thats why, this is the way it is. Please let me know if you need a simpler explanation. :-)
DeleteHello,
ReplyDeleteGreat post.
I have a question for the case of posedge triggered flop driving a positive level latch.
Can you please elaborate on how did you arrive at the hold equation for it?
Thanks
Hi, as shown in figure 2, the hold check is on the previous falling edge (thus bringing -ClockPeriod/2 into picture). The rest is a generic equation, involving data delay (Tck2Q + Tprop) & clock path delay (Tskew, which is difference of capture and launch clock latencies) along with hold time of the flip-flop. Please let me know if any further clarification needed.
Delete