Why is the sum of setup time and hold time always positive

In our post "Setup and hold - origin", we discussed that every device captures data within a certain window known as "setup + hold window". During this time, data must be held stable so that it can be captured properly. Outside this window, data is allowed to toggle.


Figure above shows "setup+hold window". This window is characterized by the setup and hold times of the device. The width of this window is essentially the sum of setup time and hold time. Thus, if the sum of setup and hold time is positive, it means there is a finite window wherein the device is allowed to capture the data. On the other hand, a negative sum of setup time and hold time indicates that the width of this window is negative. In other words, the window does not exist. So, a negative setup and hold time implies that the device cannot capture the data at all!! 

Thus, for a functional device, we always need the sum of setup and hold times to be positive. :-)

Reg-to-out paths

A reg-to-out path has a sequential element as the "startpoint" and an output port as "endpoint". We can categorize reg-to-out paths as flop-to-out and latch-to-out, but this differentiation is not widely prevalent. Figure 1 below shows a reg-to-out path originating from a positive edge-triggered flip-flop.


The output port as an "endpoint" is modeled as an alternative of a flip-flop capturing data outside. The SDC command for doing so is "set_output_delay". It represents the portion of data path and clock skew outside the design. Also, we have not shown the clock path in the above figure. The clock source may be situated inside the design and provide clock to outside sitting flip-flop (more commonly called as master transmit or clock-out-data-out in I/O protocol jargon). Or it may be situated outside, thereby, sending data to internal flip-flop through another port (commonly called as clock-in-data-out or slave transmit mode in I/O protocol jargon). Both these scenarios are shown in figures 2 and 3 below.




Constraining reg-to-out paths: As we discussed earlier also, we model the data path and clock path that is not visible inside the design for reg-to-out paths using "set_output_delay" command. There are two cases for constraining output ports:

Case 1: Constraining with respect to virtual clock
Constraining with virtual clock is helpful when we know that the data-path budgeting is exclusive of clock path, for instance, a sub-design of an SoC. A virtual clock is a clock without any source. So, data-path outside the block can be modeled using "set_output_delay" with respect to virtual clock and clock path outside the block can be modeled using "set_clock_latency" for virtual clock. The steps are listed below:

  • "create_clock" at clock source : CLK
  • "create_clock" without a clock source : VCLK (virtual clock)
  • set_output_delay at output port with respect to VCLK

Case 2: Constraining with respect to real clock

When we know that the outside data path delay and clock path delay are fixed, then we can constrain the port with respect to real clock itself. The steps are listed below:

  • "create_clock" at clock source : CLK
  • "set_output_delay" at output_port with respect to CLK (or with respect to a clock related to CLK)