Timing Verification---Setup timing check

The Setup check can be mathematically expressed as:
Tlaunch + tck2q + TDP < Tcapture + Tcycle-tsetup
Where Tlaunch is the delay of the clock tree of the launch flip-flop UFF0, TDP is the delay of the combinational logic dat A path and tcycle is the clock period.
Tcapture is the delay of the clock tree for the capture flip-flop UFF1.

Since the Setup check poses a max 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 is the largest.

1.flip-flop to Flip-flop Path

The path Type, line indicates, the delays shown in, the This, all Max Path delays indicating, 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.

The launch path takes 0.26ns to get to the D pin of flip-flop uff1-this are the arrival time at the input of the capture Flip-flop. The Capture Edge
(which is one cycle away since-a setup check) is at 10ns. A clock uncertainty of 0.3NS was specified for this clock-thus, the clock period is reduced
By the uncertainty margin. The clock uncertainty includes the variation in cycle time due to jitter in the clock source and any other timing
Margin used for analysis. The setup time of the flip-flop 0.04ns (called Library setup time), is deducted from the total capture path yielding a req Uired

Time of 9.66ns.

What's the clock network delay in the timing report and so is it marked as ideal? This timing indicates the clock trees is treated
As ideal, that any buffers in the clock path is assumed to has zero delay. Once The clock trees is built, the clock network can be marked as propagated

-which causes the clock paths to show up with real delays, as shown on the next example timing report. The 0.11ns delay is the clock network delay on the launch

Clock and the 0.12ns delay are the clock network delay on the capture flip-flop.

The timing path report can optionally include the expanded clock paths, which is, with the clock trees explicitly shown. Here's such an example.

STARTPOINT:UFF0 (rising edge-triggered flip-flop clocked by clkm)
ENDPOINT:UFF1 (rising edge-triggered flip-flop clocked by clkm)
Path group:clkm
Path Type:max

Notice the clock buffers, UCKBUF0, UCKBUF1 and UCKBUF2 appear in the path report above and provide details of the Clock tree delays
is computed.

How is the delay of the first clock cell UCKBUF0 computed? As described in previous chapters, the cell delay was calculated based on the input transition
Time and the output capacitance of the cell. Thus, the question is what transition time was used at the input of the first cell in the clock tree. The
Transition time (or slew) on the input pin of the first clock cell can be explicitly specified using the Set_input_transit Ion command.

Set_input_transition-rise 0.3 [Get_ports clkm]
Set_input_transition-fall 0.45 [Get_ports clkm]

In the Set_input_transition specification shown above, we specified the input rise transition time to be 0.3ns and the FAL L transition time to BES 0.45ns.
In the absence of the input transition specifications, ideal slew are assumed at the origin of the clock tree, which Implie s that both the rise and fall transition
Times is 0ns.

The "R" and "F" characters in the timing report indicate the rising (and falling) edge of the clock or data signal. The previous path report shows the
Path starting from the falling edge of uff0/q and ending on the rising edge of uff1/d. Since uff1/d can be either 0 or 1, there can be a path ending
At the falling edge of uff1/d as well. Here is such a path.

Note that the edge is 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.

What is clock source latency? This is also called insertion delay and was the time it takes for a clock to propagate from its source to the clock definit Ion Point
of the design under analysis as depicted in Figure 8-3. This corresponds to the latency of the clock tree, which 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 pi N 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 is the assumption used in earlier path reports. Note that the source latency does
Not affect paths is internal to the design and has the same launch clock and capture clock. This was 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 be built, that
is, the 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 used to model the delay from the master clock to one of its generated clocks. This command
was also used to model off-chip clock latency When clock generation logic was not part of the design.

2.Input to flip-flop Path

Input Path with Virtual Clock

The input path starts from the port INA; How does one compute the delay in the first cell UINV1 connected to port INA? One-to-accomplish this
is by specifying the driving cell of the input port INA. This driving cell was used to determine the drive strength and thus the slew on the Port INA,
Which is then used to compute the delay of the cell UINV1. In the absence of any slew specification on the input port INA, the transition at the port is
Assumed to is ideal, which corresponds to a transition time of 0ns.

Set_driving_cell-lib_cell BUFF \
-library LIB013LWC [Get_ports INA]

Create_clock-name virtual_clkm-period 10-waveform {0 5}
Set_input_delay-clock virtual_clkm \

-max 2.55 [Get_ports INA]

Input Path with Actual Clock

Set_input_delay-clock clkp-max 4.3 [get_ports CIN]

3.flip-flop to Output Path

Similar to the input port constraint described above, an output port can beconstrained either with respect to a virtual CL Ock, or an internal clock of the
design, or an input clock port, or an output clock port.

To determine the delay of the last cell connected to the output port correctly, one needs to specify the load in this port . The output load is specified
Above using the Set_load command.

Set_output_delay-clock VIRTUAL_CLKP \
-max 5.1 [Get_ports ROUT]
Set_load 0.02 [Get_ports ROUT]

To determine the delay of the last cell connected to the output port correctly, one needs to specify the load in this port . The output load is specified
Above using the Set_load command. Note that the port ROUT may has the load contribution internal to the DUA and the Set_load specification provides
The additional load, which is the load contribution from outside the DUA. In the absence of the Set_load specification, a value of 0 for the external
Load is assumed (which if not being realistic as this design would most probably being used in some other design). Figure 8-6 shows the timing path
To the virtual flip-flop, which has the virtual clock.

4.Input to Output Path

The design can has a combinational path going from an input port to an output port. This path can is constrained and timed just like the input and
Output paths we saw earlier. Figure 8-7 shows an example of such a path. Virtual clocks is used to specify constraints on both input and output
Ports.

Here is the input and output delay specifications.
Set_input_delay-clock virtual_clkm \
-max 3.6 [Get_ports INB]
Set_output_delay-clock virtual_clkm \
-max 5.8 [Get_ports POUT]

Here's a path report, goes through the combinational logic from input INB to output POUT. Notice that any internal clock latencies, if present,
There are no effect on the path report.

5.Frequency histogram

If one were to plot a frequency histogram of the setup slack versus number of paths for a typical design, it would look like T He one shown in Figure 8-8.
Depending upon the the state of the design, whether it had been optimized or not, the zero-slack line would is more towards th e Right-an unoptimized
Design and more towards the left for an optimized design. For a design the have zero violations, that's no paths with negative slack, the entire
Curve would is to the right of the zero slack line.

Here are a histogram shown in a textual form so can often be produced by a static timing analysis tool.

The first and indices denote the slack range and the third index is the number of paths within that slack range, for ex Ample, there is 941 paths with
Slack in the range of 410ps to 415ps. The histogram indicates that this design has a no failing paths, that's all paths having positive slack, and that the
MoS T critical path has a positive slack between 375PS and 380ps.

Designs that's tough to meet timing would has their hump of the histogrammore towards the left, which is, has many path s with slack closer to
Zero. One other observation, can be made by looking at a frequency histogram are on the ability to further optimize the Desig N to achieve Zero
Slack, that's, how difficult it was to close timing. If the number of failing paths is small and the negative slack are also small, the design is relatively
Close to meeting the required timing. However, if the number of failing paths is large and the negative slack magnitude are also large, this implies
That's the design would require a lot of effort to meet the required timing.