Showing posts with label false path. Show all posts
Showing posts with label false path. Show all posts

Can hold check be frequency dependant?


We often encounter people argue that hold check is frequency independent. However, it is only partially true. This condition is true only for zero-cycle hold checks. By zero cycle hold checks, we mean that the hold check is performed on the same edge at which it is launched. This is true in case of timing paths between same polarity registers; e.g. between positive edge-triggered flops. Figure 1 below shows timing checks for a data-path launched from a positive edge-triggered flip-flop and captured at a positive edge-triggered flip-flop. The hold timing, in this case, is checked at the same edge at which data is launched. Changing the clock frequency will not cause hold check to change.

Setup check for positive edge-triggered flip-flop to positive edge-triggered flip-flop is single cycle and hold check is zero cycle
Figure 1: Setup and hold checks for positive edge-triggered to positive edge-triggered flip-flop
Most of the cases in today’s designs are of this type only. The exceptions to zero cycle hold check are not too many. There are hold checks for previous edge also. However, these are very relaxed as compared to zero cycle hold check. Hence, are not mentioned. Also, hold checks on next edge are impossible to be met considering cross-corner delay variations. So, seldom do we hear that hold check is frequency dependant. Let us talk of different scenarios of frequency dependant hold checks:

  1.  From positive edge-triggered flip-flop to negative edge-triggered flip-flop and vice-versa: Figure 2 below shows the setup and hold checks for a timing path from positive edge-triggered flip-flop to a negative edge-triggered flip-flop. Change in frequency will change the distance between the two adjacent edges; hence, hold check will change. The equation for hold timing will be given for below case as:

Tdata + Tclk/2 > Tskew + Thold
or
Tslack =  Tclk/2 - Thold - Tskew + Tdata
          Thus, clock period comes into picture in calculation of hold timing slack.

Both setup and hold checks are half cycle. Setup is checked on next edge whereas hold is checked on previous edge
Figure 2: Setup and hold checks for timing path from positive edge-triggered flip-flop to negative edge-triggered flip-flop

Similarly, for timing paths launching from negative edge-triggered flip-flop and being captured at positive edge-triggered flip-flop, clock period comes into picture. However, this check is very relaxed most of the times. It is evident from above equation that for hold slack to be negative, the skew between launch and capture clocks should be greater than half clock cycle which is very rare scenario to occur. Even at 2 GHz frequency (Tclk = 500 ps), skew has to be greater than 250 ps which is still very rare.
Coming to latches, hold check from a positive level-sensitive latch to negative edge-triggered flip-flop is half cycle. Similarly, hold check from a negative level-sensitive latch to positive edge-triggered flip-flop is half cycle. Hence, hold check in both of these cases is frequency dependant.

2. Clock gating hold checks: When data launched from a negative edge-triggered flip-flop gates a clock on an OR gate, hold is checked on next positive edge to the edge at which data is launched as shown in figure 3, which is frequency dependant.

Setup check is single cycle and hold check is half cycle and checked on next clock edge with respect to launch clock edge
Figure 3: Clock gating hold check between data launched from a negative edge-triggered flip-flop and and clock at an OR gate

           Similarly, data launched from positive edge-triggered and gating clock on an AND gate form half cycle hold. However, this kind of check is not possible to meet under normal scenarios considering cross-corner variations.

3)      Non-default hold checks: Sometimes, due to architectural requirements (e.g. multi-cycle paths for hold), hold check is non-zero cycle even for positive edge-triggered to positive edge-triggered paths as shown in figure 4 below.
Figure 4: Non-default hold check with multi-cycle path of 1 cycle specified







False paths basics and examples

False path is a very common term used in STA. It refers to a timing path which is not required to be optimized for timing as it will never be required to get captured in a limited time when excited in normal working situation of the chip. In normal scenario, the signal launched from a flip-flop has to get captured at another flip-flop in only one clock cycle. However, there are certain scenarios where it does not matter at what time the signal originating from the transmitting flop arrives at the receiving flop. The timing path resulting in such scenarios is labeled as false path and is not optimized for timing by the optimization tool.
Definition of false path: A timing path, which can get captured even after a very large interval of time has passes, and still, can produce the required output is termed as a false path. A false path, thus, does not need to get timed and can be ignored while doing timing analysis.
Common false path scenarios:  Below, we list some of the examples , where false paths can be applied:
Synchronized signals: Let us say we have a two flop synchronizer placed between a sending and receiving flop (The sending and receiving flops may be working on different clocks or same clock). In this scenario, it is not required to meet timing from launching flop to first stage of synchronizer. Figure 1 below shows a two-flop synchronizer. We can consider the signal coming to flop1 as false, since, even if the signal causes flop1 to be metastable, it will get resolved before next clock edge arrives with the success rate governed by MTBF of the synchronizer. This kind of false path is also known as Clock domain crossing (CDC).

The paths to synchronizer are false as the metastability is accounter for
Figure 1: A two flop synchronizer
However, this does not mean that wherever you see a chain of two flops, there is a false path to first flop. The two flops may be for pipelining the logic. So, once it is confirmed that there is a synchronizer, you can specify the signal as false.
Similarly, for other types of synchronizers as well, you can specify false paths.

False paths for static signals arising due to merging of modes: Suppose you have a structure as shown in figure 1 below. You have two modes, and the path to multiplexer output is different depending upon the mode. However, in order to cover timing for both the modes, you have to keep the “Mode select bit” unconstrained. This result in paths being formed through multiplexer select also. You can specify "set false path" through select of multiplexer as this will be static in both the modes, if there are no special timing requirements related to mode transition on this signal. Specifically speaking, for the scenario shown in figure 1,
          Mode 1 : set_case_analysis 0 MUX/SEL
          Mode 2 : set_case_analysis 1 MUX/SEL
          Mode with Mode1 and Mode2 merged together : set_false_path -through MUX/SEL
Select signal selects between two paths for different modes




Figure 2: Mode selection signal selecting between mode1 and mode2 paths
Architectural false paths: There are some timing paths that are never possible to occur. Let us illustrate with the help of a hypothetical, but very simplistic example that will help understand the scenario. Suppose we have a scenario in which the select signals of two 2:1 multiplexers are tied to same signal. Thus, there cannot be a scenario where data through in0 pin of MUX0 can traverse through in1 pin of MUX1. Hence, it is a false path by design architecture. Figure 3 below depicts the scenario.
Figure shows an example of a path that is false by architecture.
Figure 3: A hypothetical example showing architectural false path
Specifying false path: The SDC command to specify a timing path as false path is "set_false_path". We can apply false path in following cases:
  •      From register to register paths
    • set_false_path -from regA -to regB

  •      Paths being launched from one clock and being captured at another
    • set_false_path -from [get_clocks clk1] -to [get_clocks clk2]

  •      Through a signal
    • set_false_path -through [get_pins AND1/B]

Also read: