TIMING

8
CHAPTER

VERIFICATION

Yashwanth Godishala
 Contents:

 8.1 Setup Timing Check

 8.2 Hold Timing Check
 8.3 Multicycle Paths
 8.4 False Paths
 8.5 Half-Cycle Paths
 8.6 Removal Timing Check
 8.7 Recovery Timing Check
 8.8 Timing across Clock Domains
 8.9 Examples
 8.10 Multiple Clocks
8.1 Setup Timing Check

 Flip-flop to Flip-flop Path

 Input to Flip-flop Path
 Flip-flop to Output Path
 Input to Output Path
 A setup timing check verifies the timing relationship between the clock and the
data pin of a flip-flop so that the setup requirement is met. In other words, the
setup check ensures that the data is available at the input of the flip-flop before
it is clocked in the flip-flop. The data should be stable for a certain amount of
time, namely the setup time of the flip-flop, before the active edge of the clock
arrives at the flip-flop. This requirement ensures that the data is captured
reliably into the flip-flop. Figure 8-1 shows the setup requirement of a typical
flip-flop. A setup check verifies the setup requirement of the flip-flop.

 The clocks to these two flip-flops can be the same or can be different. The setup
check is from the first active edge of the clock in the launch flip-flop to the
closest following active edge of the capture flip-flop. The setup check ensures
that the data launched from the previous clock cycle is ready to be captured
after one cycle.
 The setup check can be mathematically expressed as:

Tlaunch + Tck2q + Tdp < Tcapture + Tcycle - Tsetup

 In other words, the total time it takes for data to arrive at the D pin of the
capture flip-flop must be less than the time it takes for the clock to travel to the
capture flip-flop plus a clock cycle delay minus the setup time.

 Since the setup check poses a max1 constraint, the setup check always uses the
longest or the max timing path. For the same reason, this check is normally
verified at the slow corner where the delays are the largest.
8.1.1 Flip-flop to Flip-flop Path(SETUP)

 All paths in a design are categorized into path groups based on the clock
of the capture flip-flop. The path type line indicates that the delays
shown in this report are all max path delays indicating that this is a setup
check. This is because setup checks correspond to the max (or longest
path) delays through the logic. Note that the hold checks correspond to
the min (or shortest path) delays through the logic.

❖ create_clock -name CLKM -period 10 -waveform {0 5}\

[get_ports CLKM]
❖ set_clock_uncertainty -setup 0.3 [all_clocks]
❖ set_clock_transition -rise 0.2 [all_clocks]
❖ set_clock_transition -fall 0.15 [all_clocks]
 What is the clock network delay in the timing report and why is it marked
as ideal?
❑ This line in the timing report indicates that the clock trees are treated as
ideal, that any buffers in the clock path are assumed to have zero delay.
Once the clock trees are built, the clock network can be marked as
propagated- which causes the clock paths to show up with real delays, as
shown in the example timing report. The 0.11ns delay is the clock network
delay on the launch clock and the 0.12ns delay is the clock network delay
on the capture flip-flop.

 Note that the edge at the clock pin of the flip-flop (called the active edge)
remains unchanged. It can only be a rising or falling active edge, depending
upon whether the flip-flop is rising-edge triggered or falling-edge triggered
respectively.
8.2 Hold Timing Check

 Flip-flop to Flip-flop Path

 Input to Flip-flop Path
 Flip-flop to Output Path
 Input to Output Path
 A hold timing check ensures that a flip-flop output value that is
changing does not pass through to a capture flip-flop and overwrite its
output before the flip-flop has had a chance to capture its original
value. This check is based on the hold requirement of a flip-flop. The
hold specification of a flip-flop requires that the data being latched
should be held stable for a specified amount of time after the active
edge of the clock. Figure 8-9 shows the hold requirement of a typical
flip-flop.
 8.2.1 Flip-flop to Flip-flop Path (HOLD)

 Consider the second rising edge of clock CLKM. The data launched by the rising
edge of the clock takes Tlaunch + Tck2q + Tdp time to get to the D pin of the
capture flip-flop UFF1. The same edge of the clock takes Tcapture time to get to
the clock pin of the capture flip-flop. The intention is for the data from the launch
flip-flop to be captured by the capture flip-flop in the next clock cycle. If the data
is captured in the same clock cycle, the intended data in the capture flip-flop (from
the previous clock cycle) is overwritten. The hold time check is to ensure that the
intended data in the capture flip flop is not overwritten. The hold time check
verifies that the difference between these two times (data arrival time and clock
arrival time at capture flip-flop) must be larger than the hold time of the capture
flip-flop, so that the previous data on the flip-flop is not overwritten and the data is
reliably captured in the flip-flop.
Flip-flop to Flip-flop Path (HOLD)

 Notice that the Path Type is described as min indicating that the cell
delay values along the shortest path are used which corresponds to
hold timing checks. The library hold time specifies the hold time of
flip-flop UFF1. (The hold time for flip-flops can also be negative as
explained earlier in Section 3.4.) Notice that both the capture and
receive timing is computed at the rising edge (active edge of flip-
flop) of clock CLKM. The timing report shows that the earliest time
the new data can arrive at UFF1 while enabling the previous data to
be safely captured is 0.19ns. Since the new data arrives at 0.33ns, the
report shows a positive hold slack of 0.14ns.
 CLOCK LATENCY

 What is clock source latency? This is also called insertion delay and is the time it takes for a clock to propagate
from its source to the clock definition point of the design under analysis as depicted in Figure 8-3. This
corresponds to the latency of the clock tree that is outside of the design. For example, if this design were part
of a larger block, the clock source latency specifies the delay of the clock tree up to the clock pin of the
design under analysis. This latency can be explicitly specified using the set_clock_latency command.

set_clock_latency -source -rise 0.7 [get_clocks CLKM]

set_clock_latency -source -fall 0.65 [get_clocks CLKM]
 In the absence of such a command, a latency of 0 is assumed. That was the assumption used in earlier path
reports. Note that the source latency does not affect paths that are internal to the design and have the same
launch clock and capture clock. This is because the same latency gets added to both the launch clock path and
the capture clock path. However this latency does impact timing paths that go through the inputs and outputs of
the design under analysis.

 Without the -source option, the set_clock_latency command defines the clock network latency- this is the
latency from the clock definition point in the DUA to the clock pin of a flip-flop. The clock network latency is
used to model the delay through the clock path before the clock trees are built, that is, prior to clock tree
synthesis. Once a clock tree is built and is marked as propagated, this clock network latency specification is
ignored. The set_clock_latency command can be used to model the delay from the master clock to one of its
generated clocks as described in Section 7.3. This command is also used to model off-chip clock latency when
clock generation logic is not part of the design.
8.1.2 Input to Flip-flop Path (SETUP)
Input to Flip-flop Path (HOLD)

 The min delay on the input port is specified using a virtual clock as:

set_input_delay -clock VIRTUAL_CLKM \

-min 1.1 [get_ports INA]

 The set_input_delay appears as input external delay. The hold check is

done at time 0 between rising edge of VIRTUAL_CLKM and rising
edge of CLKM. The required arrival time for data to be captured by
UFF2 without violating its hold time is 0.25ns-this indicates that the
data should arrive after 0.25ns. Since the data can arrive only at 1.2ns,
this shows a positive slack of 0.95ns.
8.1.3 Flip-flop to Output Path(SETUP)
8.2.3 Flip-flop to Output Path (HOLD)
8.1.4 Input to Output Path(SETUP)
8.2.4 Input to Output Path(HOLD)

 Here is a hold timing check on an input to output path shown in

Figure8-7. The specifications on the ports are:
 set_output_delay -clock VIRTUAL_CLKM \

-min 3.2 [get_ports POUT]

 set_input_delay -clock VIRTUAL_CLKM \

-min 1.8 [get_ports INB]

 The specification on the output port is specified with respect to a

virtual clock and hence the hold check is performed on the rising
(default active) edge of that virtual clock.
8.3 Multicycle Paths

 In some cases, the combinational data path between two flip-flops can take more than one clock cycle to propagate through the
logic. In such cases, the combinational path is declared as a multicycle path. Even though the data is being captured by the
capture flip-flop on every clock edge, we direct STA that the relevant capture edge occurs after the specified number of clock
cycles.

 Figure 8-14 shows an example. Since the data path can take up to three clock cycles, a setup multicycle check of three cycles
should be specified. The multicycle setup constraints specified to achieve this are given below.

 set_multicycle_path 3 -setup -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

 The setup multicycle constraint specifies that the path from UFF0/CK to UFF1/D can take up to three clock cycles to complete
for a setup check. This implies that the design utilizes the required data from UFF1/Q only every third cycle instead of every
cycle.
8.3 Multicycle Paths(SETUP)
8.3 Multicycle Paths (HOLD)

 We now examine the hold timing check on the example multicycle path. In most common scenarios, we would want the hold check to
stay as it was in a single cycle setup case, which is the one shown in the Figure 8-14. This ensures that the data is free to change
anywhere in between the three clock cycles. A hold multicycle of two is specified to get the same behavior of a hold check as in a
single cycle setup case. This is because in the absence of such a hold multicycle specification, the default hold check is done on the
active edge prior to the setup capture edge which is not the intent. We need to move the hold check two cycles prior to the default hold
check edge and hence a hold multicycle of two is specified. The intended behavior is shown in Figure 8-15. With the multicycle hold,
the min delay for the data path can be less than one clock cycle.
 set_multicycle_path 2 -hold -from [get_pins UFF0/Q] -to [get_pins UFF1/D]

 The number of cycles denoted on a multicycle hold specifies how many clock cycles to move back from its default hold check edge
 Since this path has a setup multicycle of three, its default hold check is on the active edge prior to the capture edge. In most designs, if
the max path (or setup) requires N clock cycles, it is not feasible to achieve the min path constraint to be greater than (N-1) clock
cycles. By specifying a multicycle hold of two cycles, the hold check edge is moved back to the launch edge (at 0ns) as shown in the
above path report.

 Thus, in most designs, a multicycle setup specified as N (cycles) should be accompanied by a multicycle hold constraint specified as
N-1 (cycles).

 What happens when a multicycle setup of N is specified but the corresponding N-1 multicycle hold is missing? In such a case, the hold
check is performed on the edge one cycle prior to the setup capture edge. The case of such a hold check on a multicycle setup of 3 is
shown in Figure 8-16.

 This imposes a restriction that data can only change in the one cycle before the setup capture edge as the figure shows. Thus the data
path must have a min delay of atleast two clock cycles to meet this requirement. Here is such a path report
➢ Notice from the path report that the hold is being checked one clock edge
prior to the capture edge, leading to a large hold violation. In effect, the hold
check is requiring a minimum delay in the combinational logic of at least two
clock cycles.
8.4 False Paths

 It is possible that certain timing paths are not real (or not possible) in the actual functional operation of the design. Such paths can be turned off during STA by
setting these as false paths. A false path is ignored by the STA for analysis. Examples of false paths could be from one clock domain to another clock domain,
from a clock pin of a flip-flop to the input of another flip-flop, through a pin of a cell, through pins of multiple cells, or a combination of these. When a false path
is specified through a pin of a cell, all paths that go through that pin are ignored for timing analysis. The advantage of identifying the false paths is that the
analysis space is reduced, thereby allowing the analysis to focus only on the real paths.

 The -through option tells the STA tool:

“Ignore every path that goes through this pin.”

When you use wildcards (* or broad patterns), the tool now has to:

set_false_path -through [get_pins *MUX*/S*]

Search for all pins in the design that match, Track all paths that go through them, Then eliminate them.

If there are hundreds or thousands of such pins, that becomes very time-consuming.
 8.4 False Paths

 This wildcard matches every select pin of every multiplexer in the design. Now, STA
tool has to:

• Go through the entire netlist,

• Match all these pins,

• Search all paths going through them,

• Then mark those paths as false.

• That’s a lot of work — which can slow down the tool significantly.

❖ set_false_path -from [get_clocks SCAN_CLK] -to [get_clocks CORE_CLK]

❖ set_false_path –from [get_pins MUX0/in0] –to [get_pins MUX0/in1]
❖ set_false_path -through [get_pins SAD_CORE/RSTN]]
❖ set_false_path -to [get_ports TEST_REG*]
❖ set_false_path -through UINV/Z -through UAND0/Z
8.5 Half-Cycle Paths

 If a design has both negative-edge triggered flip-flops (active clock

edge is falling edge) and positive-edge triggered flip-flops (active
clock edge is rising edge), it is likely that half-cycle paths exist in the
design. A half-cycle path could be from a rising edge flip-flop to a
falling edge flip-flop, or vice versa. Figure 8-19 shows an example
when the launch is on the falling edge of the clock of flip-flop UFF5,
and the capture is on the rising edge of the clock of flip-flop UFF3.
 Note the edge specification in the Startpoint and Endpoint. The
falling edge occurs at 6ns and the rising edge occurs at 12ns. Thus,
the data gets only a half-cycle, which is 6ns, to propagate to the
capture flip-flop.

 The hold check always occurs one cycle prior to the capture edge.
Since the capture edge occurs at 12ns, the previous capture edge is at
0ns, and hence the hold gets checked at 0ns. This effectively adds a
half-cycle margin for hold checking and thus results in a large
positive slack on hold.
 Half-cycle Path- Case 1

 In this example, the two clocks have the same

period but are of opposite phase. Here are the
clock specifications- the waveforms are
shown in Figure 8-29.

 create_clock -name CLKM -period 20 \

-waveform {0 10} [get_ports CLKM]
 create_clock -name CLKP -period 20 \
-waveform {10 20} [get_ports CLKP]
 Half-cycle Path- Case 2

 This example is similar to case 1 and the

launch and capture clocks are of opposite
phase. The launch clock is shifted in time.
Here are the clock specifications; the
waveforms are shown in Figure 8-30.

 create_clock -name CLKM -period 10 \ -

waveform {5 10} [get_ports CLKM]

 create_clock –name CLKP -period10 \-

waveform{05}[get_ports CLKP]
8.6 Removal Timing Check

 A removal timing check ensures that there is adequate time between an active
clock edge and the release of an asynchronous control signal. The check
ensures that the active clock edge has no effect because the asynchronous
control signal remains active until removal time after the active clock edge. In
other words, the asynchronous control signal is released (becomes inactive)
well after the active clock edge so that the clock edge can have no effect. This
is illustrated in Figure 8-20. This check is based on the removal time specified
for the asynchronous pin of the flip-flop. Here is an excerpt from the cell
library description corresponding to the removal check.

 Like a hold check, it is a min path check except that it is on an asynchronous

pin of a flip-flop
 The Endpoint shows that it is removal check. It is on
the asynchronous pin CDN off lip-flop UFF6. The
removal time for this flip-flop is listed as library
removal time with a value of 0.19ns.
 All asynchronous timing checks are assigned to the
async default path group.
8.7 Recovery Timing Check

 A recovery timing check ensures that there is a minimum amount of time

between the asynchronous signal becoming inactive and the next active clock
edge. In other words, this check ensures that after the asynchronous signal
becomes inactive, there is adequate time to recover so that the next active clock
edge can be effective. For example, consider the time between an asynchronous
reset becoming inactive and the clock active edge of a flip-flop. If the active
clock edge occurs too soon after the release of reset, the state of the flip-flop
may be unknown. The recovery check is illustrated in Figure 8-21. This check
is based upon the recovery time specified for the asynchronous pin of the flip-
flop in its cell library file, an except of which is shown below.

 Like a setup check, this is a max path check except that it is on an

asynchronous signal.
 The Endpoint shows that it is recovery check. The
recovery time for the UFF6flip-flop is listed as the
library recovery time with a value of 0.09ns.
 Recovery checks also be long to the async_default
path group
8.8 Timing across Clock Domains
• 8.8.1 Slow to Fast Clock Domains

 Let us examine the setup and hold checks when a path goes from a slower clock domain to a faster
clock domain. This is shown in Figure8-22.

 Here are the clock definitions for our example.

 create_clock -name CLKM -period 20 -waveform {0 10} [get_ports CLKM]

 create_clock -name CLKP -period 5 -waveform {0 2.5} [get_ports CLKP]
 When the clock frequencies are different for the launch flip-flop and the capture flip-flop, STA is
performed by first determining a common base period. An example of a message produced when
STA is performed on such a design with the above two clocks is given below. The faster clock is
expanded so that a common period is obtained.

 Figure 8-23 shows the setup check. By default, the most constraining setup edge relationship is
used, which in this case is the very next capture edge. Here is a setup path report that shows this.
 Notice that the launch clock is at time 0ns while the capture clock is at time 5ns.

 As discussed earlier, hold checks are related to the setup checks and ensure that the data launched
by a clock edge does not interfere with the previous capture.

 set_multicycle_path 4 -setup -from [get_clocks CLKM] -to [get_clocks CLKP] -end

8.8.1 Slow to Fast Clock Domains
 In the above example, we can see that the launch data is available every fourth cycle of the
capture clock. Let us assume that the intention is not to capture data on the very next active
edge of CLKP, but to capture on every 4th capture edge. This assumption gives the
combinational logic between the flip-flops four periods of CLKP to propagate, which is 20ns.
We can do this by setting the following multicycle specification:

 set_multicycle_path 4 -setup -from [get_clocks CLKM] -to [get_clocks CLKP] –end

 The -end specifies that the multicycle of 4 refers to the end point or the capture clock. This
multicycle specification changes the setup and hold checks to the ones shown in Figure 8-24.

 Figure8-24 shows the hold check –note that the hold check is derived from the setup check
and defaults to one cycle preceding the intended capture edge. Here is the hold timing report.
Notice that the hold capture edge is at 15ns, one cycle prior to the setup capture edge.

 In most designs, this is not the intended check, and the hold check should be moved all the
way back to where the launch edge is. We do this by set ting a hold multicycle specification of
3.
 set_multicycle_path 3 -hold -from [get_clocks CLKM] -to [get_clocks CLKP] -end
8.8.2 Fast to Slow Clock Domains

 In this subsection, we consider examples where the data path goes from a fast
clock domain to a slow clock domain. The default setup and hold checks are as
shown in Figure 8-26 when the following clock definitions are used.

 create_clock -name CLKM -period 20 -waveform {0 10} [get_ports CLKM]

 create_clock -name CLKP -period 5 -waveform {0 2.5} [get_ports CLKP]

 There are four setup timing checks possible; see Setup1, Setup2, Setup3 and
Setup4 in the figure. However, the most restrictive one is the Setup4 check. Here
is the path report of this most restrictive path. Notice that the launch clock edge is
at 15ns and the capture clock edge is at 20ns.

 Similar to the setup checks, there are four hold checks possible. Figure8-26 shows
the most restrictive hold check which ensures that the capture edge at 0ns does not
capture the data being launched at 0ns. Here is the timing report for this hold
check.

 In general, a designer may specify the data path from the fast clock to the slow
clock to be a multicycle path. If the setup check is relaxed to provide two cycles
of the faster clock for the data path, the following is included for this multicycle
specification:r this hold check.
8.8.2 Fast to Slow Clock Domains
 8.8.2 Fast to Slow Clock Domains

 set_multicycle_path 2 -setup -from [get_clocks CLKP] -to [get_clocks CLKM] -start

set_multicycle_path 1 -hold -from [get_clocks CLKP] -to [get_clocks CLKM] -start
 In this case, Figure 8-27 shows the clock edges used for the setup and hold checks. The-
start option specifies that the unit for the number of cycles (2 in this case) is that of the
launch clock (CLKP in this case). The setup multi cycle of 2 moves the launch edge one
edge prior to the default launch edge, that is, at 10ns instead of the default 15ns. The hold
multicycle ensures that the capture of the earlier data can reliably occur at 0ns due to the
launch edge also at 0ns.

 Unlike the case of paths from slow to fast clock domains, a good rule of thumb for multi-
frequency multicycle path specification in the case of paths from fast to slow clock
domains is to use the-start option. The setup and hold checks are then adjusted based
upon the fast clock.
8.8.2 Fast to Slow Clock Domains
 Input Interface

What is "Input Interface"?

 In timing analysis or simulation of digital circuits, the Input Interface refers to how external signals are fed into the Design Under Analysis (DUA). The DUA could be a module,
block, or entire chip you are testing or analyzing. It’s crucial to define how and when the input signals arrive at the inputs of the DUA to accurately analyze or simulate its
behavior. There are two broad ways to do that:

1) The waveforms at an input of the DUA are provided as AC 2) The path delay of the external logic to an input is specified.
specifications. • What does this mean?
• What does this mean?
Here, you're not giving the waveform directly. Instead, you're saying: “ This input signal is
You directly provide the full timing behavior of the input signal — generated by some logic outside the DUA, and it takes X nanoseconds to travel from there
like a waveform that says: to the input pin of the DUA.”
• At time 0 ns → the input is 0 So you're specifying the delay of the signal path — not the signal shape itself.
• At time 5 ns → the input switches to 1
• At time 10 ns → the input switches back to 0 ...and so on.
This is called an AC specification, and it's often used in analog
simulation or testbench-based simulation where timing is very
specific.
 Waveform Specification at Inputs

 Consider the input AC specification shown in Figure 9-1. The specification is that
the input CIN is stable 4.3ns before the rising edge of clock CLKP, and that the value
remains stable until 2ns after the rising edge of the clock.
 Consider the 4.3ns specification first. Given the clock cycle of 8ns (as shown in
Figure 9-1), this requirement maps into the delay from the virtual flip-flop (the flip-
flop that is driving this input) to the input CIN. The delay from the virtual flip-flop
clock to CIN must be at most 3.7ns (= 8.0- 4.3), the maximum delay being at 3.7ns.
 This ensures that the data at input CIN arrives 4.3ns prior to the rising edge. Hence,
this part of the AC specification can equivalently be specified as a max input delay
of 3.7ns.
 The AC specification also states that the input CIN is stable for 2ns after the rising
edge of the clock. This specification can also be mapped into the delay from the
virtual flip-flop, that is, the delay from the virtual flip-flop to input CIN must be at
least 2.0ns. Hence the minimum input delay is specified as 2.0ns.
 create_clock -name CLKP -period 8 [get_ports CLKP]
 set_input_delay -min 2.0 -clock CLKP [get_ports CIN]
 set_input_delay -max 3.7-clock CLKP [get_ports CIN]
Path Delay Specification to Inputs

 When the path delays of the external logic connected to an input are
known, specifying the input constraints is a straight forward task. Any
de lays along the external logic path to the input are added and the
path delay is specified using the set_input_delay command. Figure 9-
2 shows an example of external logic path to input. The Tck2q and
Tc1 delays are added to obtain the external delay. Knowing Tck2q and
Tc1, the input delay is directly obtained as Tck2q + Tc1.
 The external max and min path delays translate to the following input
constraints.

 create_clock -name RCLK -period 10 [get_ports RCLK]

 set_input_delay-max 6.2 -clock RCLK [get_ports INIT]

 set_input_delay-min 3.0-clock RCLK [get_ports INIT]

 The path reports for these are similar to the ones in Section 8.1 and
Section 8.2. Note that when computing the arrival time at the data pin
of the flip-flop inside the design, the max and min input delay values
get added to the data path delay depending on whether a max path
check (setup) or a min path check (hold) is being performed.
Output Interface

❑ Output Waveform Specification

Consider the output AC specification shown in Figure 9-3. The output QOUT should
be stable at the output 2ns prior to the rising edge of clock CLKP. Also, the output
should not change until 1.5ns after the rising edge of the clock. These constraints are
normally obtained from the setup and hold requirements of the external block that
interfaces with QOUT.

create_clock -name CLKP -period 6 -waveform {0 3} [get_ports CLKP}

set_output_delay -clock CLKP -max 2.0 [get_ports QOUT]

set_output_delay -clock CLKP -min -1.5 [get_ports QOUT]

The maximum output path delay is specified as 2.0ns. This will ensure that data
QOUT changes ahead of the 2ns window before the clock edge. The minimum
output path delay of -1.5ns specifies the requirement from the perspective of the
virtual flip-flop, that is, to ensure the 1.5ns hold requirement at the output QOUT. A
hold requirement of 1.5ns maps to a set_output_delay min of -1.5ns.
Output Change within Window

 In digital circuits, especially for source synchronous interfaces, both data and a clock are sent from the transmitter to the receiver. The receiver uses the transmitted clock (not an
internal clock) to capture the data. To ensure reliable data capture, the data must change (or transition) only within a specific timing window relative to the clock edge. This is
where the set_output_delay and generated clocks come into play—to constrain the time window when an output signal (like data) is allowed to change.

 create_clock -name CLKM -period 6 [get_ports CLKM]

 create_generated_clock -name CLK_STROBE -source [get_ports CLKM] \

-divide_by 1 [get_ports CLK_STROBE]

 # Now specify that DATAQ can only change from 2ns before to 1ns after

 set_output_delay -clock CLK_STROBE -min -2 [get_ports DATAQ]

 set_output_delay -clock CLK_STROBE -max 1 [get_ports DATAQ]

 -min -2 means data can change as early as 2ns before the clock edge.

 -max 1 means data can change as late as 1ns after the clock edge.

You have a clock signal: CLKM with a 6ns period. There’s a data signal DATAQ.

There’s an output clock signal CLK_STROBE, which is derived from CLKM (same frequency).

You want DATAQ to only change within a specific window: from 2ns before to 1ns after the

rising edge of CLK_STROBE. This constraint ensures that the data transitions only happen in this

[-2ns, +1ns] window around the clock edge—this helps the receiver align sampling correctly.
 The constraint is: "DATAQ may only change between 2ns before and 1ns after the rising edge of CLK_STROBE. "This is different from traditional timing
(where data is required to be stable before and after the clock edge). Here, the design explicitly allows the data to change only within a specific window.
Why? Because this helps the receiver know when to expect transitions, and avoid sampling while data is changing.
❑ Why do we have CLK_STROBE?

❖ Imagine this: You have two chips (or two blocks) communicating:

❖ One is sending data, the other needs to receive that data on time

❖ But wait — the receiving chip doesn't know when the data is valid!

❖ So how do we fix this? --→ We send a clock signal along with the data — this is called a source synchronous interface.
❖ The sender becomes the "source" of the clock and the data.

❖ That's what CLK_STROBE is — a clock signal sent out with the data so the receiver knows exactly when to sample it.

❑ Why do we give a window to change the data?

o The receiver samples data using CLK_STROBE.
o To avoid confusion, we say: “DATA can only change between 2ns before and 1ns after
CLK_STROBE rising edge.”
o This gives a predictable window so the receiver knows:
o Exactly when data might change
o When to safely capture stable data
❑ Where is this used in design?
❖ DDR (Double Data Rate) memory interfaces
❖ FPGA-to-FPGA communication
❖ High-speed serial interfaces
Summary:
❖ Camera interfaces (like MIPI CSI)
❖ set_multicycle_path 0 -setup -to [get_ports DATAQ]
❖ “For setup, treat this as a same-cycle path.”
❖ In other words, data should be captured on the same edge it was
launched.
❖ set_multicycle_path -1 -hold -to [get_ports DATAQ]
❖ “Also do the hold check on the same clock edge.”
❖ Why -1? Because without it, the hold check would assume the
next edge. You're correcting it to the same edge.
❑ Notice that the launch and the capture edges are the same clock edge,
which is at time 0. The report shows that DATAQ changes at 0.61ns while ❑ With the min path analysis, DATAQ arrives at 0.48ns while the CLK_STROBE arrives at
the CLK_STROBE changes at 0.09ns. Since DATAQ can change within 1ns 0.09ns. Since the requirement is that data can change up to a 2ns limit before
of the CLK_STROBE, there is a slack of 0.18ns after accounting for the 0.3ns CLK_STROBE, we get a slack of 2.35ns after accounting for the clock uncertainty of 50ps.
of clock uncertainty.