In-to-reg paths

An in-to-reg path has an input port as "startpoint" and a sequential element as the "endpoint". Similar to reg-to-reg paths, we can categorize these into in-to-flop and in-to-latch paths; but this differentiation is not prevalent widely. Figure 1 below shows a sample in-to-reg path ending at a positive edge-triggered flip-flop.

The input port as a startpoint is modelled as an alternative of a flip-flop launching data from the outside. The SDC command for doing so is "set_input_delay". It represents the portion of total clock period and clock skew that is outside the design. Also, we have not shown the clock source in the above figure. The clock source may be situated inside the design and provide clock to the outside sitting flip-flop (more popularly called as clock-out-data-in or master receive mode in terms of I/O protocol jargon). Or it may be situated outside, thereby sending clock signal to the internal flip-flop through another port (more popularly called as clock-in-data-in or slave receive mode in I/O protocol jargon). Both these scenarios are shown in figures 2 and 3 below.

Figure 2

Figure 3

Constraining in-to-reg paths: As we discussed earlier, we model the data-path and clock-path that is not visible inside the design for in-to-reg paths. This is done using "set_input_delay" command. There are two cases for constraining input 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 modelled with "set_input_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
• "create_clock" without any source (virtual clock)
• set_input_delay at input_port with respect to virtual clock created 

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 constrain the input port with respect to real clock itself. An example is SoC level protocol signals such as ethernet signals.  The input port is constrained either with respect to the same clock going to the endpoint or some clock related to it. The steps are listed below:

• "create_clock" CLK at clock source
• "set_input_delay" at input_port with respect to CLK (or with respect to a generated_clock created from the CLK