Fig.

IoT Reference Model Published by the IoT World Forum

Fig. IoT Reference Model Connectivity Layer Functions

Fig. IoT Reference Model Layer 3 Functions

Slew of a Waveform
A slew rate is defined as a rate of change. In static timing analysis, the rising or falling waveforms
are measured in terms of whether the transition is slow or fast. The slew is typically measured in
terms of the transition time, that is, the time it takes for a signal to transition between two specific
levels. Transition time is actually inverse of the slew rate – the larger the transition time, the slower
the slew, and vice versa.
Fig. illustrates a typical waveform at the output of a CMOS cell. The waveforms at the ends are
asymptotic and it is hard to determine the exact start and end points of the transition. Consequently,
the transition time is defined with respect to specific threshold levels. For example, the slew
threshold settings can be:
#Falling edge thresholds:
slew_lower_threshold_pct_fall : 30.0;
slew_upper_threshold_pct_fall : 70.0;
#Rising edge thresholds:
slew_lower_threshold_pct_rise : 30.0;
slew_upper_threshold_pct_rise : 70.0;

These values are specified as a percent of Vdd. The threshold settings specify that falling slew is
the difference between the times that falling edge reaches 70% and 30% of Vdd. Similarly, the
settings for rise specify that the rise slew is the difference in times that the rising edge reaches
30% and 70% of Vdd, as shown in below figure.

Fig. Rise and fall transition times.

Fig. below shows another example where the slew on a falling edge is measured 20-80 (80% to
20%) and that on the rising edge is measured 10-90(10% to 90%).

Fig. Another example of slew measurement.

The threshold settings for this case are –

# Falling edge thresholds:

slew_lower_threshold_pct_fall : 20.0;
slew_upper_threshold_pct_fall : 80.0;
# Rising edge thresholds:
slew_lower_threshold_pct_rise : 10.0;
slew_upper_threshold_pct_rise : 90.0;

Skew between Signals

Skew is the difference in timing between two or more signals, maybe data, clock or both. For
example, if a clock tree has 500 end points and has a skew of 50ps, it means that the difference in
latency between the longest path and the shortest clock path is 50ps. Figure 2-15 shows an example
of a clock tree. The beginning point of a clock tree typically is a node where a clock is defined.
The end points of a clock tree are typically clock pins of synchronous elements, such as flip-flops.
Clock latency is the total time it takes from the clock source to an end point. Clock skew is the
difference in arrival times at the end points of the clock tree.

Fig. Clock tree, clock latency and clock skew.

An ideal clock tree is one where the clock source is assumed to have an infinite drive, that is, the
clock can drive infinite sources with no delay. In addition, any cells present in the clock tree are
assumed to have zero delay. In the early stages of logical design, STA is often performed with
ideal clock trees so that the focus of the analysis is on the data paths. In an ideal clock tree, clock
skew is 0ps by default. Latency of a clock tree can be explicitly specified using the
set_clock_latency command.
The following example models the latency of a clock tree:

set_clock_latency 2.2 [get_clocks BZCLK]

# Both rise and fall latency is 2.2ns.
# Use options -rise and -fall if different.

Clock skew for a clock tree can also be implied by explicitly specifying its value using the
set_clock_uncertainty command:

set_clock_uncertainty 0.250 -setup [get_clocks BZCLK]

set_clock_uncertainty 0.100 -hold [get_clocks BZCLK]

The set_clock_uncertainty specifies a window within which a clock edge can occur. The
uncertainty in the timing of the clock edge is to account for several factors such as clock period
jitter and additional margins used for timing verification. Every real clock source has a finite
amount of jitter – a window within which a clock edge can occur. The clock period jitter is
determined by the type of clock generator utilized. In reality, there are no ideal clocks, that is, all
clocks have a finite amount of jitter and the clock period jitter should be included while specifying
the clock uncertainty.

Before the clock tree is implemented, the clock uncertainty must also include the expected clock
skew of the implementation.

One can specify different clock uncertainties for setup checks and for hold checks. The hold checks
do not require the clock jitter to be included in the uncertainty and thus a smaller value of clock
uncertainty is generally specified for hold.

Fig. Clock setup uncertainty

Fig. (a) above shows an example of a clock with a setup uncertainty of 250ps.
Fig.(b) shows how the uncertainty takes away from the time available for the logic to propagate
to the next flip-flop stage. This is equivalent to validating the design to run at a higher frequency.

The set_clock_uncertainty can also be used to model any additional margin. For ex, a designer
may use a 50ps timing margin as additional pessimism during design. This component can be
added and included in the set_clock_uncertainty command.
In general, before the clock tree is implemented, the set_clock_uncertainty command is used to
specify a value that includes clock jitter plus estimated clock skew plus additional pessimism.

set_clock_latency 2.0 [get_clocks USBCLK]

set_clock_uncertainty 0.2 [get_clocks USBCLK]
# The 200ps may be composed of 50ps clock jitter,
# 100ps clock skew and 50ps additional pessimism.
Timing Modeling

The cell timing models are intended to provide accurate timing for various instances of the cell in
the design environment. The timing models are normally obtained from detailed circuit
simulations of the cell to model the actual scenario of the cell operation. The timing models are
specified for each timing arc of the cell.

Figure 3.1 Timing arc delays for an inverter cell.

Timing arcs for a simple inverter logic cell shown in Figure 3-1. Since it is an inverter, a rising
(falling) transition at the input causes a falling (rising) transition at the output. The two kinds of
delay characterized for the cell are:

• Tr : Output rise delay

• Tf : Output fall delay

The delays are measured based upon the threshold points defined in a cell library (s, which is
typically 50% Vdd. Thus, delays are measured from input crossing its threshold point to the output
crossing its threshold point.

The delay values have a direct correlation with the load capacitance – the larger the load
capacitance, the larger the delay. In most cases, the delay increases with increasing input transition
time.
The slew at the output of a cell depends mainly upon the output capacitance - output transition
time increases with output load. Thus, a large slew at the input (large transition time) can improve
at the output depending upon the cell type and its output load.

Figure 3-2 Slew changes going through a cell.

 Non-Linear Delay Model (NLDM)

Most of the cell libraries include table models to specify the delays and timing checks for various
timing arcs of the cell. Some newer timing libraries for nm technologies also provide current
source based advanced timing models (such as CCS, ECSM, etc.). The table models are referred
to as NLDM (Non-Linear Delay Model) and are used for delay, output slew, or other timing
checks.
The table models capture the delay through the cell for various combinations of input transition
time at the cell input pin and total output capacitance at the cell output.
An NLDM is in a 2D form, with the two independent variables being the input transition time and
the output load capacitance, and the entries in the table denoting the delay.
Here is an ex of such a table for a typical inverter cell:

pin (OUT) {
max_transition : 1.0;
timing() {
related_pin : "INP1";
timing_sense : negative_unate;
cell_rise(delay_template_3x3) {
index_1 ("0.1, 0.3, 0.7"); /* Input transition */
index_2 ("0.16, 0.35, 1.43"); /* Output capacitance */
values ( /* 0.16 0.35 1.43 */ \
/* 0.1 */ "0.0513, 0.1537, 0.5280", \
/* 0.3 */ "0.1018, 0.2327, 0.6476", \
/* 0.7 */ "0.1334, 0.2973, 0.7252");
}
cell_fall(delay_template_3x3) {
index_1 ("0.1, 0.3, 0.7"); /* Input transition */
index_2 ("0.16, 0.35, 1.43"); /* Output capacitance */
values ( /* 0.16 0.35 1.43 */ \
/* 0.1 */ "0.0617, 0.1537, 0.5280", \
/* 0.3 */ "0.0918, 0.2027, 0.5676", \
/* 0.7 */ "0.1034, 0.2273, 0.6452");
}
In the above ex, the delays of the output pin OUT are described. This portion of the cell description
contains the rising and falling delay models for the timing arc from pin INP1 to pin OUT, as well
as the max_transition allowed time at pin OUT. There are separate models for the rise and fall
delays and these are labeled as cell_rise and cell_fall respectively.
The type of indices and the order of table lookup indices are described in the lookup table template
delay_template_3x3.
Different Slew Thresholds
In general, a library specifies the slew (transition time) threshold values used during
characterization of the cells. The question is, what happens when a cell with one set of slew
thresholds drives other cells with different set of slew threshold settings?

Consider the case shown in above fig. where a cell characterized with 20-80 slew threshold drives
two fanout cells; one with a 10-90 slew threshold and the other with a 30-70 slew threshold and a
slew derate of 0.5.